From bence@intercom.hu Sat Jan 2 14:47:20 1999 From: bence@intercom.hu (Hermann Benedek) Date: Sat, 2 Jan 1999 15:47:20 +0100 Subject: [Mailman-Developers] Send digest at a specific time Message-ID: I want the digest to be sent a specific time, eg. at midnight, but I can't set the sent-out-time. It would be great if I could set the max. digest size to 0, and set a "send-time" variable to the time when I want to send out the digests. Any idea? Udv Bence From w.knowles@niwa.cri.nz Tue Jan 5 02:56:25 1999 From: w.knowles@niwa.cri.nz (Wayne Knowles) Date: Tue, 5 Jan 1999 15:56:25 +1300 (NZDT) Subject: [Mailman-Developers] Upgrade from 1.0b4 -> 1.0b7 fails Message-ID: I have been running Mailman version 1.0b4 for a while, and decided it was about time to upgrade to the latest version. Everything went well until the point of running the "make update" script then got the following error: ***** ***** If you are installing over an old installation, please ***** run "make update". See the UPGRADING file for details. ***** katipo 130% make update Traceback (innermost last): File "bin/update", line 10, in ? from Mailman.MailList import MailList File "/home/mailman/Mailman/MailList.py", line 30, in ? import Utils File "/home/mailman/Mailman/Utils.py", line 509, in ? def chunkify(members, chunksize=mm_cfg.DEFAULT_ADMIN_MEMBER_CHUNKSIZE): AttributeError: DEFAULT_ADMIN_MEMBER_CHUNKSIZE DEFAULT_ADMIN_MEMBER_CHUNKSIZE was not defined in my old mm_cfg.py file, and the mm_cfg.py wasn't installed overtop, but as mm_cfg.py.dist Since the site config is standard I copied across mm_cfg.py.dist into mm_cfg.py and make update completed. The Python version isn't quite kosher, but I don't think it matters: Python 1.5.2a2 (#5, Dec 15 1998, 13:16:57) [GCC 2.7.2.1] on freebsd2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> Did I install 1.0b4 incorrectly, or does the update script need to be fixed to work around the problem? BTW - The known problem building under FreeBSD using BSD Make appears to be fixed (have tested on FreeSBD 2.2.5 and 3.0-current). I no longer need GNU Make or hack the Makefile by hand. Wayne -- _____ Wayne Knowles, Systems Manager / o \/ National Institute of Water & Atmospheric Research Ltd \/ v /\ P.O. Box 14-901 Kilbirnie, Wellington, NEW ZEALAND `---' Email: w.knowles@niwa.cri.nz From grin@tolna.net Tue Jan 5 03:34:25 1999 From: grin@tolna.net (Peter Gervai) Date: Tue, 5 Jan 1999 04:34:25 +0100 Subject: [Mailman-Developers] [ANNOUNCE] Mailman 1.0b7 In-Reply-To: <13964.177.459126.902326@anthem.cnri.reston.va.us>; from Barry A. Warsaw on Thu, Dec 31, 1998 at 05:54:41PM -0500 References: <13964.177.459126.902326@anthem.cnri.reston.va.us> Message-ID: <19990105043425.A23199@mail.tolna.net> Barry, On Thu, Dec 31, 1998 at 05:54:41PM -0500, Barry A. Warsaw wrote: > Below is an excerpt from the DONE file which gives some highlights for > this release. [...] Do you know the feeling when you read a release note and it contains nearly all the bugs you've come up with the last month fixed? ;-) Great work done, installed without a problem. Until now. :) So far only one comment: UPGRADING file should be upgraded. :) (as well as 'make upgrade' texts.) bye, grin From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Jan 6 03:47:45 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 5 Jan 1999 22:47:45 -0500 (EST) Subject: [Mailman-Developers] Send digest at a specific time References: Message-ID: <13970.56545.331951.476159@anthem.cnri.reston.va.us> >>>>> "HB" == Hermann Benedek writes: HB> I want the digest to be sent a specific time, eg. at midnight, HB> but I can't set the sent-out-time. HB> It would be great if I could set the max. digest size to 0, HB> and set a "send-time" variable to the time when I want to send HB> out the digests. HB> Any idea? The "send-time" is controlled by the crontab entry you installed: cron/crontab.in. Just change the time set to run the senddigests script. You don't need to set digest size to 0, leave it at the size you have so digests can be send more than once a day if your list has a lot of traffic. Just set digest_send_periodic to true and you'll get your daily digests even if the size threshhold hasn't been reached. Hit `yes' to the question: Should a digest be dispatched daily when the size threshold isn't reached? -Barry From boldi@budapest.hu Mon Jan 4 01:47:38 1999 From: boldi@budapest.hu (Bencsath Boldizsar) Date: Mon, 4 Jan 1999 02:47:38 +0100 (CET) Subject: [Mailman-Developers] small sec problem / or feuture (?) In-Reply-To: <13947.11732.567166.584256@anthem.cnri.reston.va.us> Message-ID: Hi! Another mailman problem, just for You: On one of my lists a strange mail occoured: it came from szecsei virag, who has NO email address at budapest.hu But the mail, that was distributed by the list contains a header: From: Szecsei@sas.fph.hu, =?iso-8859-1?Q?Vir=E1g?= I'm not sure, it might be a problem in sendmail or anything, i thing the original address was From: Szecsei, Vira'g (but the a' was an eastern european letter) And somewhere, somewhat tried to convert it to a "living" address by adding the hostname to the first word. thank You, boldizsar -------------------------------- Bencsath Boldizsar boldi@inf.bme.hu boldi@rulez.org greetings to MP5k DREC JCE Lacrosse http://www.inf.bme.hu/~boldi -------------------------------- From dragondm@delta.integral.org Wed Jan 6 16:08:58 1999 From: dragondm@delta.integral.org (The Dragon De Monsyne) Date: Wed, 6 Jan 1999 10:08:58 -0600 (CST) Subject: [Mailman-Developers] small sec problem / or feuture (?) In-Reply-To: Message-ID: On Mon, 4 Jan 1999, Bencsath Boldizsar wrote: > Hi! > > Another mailman problem, just for You: > On one of my lists a strange mail occoured: it came from szecsei virag, > who has NO email address at budapest.hu > But the mail, that was distributed by the list contains a header: > From: Szecsei@sas.fph.hu, =?iso-8859-1?Q?Vir=E1g?= > > > I'm not sure, it might be a problem in sendmail or anything, i thing the > original address was > From: Szecsei, Vira'g > (but the a' was an eastern european letter) > And somewhere, somewhat tried to convert it to a "living" address by > adding the hostname to the first word. Ok, I see what's happening here, but it isn't with Mailman. The =?iso...?= stuff is the MIME way of quoting non latin-1 charsets. Some MTA probly did that, and you email program dosen't support MIME RFC encoded headers. Second, as I see by your message ID you are using PINE on sas.fph.hu PINE is what is adding the hostname to that first part. It's thinking 'Szecsei' is a local emal address, & tacking the local hostname (sas.fph.hu) onto it for you. Third, that address is technically bogus. Commas are not allowed in address comments. -The Dragon De Monsyne From Harald.Meland@usit.uio.no Wed Jan 6 16:43:06 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 06 Jan 1999 17:43:06 +0100 Subject: [Mailman-Developers] small sec problem / or feuture (?) In-Reply-To: Bencsath Boldizsar's message of "Mon, 4 Jan 1999 02:47:38 +0100 (CET)" References: Message-ID: [Bencsath Boldizsar] > But the mail, that was distributed by the list contains a header: > From: Szecsei@sas.fph.hu, =?iso-8859-1?Q?Vir=E1g?= > > > I'm not sure, it might be a problem in sendmail or anything, i thing the > original address was > From: Szecsei, Vira'g This very much sounds like something that the MTA, and not Mailman, would do. RFC822 specifies that addresses in the From: header should not be unqualified, and thus many MTAs try "fixing" such broken headers by adding and "@" and some local domain. I think trying to implement something in Mailman to stop messages whose headers appear to have been subject to such (possibly incorrect) address qualification, would be: 1) Very nearly impossible to get anywhere close to correct 2) Uncalled for. This is simply not a job Mailman should take on Basically the problem in Szecsei's case is that he inserted a "," in the real name part of his From address, thereby really making it into _two_ separate addresses (one of them unqualified). The problems start with the insertion of that pesky extra ",", and that's where this should be fixed. -- Harald From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Jan 6 23:09:28 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 6 Jan 1999 18:09:28 -0500 (EST) Subject: [Mailman-Developers] Upgrade from 1.0b4 -> 1.0b7 fails References: Message-ID: <13971.60712.534766.306199@anthem.cnri.reston.va.us> >>>>> "WK" == Wayne Knowles writes: WK> Did I install 1.0b4 incorrectly, or does the update script WK> need to be fixed to work around the problem? You did everything correctly. It is a problem with the Mailman/Utils.py file. Attached is a patch that should fix the problem. WK> BTW - The known problem building under FreeBSD using BSD Make WK> appears to be fixed (have tested on FreeSBD 2.2.5 and WK> 3.0-current). I no longer need GNU Make or hack the Makefile WK> by hand. Cool! Thanks for the feedback -- I can only test with Solaris make and GNU make, so I'm glad my changes fixed the problem. -Barry Index: Utils.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/Utils.py,v retrieving revision 1.58 diff -c -r1.58 Utils.py *** Utils.py 1999/01/05 23:03:43 1.58 --- Utils.py 1999/01/06 23:05:03 *************** *** 506,515 **** return got ! def chunkify(members, chunksize=mm_cfg.DEFAULT_ADMIN_MEMBER_CHUNKSIZE): """ return a list of lists of members """ members.sort() res = [] while 1: --- 506,517 ---- return got ! def chunkify(members, chunksize=None): """ return a list of lists of members """ + if chunksize is None: + chunksize = mm_cfg.DEFAULT_ADMIN_MEMBER_CHUNKSIZE members.sort() res = [] while 1: From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Jan 6 23:11:33 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 6 Jan 1999 18:11:33 -0500 (EST) Subject: [Mailman-Developers] [ANNOUNCE] Mailman 1.0b7 References: <13964.177.459126.902326@anthem.cnri.reston.va.us> <19990105043425.A23199@mail.tolna.net> Message-ID: <13971.60837.546629.831837@anthem.cnri.reston.va.us> >>>>> "PG" == Peter Gervai writes: PG> Do you know the feeling when you read a release note and it PG> contains nearly all the bugs you've come up with the last PG> month fixed? ;-) Yay! PG> Great work done, installed without a problem. Until now. :) Cool... um... PG> So far only one comment: UPGRADING file should be upgraded. :) PG> (as well as 'make upgrade' texts.) Thanks, will do. -Barry From jerrya@fastrans.net Wed Jan 6 23:20:55 1999 From: jerrya@fastrans.net (Jerry Adlersfluegel) Date: Wed, 6 Jan 1999 17:20:55 -0600 (CST) Subject: [Mailman-Developers] fwd: Cron /usr/bin/python /home/mailman/cron/senddigests (fwd) Message-ID: I have upgraded mailman to the new release, 1.0b7, on my redhat 5 system. $ uname -a Linux jerrya 2.0.32 #4 Wed Jan 7 23:14:32 CST 1998 i486 unknown I still receive the following message every day when the digests go out. They are going out successfully, but this message still gets delivered. ---------- Forwarded message ---------- Date: Wed, 6 Jan 1999 12:00:04 -0600 From: Cron Daemon To: mailman@jerrya.fastrans.net Subject: Cron /usr/bin/python /home/mailman/cron/senddigests Traceback (innermost last): File "/home/mailman/cron/senddigests", line 37, in ? main() File "/home/mailman/cron/senddigests", line 34, in main list.SendDigestIfAny() File "/home/mailman/Mailman/Digester.py", line 194, in SendDigestIfAny self.SendDigestOnSize(0) File "/home/mailman/Mailman/Digester.py", line 206, in SendDigestOnSize self.SendDigest() File "/home/mailman/Mailman/Digester.py", line 290, in SendDigest self.DeliverToList(d.Present(mime=0), File "/home/mailman/Mailman/Deliverer.py", line 172, in DeliverToList status = cmdproc.close() IOError: (10, 'No child processes') Any ideas? Thanks. -- Jerry Adlersfluegel From julian7@kva.hu Thu Jan 7 19:07:06 1999 From: julian7@kva.hu (Balazs Nagy) Date: Thu, 7 Jan 1999 20:07:06 +0100 (CET) Subject: [Mailman-Developers] Little bug(?) in admindb Message-ID: Hiyas, I got four pendings to an email list, but when I wanted to submit my changes, it said that there's an error in line #196. This is a for loop with form.keys() as k, but it cannot interpret form[k].value. I have no time because I want to finish my cgi extension and MTU patches but for the short-time fix I got out ValueError from the next except line. -- Linux Supporting Center -- Red Hat Qmail packages -- http://lsc.kva.hu PGP 0x1DE3631D / A8 B4 92 EE 1F 55 27 C8 86 64 9C 42 41 A4 BD B8 Don't spell GLIB backwards! From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Jan 8 06:36:22 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 8 Jan 1999 01:36:22 -0500 (EST) Subject: [Mailman-Developers] fwd: Cron /usr/bin/python /home/mailman/cron/senddigests (fwd) References: Message-ID: <13973.42854.570987.255838@anthem.cnri.reston.va.us> >>>>> "JA" == Jerry Adlersfluegel writes: JA> I have upgraded mailman to the new release, 1.0b7, on my JA> redhat 5 system. JA> $ uname -a Linux jerrya 2.0.32 #4 Wed Jan 7 23:14:32 CST 1998 JA> i486 unknown JA> I still receive the following message every day when the JA> digests go out. They are going out successfully, but this JA> message still gets delivered. I've never seen this on Solaris, and I can't reproduce it. Since you're still getting deliveries, I think we'll suppress the error message. Here's a patch. Could you and other Linux folks please test? -Barry -------------------- snip snip -------------------- Index: Deliverer.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/Deliverer.py,v retrieving revision 1.48 diff -c -r1.48 Deliverer.py *** Deliverer.py 1998/12/23 00:09:59 1.48 --- Deliverer.py 1999/01/08 06:27:55 *************** *** 20,25 **** --- 20,26 ---- import string, os, sys import operator + import errno import mm_cfg import Errors import Utils *************** *** 169,175 **** if footer: cmdproc.write(footer) ! status = cmdproc.close() if status: self.LogMsg('deliverer', 'Non-zero exit status: %d\nCommand: %s', --- 170,191 ---- if footer: cmdproc.write(footer) ! # TBD: this potentially masks a real bug. We have been getting ! # several reports from Linux users that this line is raising the ! # following exception: ! # ! # IOError: (10, 'No child processes') ! # ! # I don't know how this can happen, I can't reproduce it on Solaris, ! # and it doesn't seem to affect anything. So I'm chalking it up to a ! # harmless Linux artifact that we can safely ignore. ! try: ! status = cmdproc.close() ! except IOError, (code, msg): ! if errcode <> errno.ECHILD: ! Utils.reraise() ! # otherwise just ignore it ! status = 0 if status: self.LogMsg('deliverer', 'Non-zero exit status: %d\nCommand: %s', From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Jan 8 06:46:16 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 8 Jan 1999 01:46:16 -0500 (EST) Subject: [Mailman-Developers] Little bug(?) in admindb References: Message-ID: <13973.43448.461046.183947@anthem.cnri.reston.va.us> >>>>> "BN" == Balazs Nagy writes: BN> I got four pendings to an email list, but when I wanted to BN> submit my changes, it said that there's an error in line #196. BN> This is a for loop with form.keys() as k, but it cannot BN> interpret form[k].value. Can you please send a traceback? I don't know what kind of error you're getting. Is it an AttributeError or something else? BN> I have no time because I want to finish my cgi extension and BN> MTU patches but for the short-time fix I got out ValueError BN> from the next except line. Sorry, I don't quite understand. Also, please submit patches against the CVS tree if possible, otherwise definitely against 1.0b7. And if you're looking to get these patches into 1.0, *please hurry*! ;-) -Barry From julian7@kva.hu Fri Jan 8 08:16:14 1999 From: julian7@kva.hu (Balazs Nagy) Date: Fri, 8 Jan 1999 09:16:14 +0100 (CET) Subject: [Mailman-Developers] Little bug(?) in admindb In-Reply-To: <13973.43448.461046.183947@anthem.cnri.reston.va.us> Message-ID: On Fri, 8 Jan 1999, Barry A. Warsaw wrote: > >>>>> "BN" == Balazs Nagy writes: > > BN> I got four pendings to an email list, but when I wanted to > BN> submit my changes, it said that there's an error in line #196. > BN> This is a for loop with form.keys() as k, but it cannot > BN> interpret form[k].value. > > Can you please send a traceback? I don't know what kind of error > you're getting. Is it an AttributeError or something else? I didn't have a mouse but a simple console screen with lynx. Here's my new test: With one pending: OK With two or more pendings: Traceback (innermost last): File "/home/mailman/scripts/driver", line 102, in run_main main() File "../Mailman/Cgi/admindb.py", line 124, in main HandleRequests(doc) File "../Mailman/Cgi/admindb.py", line 196, in HandleRequests v = int(form[k].value) AttributeError: value > BN> I have no time because I want to finish my cgi extension and > BN> MTU patches but for the short-time fix I got out ValueError > BN> from the next except line. Just now Iam rewriting my old patches, but my temp fix is --- admindb.py.orig Fri Jan 8 09:13:35 1999 +++ admindb.py Fri Jan 8 09:13:43 1999 @@ -195,7 +195,7 @@ try: v = int(form[k].value) request_id = int(k) - except ValueError: + except: continue try: request = list.GetRequest(request_id) > Also, please submit patches against the CVS tree if possible, > otherwise definitely against 1.0b7. And if you're looking to get > these patches into 1.0, *please hurry*! ;-) Of course ;) I'll send it today (until 1500CET). -- Linux Supporting Center -- Red Hat Qmail packages -- http://lsc.kva.hu PGP 0x1DE3631D / A8 B4 92 EE 1F 55 27 C8 86 64 9C 42 41 A4 BD B8 Don't spell GLIB backwards! From julian7@kva.hu Fri Jan 8 09:47:48 1999 From: julian7@kva.hu (Balazs Nagy) Date: Fri, 8 Jan 1999 10:47:48 +0100 (CET) Subject: [Mailman-Developers] My patches Message-ID: 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. ---456965764-233999344-915788868=:3512 Content-Type: TEXT/PLAIN; charset=US-ASCII Hiyas, Here are my patches. These do the following: 1-cmdhandler: simplification in `set' command 2-cgiext: adds CGI extension support (eg. admin -> admin.cgi) 3-mtu: replaces direct SMTP delivery with sendmail/qmail/smail etc software. -- Linux Supporting Center -- Red Hat Qmail packages -- http://lsc.kva.hu PGP 0x1DE3631D / A8 B4 92 EE 1F 55 27 C8 86 64 9C 42 41 A4 BD B8 Don't spell GLIB backwards! ---456965764-233999344-915788868=:3512 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="mailman-1-cmdhandler.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="mailman-1-cmdhandler.patch" ZGlmZiAtcnVOIG1haWxtYW4ub3JpZy9NYWlsbWFuL01haWxDb21tYW5kSGFu ZGxlci5weSBtYWlsbWFuL01haWxtYW4vTWFpbENvbW1hbmRIYW5kbGVyLnB5 DQotLS0gbWFpbG1hbi5vcmlnL01haWxtYW4vTWFpbENvbW1hbmRIYW5kbGVy LnB5CVNhdCBEZWMgMTIgMTk6MDM6NDMgMTk5OA0KKysrIG1haWxtYW4vTWFp bG1hbi9NYWlsQ29tbWFuZEhhbmRsZXIucHkJRnJpIEphbiAgOCAwOToyOTow OSAxOTk5DQpAQCAtMjQxLDEwICsyNDEsMTcgQEANCiAJZWxzZToNCiAJICAg IFNob3dTZXRVc2FnZSgpDQogCSAgICByZXR1cm4NCisJdHJ5Og0KKwkgICAg c2VuZGVyID0gc2VsZi5GaW5kVXNlcihtYWlsLkdldFNlbmRlcigpKQ0KKwkg ICAgc2VsZi5Db25maXJtVXNlclBhc3N3b3JkKHNlbmRlciwgYXJnc1syXSkN CisJZXhjZXB0IEVycm9ycy5NTU5vdEFNZW1iZXJFcnJvcjoNCisJICAgIHNl bGYuQWRkRXJyb3IoIiVzIGlzbid0IHN1YnNjcmliZWQgdG8gdGhpcyBsaXN0 LiINCisJCQkgICUgbWFpbC5HZXRTZW5kZXIoKSkNCisJICAgIHJldHVybg0K KwlleGNlcHQgRXJyb3JzLk1NQmFkUGFzc3dvcmRFcnJvcjoNCisJICAgIHNl bGYuQWRkRXJyb3IoIllvdSBnYXZlIHRoZSB3cm9uZyBwYXNzd29yZC4iKQ0K IAlpZiBhcmdzWzBdID09ICdkaWdlc3QnOg0KIAkgICAgdHJ5Og0KLQkJc2Vu ZGVyID0gc2VsZi5GaW5kVXNlcihtYWlsLkdldFNlbmRlcigpKQ0KLQkJc2Vs Zi5Db25maXJtVXNlclBhc3N3b3JkKHNlbmRlciwgYXJnc1syXSkNCiAJCXNl bGYuU2V0VXNlckRpZ2VzdChtYWlsLkdldFNlbmRlcigpLCB2YWx1ZSkNCiAJ CXNlbGYuQWRkVG9SZXNwb25zZSgiU3VjY2VlZGVkLiIpDQogCSAgICBleGNl cHQgRXJyb3JzLk1NQWxyZWFkeURpZ2VzdGVkOg0KQEAgLTI1OCwxNiArMjY1 LDExIEBADQogCQlzZWxmLkFkZEVycm9yKCJMaXN0IG9ubHkgYWNjZXB0cyBk aWdlc3QgbWVtYmVycy4iKQ0KIAkgICAgZXhjZXB0IEVycm9ycy5NTUNhbnRE aWdlc3RFcnJvcjoNCiAJCXNlbGYuQWRkRXJyb3IoIkxpc3QgZG9lc24ndCBh Y2NlcHQgZGlnZXN0IG1lbWJlcnMuIikNCi0JICAgIGV4Y2VwdCBFcnJvcnMu TU1Ob3RBTWVtYmVyRXJyb3I6DQotCQlzZWxmLkFkZEVycm9yKCIlcyBpc24n dCBzdWJzY3JpYmVkIHRvIHRoaXMgbGlzdC4iDQotICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgJSBtYWlsLkdldFNlbmRlcigpKQ0KIAkgICAgZXhj ZXB0IEVycm9ycy5NTUxpc3ROb3RSZWFkeToNCiAJCXNlbGYuQWRkRXJyb3Io Ikxpc3QgaXMgbm90IGZ1bmN0aW9uYWwuIikNCiAJICAgIGV4Y2VwdCBFcnJv cnMuTU1Ob1N1Y2hVc2VyRXJyb3I6DQogCQlzZWxmLkFkZEVycm9yKCIlcyBp cyBub3Qgc3Vic2NyaWJlZCB0byB0aGlzIGxpc3QuIg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICUgbWFpbC5HZXRTZW5kZXIoKSkNCi0JICAg IGV4Y2VwdCBFcnJvcnMuTU1CYWRQYXNzd29yZEVycm9yOg0KLQkJc2VsZi5B ZGRFcnJvcigiWW91IGdhdmUgdGhlIHdyb25nIHBhc3N3b3JkLiIpDQogCSAg ICBleGNlcHQgRXJyb3JzLk1NTmVlZEFwcHJvdmFsOg0KIAkJc2VsZi5BZGRB cHByb3ZhbE1zZyhjbWQpDQogCSAgICBleGNlcHQ6DQpAQCAtMjc4LDExICsy ODAsNiBAQA0KIAkJc2VsZi5BZGRFcnJvcigiJXMiICUgc3lzLmV4Y190eXBl KQ0KIAllbGlmIG9wdGlvbl9pbmZvLmhhc19rZXkoYXJnc1swXSk6DQogCSAg ICB0cnk6DQotCQlzZW5kZXIgPSBzZWxmLkZpbmRVc2VyKG1haWwuR2V0U2Vu ZGVyKCkpDQotCQlpZiBub3Qgc2VuZGVyOg0KLQkJICAgIHNlbGYuQWRkRXJy b3IoIllvdSBhcmVuJ3Qgc3Vic2NyaWJlZC4iKQ0KLQkJICAgIHJldHVybg0K LQkJc2VsZi5Db25maXJtVXNlclBhc3N3b3JkKHNlbmRlciwgYXJnc1syXSkN CiAJCXNlbGYuU2V0VXNlck9wdGlvbihzZW5kZXIsIG9wdGlvbl9pbmZvW2Fy Z3NbMF1dLCB2YWx1ZSkNCiAJCXNlbGYuQWRkVG9SZXNwb25zZSgiU3VjY2Vl ZGVkLiIpDQogCSAgICBleGNlcHQgRXJyb3JzLk1NQmFkUGFzc3dvcmRFcnJv cjoNCg== ---456965764-233999344-915788868=:3512 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="mailman-2-cgiext.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="mailman-2-cgiext.patch" ZGlmZiAtcnVOIG1haWxtYW4tMS1jbWRoYW5kbGVyL01haWxtYW4vQXJjaGl2 ZXIvSHlwZXJBcmNoLnB5IG1haWxtYW4vTWFpbG1hbi9BcmNoaXZlci9IeXBl ckFyY2gucHkNCi0tLSBtYWlsbWFuLTEtY21kaGFuZGxlci9NYWlsbWFuL0Fy Y2hpdmVyL0h5cGVyQXJjaC5weQlTYXQgRGVjIDEyIDE5OjA0OjAwIDE5OTgN CisrKyBtYWlsbWFuL01haWxtYW4vQXJjaGl2ZXIvSHlwZXJBcmNoLnB5CUZy aSBKYW4gIDggMDk6MzA6MjIgMTk5OQ0KQEAgLTQzMiw3ICs0MzIsNyBAQA0K ICAgICBkZWYgaHRtbF9mb290KHNlbGYpOg0KIAlkID0geyJsYXN0ZGF0ZSI6 IGh0bWxfcXVvdGUoc2VsZi5sYXN0ZGF0ZSksDQogCSAgICAgImFyY2hpdmVk YXRlIjogaHRtbF9xdW90ZShzZWxmLmFyY2hpdmVkYXRlKSwNCi0JICAgICAi bGlzdGluZm8iOiBzZWxmLm1haWxsaXN0LkdldEFic29sdXRlU2NyaXB0VVJM KCdsaXN0aW5mbycpLA0KKwkgICAgICJsaXN0aW5mbyI6IHNlbGYubWFpbGxp c3QuR2V0QWJzb2x1dGVTY3JpcHRVUkwobW1fY2ZnLmxpc3RpbmZvX2NnaSks DQogCSAgICAgInZlcnNpb24iOiBzZWxmLnZlcnNpb259DQogCWZvciB0IGlu ICgidGhyZWFkIiwgInN1YmplY3QiLCAiYXV0aG9yIiwgImRhdGUiKToNCiAJ ICAgIGNhcCA9IHN0cmluZy51cHBlcih0WzBdKSArIHRbMTpdDQpAQCAtNDQ4 LDcgKzQ0OCw3IEBADQogCWQgPSB7Imxpc3RuYW1lIjogaHRtbF9xdW90ZShz ZWxmLm1haWxsaXN0LnJlYWxfbmFtZSksDQogCSAgICAgImFyY2h0eXBlIjog c2VsZi50eXBlLA0KIAkgICAgICJhcmNoaXZlIjogc2VsZi5hcmNoaXZlLA0K LQkgICAgICJsaXN0aW5mbyI6IHNlbGYubWFpbGxpc3QuR2V0QWJzb2x1dGVT Y3JpcHRVUkwoJ2xpc3RpbmZvJyksDQorCSAgICAgImxpc3RpbmZvIjogc2Vs Zi5tYWlsbGlzdC5HZXRBYnNvbHV0ZVNjcmlwdFVSTChtbV9jZmcubGlzdGlu Zm9fY2dpKSwNCiAJICAgICAiZmlyc3RkYXRlIjogaHRtbF9xdW90ZShzZWxm LmZpcnN0ZGF0ZSksDQogCSAgICAgImxhc3RkYXRlIjogaHRtbF9xdW90ZShz ZWxmLmxhc3RkYXRlKSwNCiAJICAgICAic2l6ZSI6IHNlbGYuc2l6ZSwNCkBA IC00NjYsNyArNDY2LDcgQEANCiANCiAgICAgZGVmIGh0bWxfVE9DKHNlbGYp Og0KICAgICAgICAgZCA9IHsibGlzdG5hbWUiOiBzZWxmLm1haWxsaXN0LnJl YWxfbmFtZSwNCi0gICAgICAgICAgICAgImxpc3RpbmZvIjogc2VsZi5tYWls bGlzdC5HZXRBYnNvbHV0ZVNjcmlwdFVSTCgnbGlzdGluZm8nKSB9DQorICAg ICAgICAgICAgICJsaXN0aW5mbyI6IHNlbGYubWFpbGxpc3QuR2V0QWJzb2x1 dGVTY3JpcHRVUkwobW1fY2ZnLmxpc3RpbmZvX2NnaSkgfQ0KICAgICAgICAg bGlzdGluZyA9ICIiDQogICAgICAgICBpZiBub3Qgc2VsZi5hcmNoaXZlczoN CiAgICAgICAgICAgICBkWyJub2FyY2hpdmVfbXNnIl0gPSAnPFA+Q3VycmVu dGx5LCB0aGVyZSBhcmUgbm8gYXJjaGl2ZXMuIDwvUD4nDQpkaWZmIC1ydU4g bWFpbG1hbi0xLWNtZGhhbmRsZXIvTWFpbG1hbi9Cb3VuY2VyLnB5IG1haWxt YW4vTWFpbG1hbi9Cb3VuY2VyLnB5DQotLS0gbWFpbG1hbi0xLWNtZGhhbmRs ZXIvTWFpbG1hbi9Cb3VuY2VyLnB5CVNhdCBEZWMgMTIgMTk6MDM6MjggMTk5 OA0KKysrIG1haWxtYW4vTWFpbG1hbi9Cb3VuY2VyLnB5CUZyaSBKYW4gIDgg MDk6MzA6MjIgMTk5OQ0KQEAgLTIxNSw3ICsyMTUsNyBAQA0KICAgICAgICAg ICAgIGlmIGRpZCA9PSAnZGlzYWJsZWQnIGFuZCBzdWNjZWVkZWQgPT0gMToN CiAgICAgICAgICAgICAgICAgcmVlbmFibGUgPSBVdGlscy5tYWtldGV4dCgN CiAgICAgICAgICAgICAgICAgICAgICdyZWVuYWJsZS50eHQnLA0KLSAgICAg ICAgICAgICAgICAgICAgeydhZG1pbl91cmwnOiBzZWxmLkdldEFic29sdXRl U2NyaXB0VVJMKCdhZG1pbicpLA0KKyAgICAgICAgICAgICAgICAgICAgeydh ZG1pbl91cmwnOiBzZWxmLkdldEFic29sdXRlU2NyaXB0VVJMKG1tX2NmZy5h ZG1pbl9jZ2kpLA0KICAgICAgICAgICAgICAgICAgICAgIH0pDQogICAgICAg ICAgICAgZWxzZToNCiAgICAgICAgICAgICAgICAgcmVlbmFibGUgPSAnJw0K ZGlmZiAtcnVOIG1haWxtYW4tMS1jbWRoYW5kbGVyL01haWxtYW4vQ2dpL2Fk bWluLnB5IG1haWxtYW4vTWFpbG1hbi9DZ2kvYWRtaW4ucHkNCi0tLSBtYWls bWFuLTEtY21kaGFuZGxlci9NYWlsbWFuL0NnaS9hZG1pbi5weQlGcmkgSmFu ICA4IDA5OjE4OjI3IDE5OTkNCisrKyBtYWlsbWFuL01haWxtYW4vQ2dpL2Fk bWluLnB5CUZyaSBKYW4gIDggMDk6MzA6MjIgMTk5OQ0KQEAgLTEyNCw3ICsx MjQsNyBAQA0KICAgICAgICAgICAgICAgICAnYWRtbG9naW4udHh0JywNCiAg ICAgICAgICAgICAgICAgeyJsaXN0bmFtZSI6IGxpc3RfbmFtZSwNCiAgICAg ICAgICAgICAgICAgICJwYXRoIiAgICA6IG9zLmVudmlyb24uZ2V0KCJSRVFV RVNUX1VSSSIsDQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAnL21haWxtYW4vYWRtaW4vJyArIGxpc3RfbmFtZSksDQor ICAgICAgICAgICAgICAgICAgICAgICAgICAgICcvbWFpbG1hbi8nICsgbW1f Y2ZnLmFkbWluX2NnaSArICcvJyArIGxpc3RfbmFtZSksDQogICAgICAgICAg ICAgICAgICAibWVzc2FnZSIgOiBtZXNzYWdlLA0KICAgICAgICAgICAgICAg ICAgfSkNCiAgICAgICAgICAgICBwcmludCB0ZXh0DQpAQCAtMjE3LDcgKzIx Nyw4IEBADQogICAgICAgICAgICAgICAgICAgICAgICAlICgoZXJyb3IgYW5k ICJ0aGUgcmlnaHQgIikgb3IgIiIpKQ0KICAgICAgICAgICAgICAgICAgICAg ICArDQogICAgICAgICAgICAgICAgICAgICAgICIgR2VuZXJhbCBsaXN0IGlu Zm9ybWF0aW9uIGNhbiBiZSBmb3VuZCBhdCAiLA0KLSAgICAgICAgICAgICAg ICAgICAgICBMaW5rKCIlc2xpc3RpbmZvIiAlICgnLi4vJyAqIFV0aWxzLkdl dE5lc3RpbmdMZXZlbCgpKSwgDQorICAgICAgICAgICAgICAgICAgICAgIExp bmsoIiVzJXMiICUgKCcuLi8nICogVXRpbHMuR2V0TmVzdGluZ0xldmVsKCks DQorCQkgICAgICAgICAgbW1fY2ZnLmxpc3RpbmZvX2NnaSksIA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICJ0aGUgbWFpbGluZyBsaXN0IG92ZXJ2 aWV3IHBhZ2UiKSwNCiAgICAgICAgICAgICAgICAgICAgICAgIi4iDQogICAg ICAgICAgICAgICAgICAgICAgICI8cD4oU2VuZCBxdWVzdGlvbnMgYW5kIGNv bW1lbnRzIHRvICIsDQpAQCAtMjMzLDcgKzIzNCw3IEBADQogICAgIGlmIGFk dmVydGlzZWQ6DQogICAgICAgICB0YWJsZS5BZGRSb3coW0l0YWxpYygiTGlz dCIpLCBJdGFsaWMoIkRlc2NyaXB0aW9uIildKQ0KICAgICAgICAgZm9yIGwg aW4gYWR2ZXJ0aXNlZDoNCi0gICAgICAgICAgICB0YWJsZS5BZGRSb3coW0xp bmsobC5HZXRSZWxhdGl2ZVNjcmlwdFVSTCgnYWRtaW4nKSwgDQorICAgICAg ICAgICAgdGFibGUuQWRkUm93KFtMaW5rKGwuR2V0UmVsYXRpdmVTY3JpcHRV UkwobW1fY2ZnLmFkbWluX2NnaSksIA0KIAkgICAgICAgICAgICAgICAgICBC b2xkKGwucmVhbF9uYW1lKSksbC5kZXNjcmlwdGlvbl0pDQogDQogICAgIGRv Yy5BZGRJdGVtKHRhYmxlKQ0KQEAgLTI1NSwxMyArMjU2LDEzIEBADQogICAg IGxpbmtzX3RhYmxlLkFkZFJvdyhbQ2VudGVyKEJvbGQoIkNvbmZpZ3VyYXRp b24gQ2F0ZWdvcmllcyIpKSwNCiAgICAgICAgICAgICAgICAgICAgICAgICBD ZW50ZXIoQm9sZCgiT3RoZXIgQWRtaW5pc3RyYXRpdmUgQWN0aXZpdGllcyIp KV0pDQogICAgIG90aGVyX2xpbmtzID0gVW5vcmRlcmVkTGlzdCgpDQotICAg IGxpbmsgPSBMaW5rKGxzdC5HZXRSZWxhdGl2ZVNjcmlwdFVSTCgnYWRtaW5k YicpLCANCisgICAgbGluayA9IExpbmsobHN0LkdldFJlbGF0aXZlU2NyaXB0 VVJMKG1tX2NmZy5hZG1pbmRiX2NnaSksIA0KICAgICAgICAgICAgICAgICAn VGVuZCB0byBwZW5kaW5nIGFkbWluaXN0cmF0aXZlIHJlcXVlc3RzLicpDQog ICAgIG90aGVyX2xpbmtzLkFkZEl0ZW0obGluaykNCi0gICAgbGluayA9IExp bmsobHN0LkdldFJlbGF0aXZlU2NyaXB0VVJMKCdsaXN0aW5mbycpLA0KKyAg ICBsaW5rID0gTGluayhsc3QuR2V0UmVsYXRpdmVTY3JpcHRVUkwobW1fY2Zn Lmxpc3RpbmZvX2NnaSksDQogICAgICAgICAgICAgICAgICdHbyB0byB0aGUg Z2VuZXJhbCBsaXN0IGluZm9ybWF0aW9uIHBhZ2UuJykNCiAgICAgb3RoZXJf bGlua3MuQWRkSXRlbShsaW5rKQ0KLSAgICBsaW5rID0gTGluayhsc3QuR2V0 UmVsYXRpdmVTY3JpcHRVUkwoJ2VkaXRodG1sJyksDQorICAgIGxpbmsgPSBM aW5rKGxzdC5HZXRSZWxhdGl2ZVNjcmlwdFVSTChtbV9jZmcuZWRpdGh0bWxf Y2dpKSwNCiAgICAgICAgICAgICAgICAgJ0VkaXQgdGhlIEhUTUwgZm9yIHRo ZSBwdWJsaWMgbGlzdCBwYWdlcy4nKQ0KICAgICBvdGhlcl9saW5rcy5BZGRJ dGVtKGxpbmspDQogDQpAQCAtMjcxLDcgKzI3Miw3IEBADQogICAgICAgICAg ICAgdGhlc2VfbGlua3MuQWRkSXRlbSgiPGI+ID0mZ3Q7ICIgKyB2ICsgIiAm bHQ7PSA8L2I+IikNCiAgICAgICAgIGVsc2U6DQogICAgICAgICAgICAgdGhl c2VfbGlua3MuQWRkSXRlbShMaW5rKCIlcy8lcyIgJSANCi0JICAgICAgICAg ICAgICAgICAobHN0LkdldFJlbGF0aXZlU2NyaXB0VVJMKCdhZG1pbicpLGsp LHYpKQ0KKwkgICAgICAgICAgICAgICAgIChsc3QuR2V0UmVsYXRpdmVTY3Jp cHRVUkwobW1fY2ZnLmFkbWluX2NnaSksayksdikpDQogDQogICAgIGxpbmtz X3RhYmxlLkFkZFJvdyhbdGhlc2VfbGlua3MsIG90aGVyX2xpbmtzXSkNCiAg ICAgbGlua3NfdGFibGUuQWRkUm93SW5mbyhtYXgobGlua3NfdGFibGUuR2V0 Q3VycmVudFJvd0luZGV4KCksIDApLA0KQEAgLTI4MCwxMCArMjgxLDEwIEBA DQogICAgIGRvYy5BZGRJdGVtKGxpbmtzX3RhYmxlKQ0KICAgICBkb2MuQWRk SXRlbSgnPGhyPicpDQogICAgIGlmIGNhdGVnb3J5X3N1ZmZpeDoNCi0gICAg ICAgIGZvcm0gPSBGb3JtKCIlcy8lcyIgJSAobHN0LkdldFJlbGF0aXZlU2Ny aXB0VVJMKCdhZG1pbicpLA0KKyAgICAgICAgZm9ybSA9IEZvcm0oIiVzLyVz IiAlIChsc3QuR2V0UmVsYXRpdmVTY3JpcHRVUkwobW1fY2ZnLmFkbWluX2Nn aSksDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNhdGVn b3J5X3N1ZmZpeCkpDQogICAgIGVsc2U6DQotICAgICAgICBmb3JtID0gRm9y bShsc3QuR2V0UmVsYXRpdmVTY3JpcHRVUkwoJ2FkbWluJykpDQorICAgICAg ICBmb3JtID0gRm9ybShsc3QuR2V0UmVsYXRpdmVTY3JpcHRVUkwobW1fY2Zn LmFkbWluX2NnaSkpDQogICAgIGRvYy5BZGRJdGVtKGZvcm0pDQogDQogICAg IGZvcm0uQWRkSXRlbSgiTWFrZSB5b3VyIGNoYW5nZXMgYmVsb3csIGFuZCB0 aGVuIHN1Ym1pdCB0aGVtIHVzaW5nIHRoZSINCkBAIC00MDIsNyArNDAzLDcg QEANCiAgICAgZG9jLkFkZEl0ZW0oIjxiPiVzPC9iPiAoJXMpOiAlczxwPiIg JSAodmFybmFtZSwgY2F0ZWdvcnksIGl0ZW1bNF0pKQ0KICAgICBkb2MuQWRk SXRlbSgiJXM8cD4iICUgaXRlbVs1XSkNCiANCi0gICAgZm9ybSA9IEZvcm0o IiVzLyVzIiAlIChsc3QuR2V0UmVsYXRpdmVTY3JpcHRVUkwoJ2FkbWluJyks IGNhdGVnb3J5KSkNCisgICAgZm9ybSA9IEZvcm0oIiVzLyVzIiAlIChsc3Qu R2V0UmVsYXRpdmVTY3JpcHRVUkwobW1fY2ZnLmFkbWluX2NnaSksIGNhdGVn b3J5KSkNCiAgICAgdmFsdGFiID0gVGFibGUoY2VsbHNwYWNpbmc9MywgY2Vs bHBhZGRpbmc9NCkNCiAgICAgQWRkT3B0aW9uc1RhYmxlSXRlbSh2YWx0YWIs IGl0ZW0sIGNhdGVnb3J5LCBsc3QsIG5vZGV0YWlscz0xKQ0KICAgICBmb3Jt LkFkZEl0ZW0odmFsdGFiKQ0KQEAgLTUxMiw3ICs1MTMsNyBAQA0KICAgICAg ICAgYnV0dG9ucyA9IFtdDQogICAgICAgICBmb3IgY2kgaW4gY2h1bmtfaW5k aWNlczoNCiAgICAgICAgICAgICBzdGFydCwgZW5kID0gY2h1bmtzW2NpXVsw XSwgY2h1bmtzW2NpXVstMV0NCi0JICAgIHVybCA9IGxzdC5HZXRBYnNvbHV0 ZVNjcmlwdFVSTCgnYWRtaW4nKQ0KKwkgICAgdXJsID0gbHN0LkdldEFic29s dXRlU2NyaXB0VVJMKG1tX2NmZy5hZG1pbl9jZ2kpDQogICAgICAgICAgICAg YnV0dG9ucy5hcHBlbmQoIjxhIGhyZWY9JXMvbWVtYmVycz9jaHVuaz0lZD4g ZnJvbSAlcyB0byAlcyA8L2E+Ig0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICUgKCB1cmwsICBjaSwgc3RhcnQsIGVuZCkpDQogICAgICAgICBidXR0 b25zID0gYXBwbHkoVW5vcmRlcmVkTGlzdCwgdHVwbGUoYnV0dG9ucykpDQpk aWZmIC1ydU4gbWFpbG1hbi0xLWNtZGhhbmRsZXIvTWFpbG1hbi9DZ2kvYWRt aW5kYi5weSBtYWlsbWFuL01haWxtYW4vQ2dpL2FkbWluZGIucHkNCi0tLSBt YWlsbWFuLTEtY21kaGFuZGxlci9NYWlsbWFuL0NnaS9hZG1pbmRiLnB5CUZy aSBKYW4gIDggMDk6MTg6MjggMTk5OQ0KKysrIG1haWxtYW4vTWFpbG1hbi9D Z2kvYWRtaW5kYi5weQlGcmkgSmFuICA4IDA5OjMxOjQ4IDE5OTkNCkBAIC0x MTMsNyArMTEzLDcgQEANCiAgICAgICAgICAgICAgICAgJ2FkbWxvZ2luLnR4 dCcsDQogICAgICAgICAgICAgICAgIHsnbGlzdG5hbWUnOiBsaXN0X25hbWUs DQogICAgICAgICAgICAgICAgICAncGF0aCcgICAgOiBvcy5lbnZpcm9uLmdl dCgnUkVRVUVTVF9VUkknLA0KLSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgJy9tYWlsbWFuL2FkbWluLycgKyBsaXN0X25h bWUpLA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJy9tYWlsbWFu LycgKyBtbV9jZmcuYWRtaW5fY2dpICsgJy8nICsgbGlzdF9uYW1lKSwNCiAg ICAgICAgICAgICAgICAgICdtZXNzYWdlJyA6IG1lc3NhZ2UsDQogICAgICAg ICAgICAgICAgICB9KQ0KICAgICAgICAgICAgIHByaW50IHRleHQNCkBAIC0y NTAsNiArMjUwLDcgQEANCiANCiAMDQogZGVmIFByaW50UmVxdWVzdHMoZG9j KToNCisgICAgaW1wb3J0IG1tX2NmZw0KICAgICAjIFhYWDogWXVrLCBibGVj aCwgaWNrDQogICAgIGdsb2JhbCBsaXN0DQogICAgIGdsb2JhbCBmb3JtDQpA QCAtMjYyLDcgKzI2Myw3IEBADQogICAgIGRvYy5BZGRJdGVtKEhlYWRlcigy LCAiQWRtaW5pc3RyYXRpdmUgcmVxdWVzdHMgZm9yICclcycgbWFpbGluZyBs aXN0Ig0KICAgICAgICAgICAgICAgICAgICAgICAgJSBsaXN0LnJlYWxfbmFt ZSkpDQogICAgIGRvYy5BZGRJdGVtKEZvbnRTaXplKCIrMSIsDQotICAgICAg ICAgICAgICAgICAgICAgICAgIExpbmsobGlzdC5HZXRSZWxhdGl2ZVNjcmlw dFVSTCgnYWRtaW4nKSwNCisgICAgICAgICAgICAgICAgICAgICAgICAgTGlu ayhsaXN0LkdldFJlbGF0aXZlU2NyaXB0VVJMKG1tX2NmZy5hZG1pbl9jZ2kp LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEl0YWxpYygNCiAg ICAgICAgICdWaWV3IG9yIGVkaXQgdGhlIGxpc3QgY29uZmlndXJhdGlvbiBp bmZvcm1hdGlvbicpKSkpDQogICAgIGRvYy5BZGRJdGVtKCc8cD4nKQ0KQEAg LTI3MCw3ICsyNzEsNyBAQA0KIAlkb2MuQWRkSXRlbShIZWFkZXIoMywnVGhl cmUgYXJlIG5vIHBlbmRpbmcgcmVxdWVzdHMuJykpDQogCWRvYy5BZGRJdGVt KGxpc3QuR2V0TWFpbG1hbkZvb3RlcigpKQ0KIAlyZXR1cm4NCi0gICAgZm9y bSA9IEZvcm0obGlzdC5HZXRSZWxhdGl2ZVNjcmlwdFVSTCgnYWRtaW5kYicp KQ0KKyAgICBmb3JtID0gRm9ybShsaXN0LkdldFJlbGF0aXZlU2NyaXB0VVJM KG1tX2NmZy5hZG1pbmRiX2NnaSkpDQogICAgIGRvYy5BZGRJdGVtKGZvcm0p DQogIyMgICAgZm9ybS5BZGRJdGVtKCdBZG1pbiBwYXNzd29yZDogJykNCiAj IyAgICBmb3JtLkFkZEl0ZW0oUGFzc3dvcmRCb3goJ2FkbWlucHcnKSkNCmRp ZmYgLXJ1TiBtYWlsbWFuLTEtY21kaGFuZGxlci9NYWlsbWFuL0NnaS9lZGl0 aHRtbC5weSBtYWlsbWFuL01haWxtYW4vQ2dpL2VkaXRodG1sLnB5DQotLS0g bWFpbG1hbi0xLWNtZGhhbmRsZXIvTWFpbG1hbi9DZ2kvZWRpdGh0bWwucHkJ TW9uIE5vdiAxNiAwMjo0Njo0NyAxOTk4DQorKysgbWFpbG1hbi9NYWlsbWFu L0NnaS9lZGl0aHRtbC5weQlGcmkgSmFuICA4IDA5OjMwOjIyIDE5OTkNCkBA IC0yMyw3ICsyMyw3IEBADQogZnJvbSBNYWlsbWFuIGltcG9ydCBVdGlscywg TWFpbExpc3QNCiBmcm9tIE1haWxtYW4gaW1wb3J0IGh0bWxmb3JtYXQNCiBm cm9tIE1haWxtYW4uSFRNTEZvcm1hdHRlciBpbXBvcnQgSFRNTEZvcm1hdHRl cg0KLWZyb20gTWFpbG1hbiBpbXBvcnQgRXJyb3JzDQorZnJvbSBNYWlsbWFu IGltcG9ydCBFcnJvcnMsIG1tX2NmZw0KIA0KIA0KICNFZGl0YWJsZSB0ZW1w bGF0ZXMuICBXZSBzaG91bGQgYWxzbyBiZSBhYmxlIHRvIGVkaXQgdGhlIGFy Y2hpdmUgaW5kZXgsIHdoaWNoIA0KQEAgLTkyLDggKzkyLDggQEANCiAgICAg ICAgIGRvYy5BZGRJdGVtKGh0bWxmb3JtYXQuSGVhZGVyKDIsICdTZWxlY3Qg cGFnZSB0byBlZGl0OicpKQ0KICAgICAgICAgdGVtcGxhdGVfbGlzdCA9IGh0 bWxmb3JtYXQuVW5vcmRlcmVkTGlzdCgpDQogICAgICAgICBmb3IgKHRlbXBs YXRlLCBpbmZvKSBpbiB0ZW1wbGF0ZV9kYXRhOg0KLSAgICAgICAgICAgIGwg PSBodG1sZm9ybWF0LkxpbmsoIiVzLyVzIiAlIChsaXN0LkdldFJlbGF0aXZl U2NyaXB0VVJMKCdlZGl0aHRtbCcpLHRlbXBsYXRlKSwNCi0gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGluZm8pDQorICAgICAgICAgICAgbCA9 IGh0bWxmb3JtYXQuTGluaygiJXMvJXMiICUNCisJCShsaXN0LkdldFJlbGF0 aXZlU2NyaXB0VVJMKG1tX2NmZy5lZGl0aHRtbF9jZ2kpLHRlbXBsYXRlKSwg aW5mbykNCiAgICAgICAgICAgICB0ZW1wbGF0ZV9saXN0LkFkZEl0ZW0obCkN CiAgICAgICAgIGRvYy5BZGRJdGVtKGh0bWxmb3JtYXQuRm9udFNpemUoIisy IiwgdGVtcGxhdGVfbGlzdCkpDQogICAgICAgICBkb2MuQWRkSXRlbShsaXN0 LkdldE1haWxtYW5Gb290ZXIoKSkNCkBAIC0xNTAsMTQgKzE1MCwxNCBAQA0K IA0KICAgICBkb2MuQWRkSXRlbSgnPGhyPicpDQogDQotICAgIGxpbmsgPSBo dG1sZm9ybWF0LkxpbmsobGlzdC5HZXRSZWxhdGl2ZVNjcmlwdFVSTCgnYWRt aW4nKSwNCisgICAgbGluayA9IGh0bWxmb3JtYXQuTGluayhsaXN0LkdldFJl bGF0aXZlU2NyaXB0VVJMKG1tX2NmZy5hZG1pbl9jZ2kpLA0KIAkJCSAgICdW aWV3IG9yIGVkaXQgdGhlIGxpc3QgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlv bi4nKQ0KICAgICBkb2MuQWRkSXRlbShodG1sZm9ybWF0LkZvbnRTaXplKCIr MSIsIGxpbmspKQ0KICAgICBkb2MuQWRkSXRlbSgnPHA+JykNCiANCiAgICAg ZG9jLkFkZEl0ZW0oJzxocj4nKQ0KIA0KLSAgICBmb3JtID0gaHRtbGZvcm1h dC5Gb3JtKCIlcy8lcyIgJSAobGlzdC5HZXRSZWxhdGl2ZVNjcmlwdFVSTCgn ZWRpdGh0bWwnKSwNCisgICAgZm9ybSA9IGh0bWxmb3JtYXQuRm9ybSgiJXMv JXMiICUgKGxpc3QuR2V0UmVsYXRpdmVTY3JpcHRVUkwobW1fY2ZnLmVkaXRo dG1sX2NnaSksDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB0ZW1wbGF0ZV9uYW1lKSkNCiAgICAgZG9jLkFkZEl0ZW0oZm9ybSkN CiANCmRpZmYgLXJ1TiBtYWlsbWFuLTEtY21kaGFuZGxlci9NYWlsbWFuL0Nn aS9saXN0aW5mby5weSBtYWlsbWFuL01haWxtYW4vQ2dpL2xpc3RpbmZvLnB5 DQotLS0gbWFpbG1hbi0xLWNtZGhhbmRsZXIvTWFpbG1hbi9DZ2kvbGlzdGlu Zm8ucHkJRnJpIEphbiAgOCAwOToxODoyOSAxOTk5DQorKysgbWFpbG1hbi9N YWlsbWFuL0NnaS9saXN0aW5mby5weQlGcmkgSmFuICA4IDA5OjMwOjIyIDE5 OTkNCkBAIC0xMjcsNyArMTI3LDggQEANCiAgICAgICAgICAgICAgICAgICAg ICAgICUgKChlcnJvciBhbmQgInJpZ2h0ICIpIG9yICIiKSkNCiAgICAgICAg ICAgICAgICAgICAgICAgKw0KICAgICAgICAgICAgICAgICAgICAgICAnPHA+ IExpc3QgYWRtaW5pc3RyYXRvcnMsIHlvdSBjYW4gdmlzaXQgJywNCi0gICAg ICAgICAgICAgICAgICAgICAgTGluaygiJXNhZG1pbi8iICUgKCcuLi8nICog VXRpbHMuR2V0TmVzdGluZ0xldmVsKCkpLA0KKyAgICAgICAgICAgICAgICAg ICAgICBMaW5rKCIlcyVzLyIgJSAoJy4uLycgKiBVdGlscy5HZXROZXN0aW5n TGV2ZWwoKSwNCisJCSAgICAgICAgICBtbV9jZmcuYWRtaW5fY2dpKSwNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAidGhlIGxpc3QgYWRtaW4gb3Zl cnZpZXcgcGFnZSIpLA0KICAgICAgICAgICAgICAgICAgICAgICAiIHRvIGZp bmQgdGhlIG1hbmFnZW1lbnQgaW50ZXJmYWNlIGZvciB5b3VyIGxpc3QuIg0K ICAgICAgICAgICAgICAgICAgICAgICAiPHA+KFNlbmQgcXVlc3Rpb25zIG9y IGNvbW1lbnRzIHRvICIsDQpAQCAtMTQxLDcgKzE0Miw3IEBADQogICAgIGlm IGFkdmVydGlzZWQ6DQogICAgICAgICB0YWJsZS5BZGRSb3coW0l0YWxpYygi TGlzdCIpLCBJdGFsaWMoIkRlc2NyaXB0aW9uIildKQ0KICAgICBmb3IgbCBp biBhZHZlcnRpc2VkOg0KLSAgICAgICAgdGFibGUuQWRkUm93KFtMaW5rKGwu R2V0UmVsYXRpdmVTY3JpcHRVUkwoJ2xpc3RpbmZvJyksIA0KKyAgICAgICAg dGFibGUuQWRkUm93KFtMaW5rKGwuR2V0UmVsYXRpdmVTY3JpcHRVUkwobW1f Y2ZnLmxpc3RpbmZvX2NnaSksIA0KIAkgICAgICBCb2xkKGwucmVhbF9uYW1l KSksIGwuZGVzY3JpcHRpb25dKQ0KIA0KICAgICBkb2MuQWRkSXRlbSh0YWJs ZSkNCkBAIC0xNzAsOCArMTcxLDggQEANCiAgICAgcmVwbGFjZW1lbnRzWyc8 bW0tbmV3LXBhc3N3b3JkLWJveD4nXSA9IGxpc3QuRm9ybWF0U2VjdXJlQm94 KCdwdycpDQogICAgIHJlcGxhY2VtZW50c1snPG1tLWNvbmZpcm0tcGFzc3dv cmQ+J10gPSBsaXN0LkZvcm1hdFNlY3VyZUJveCgncHctY29uZicpDQogICAg IHJlcGxhY2VtZW50c1snPG1tLXN1YnNjcmliZS1mb3JtLXN0YXJ0PiddID0g XA0KLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBsaXN0LkZvcm1hdEZvcm1TdGFydCgnc3Vic2NyaWJlJykNCi0gICAg cmVwbGFjZW1lbnRzWyc8bW0tcm9zdGVyLWZvcm0tc3RhcnQ+J10gPSBsaXN0 LkZvcm1hdEZvcm1TdGFydCgncm9zdGVyJykNCisgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbGlzdC5Gb3JtYXRGb3Jt U3RhcnQobW1fY2ZnLnN1YnNjcmliZV9jZ2kpDQorICAgIHJlcGxhY2VtZW50 c1snPG1tLXJvc3Rlci1mb3JtLXN0YXJ0PiddID0gbGlzdC5Gb3JtYXRGb3Jt U3RhcnQobW1fY2ZnLnJvc3Rlcl9jZ2kpDQogICAgIHJlcGxhY2VtZW50c1sn PG1tLWVkaXRpbmctb3B0aW9ucz4nXSA9IGxpc3QuRm9ybWF0RWRpdGluZ09w dGlvbigpDQogICAgIHJlcGxhY2VtZW50c1snPG1tLWluZm8tYnV0dG9uPidd ID0gU3VibWl0QnV0dG9uKCdVc2VyT3B0aW9ucycsDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICdFZGl0 IE9wdGlvbnMnKS5Gb3JtYXQoKQ0KZGlmZiAtcnVOIG1haWxtYW4tMS1jbWRo YW5kbGVyL01haWxtYW4vQ2dpL29wdGlvbnMucHkgbWFpbG1hbi9NYWlsbWFu L0NnaS9vcHRpb25zLnB5DQotLS0gbWFpbG1hbi0xLWNtZGhhbmRsZXIvTWFp bG1hbi9DZ2kvb3B0aW9ucy5weQlUaHUgRGVjIDE3IDExOjAwOjE3IDE5OTgN CisrKyBtYWlsbWFuL01haWxtYW4vQ2dpL29wdGlvbnMucHkJRnJpIEphbiAg OCAwOTozMDoyMiAxOTk5DQpAQCAtMTIyLDcgKzEyMiw3IEBADQogICAgICAg ICAgICAgICAgICAgICAgICAgICAnTGlzdCBteSBvdGhlciBzdWJzY3JpcHRp b25zJykpDQogICAgIHJlcGxhY2VtZW50c1snPG1tLWNoYW5nZS1wYXNzLWJ1 dHRvbj4nXSA9ICgNCiAgICAgICAgIGxpc3QuRm9ybWF0QnV0dG9uKCdjaGFu Z2VwdycsICJDaGFuZ2UgTXkgUGFzc3dvcmQiKSkNCi0gICAgcmVwbGFjZW1l bnRzWyc8bW0tZm9ybS1zdGFydD4nXSA9IGxpc3QuRm9ybWF0Rm9ybVN0YXJ0 KCdoYW5kbGVfb3B0cycsIHVzZXIpDQorICAgIHJlcGxhY2VtZW50c1snPG1t LWZvcm0tc3RhcnQ+J10gPSBsaXN0LkZvcm1hdEZvcm1TdGFydChtbV9jZmcu aGFuZGxlX29wdHNfY2dpLCB1c2VyKQ0KICAgICByZXBsYWNlbWVudHNbJzxt bS11c2VyPiddID0gdXNlcg0KICAgICByZXBsYWNlbWVudHNbJzxtbS1wcmVz ZW50YWJsZS11c2VyPiddID0gcHJlc2VudGFibGVfdXNlcg0KICAgICByZXBs YWNlbWVudHNbJzxtbS1lbWFpbC1teS1wdz4nXSA9IGxpc3QuRm9ybWF0QnV0 dG9uKCdlbWFpbHB3JywNCmRpZmYgLXJ1TiBtYWlsbWFuLTEtY21kaGFuZGxl ci9NYWlsbWFuL0RlZmF1bHRzLnB5LmluIG1haWxtYW4vTWFpbG1hbi9EZWZh dWx0cy5weS5pbg0KLS0tIG1haWxtYW4tMS1jbWRoYW5kbGVyL01haWxtYW4v RGVmYXVsdHMucHkuaW4JRnJpIEphbiAgOCAwOToxODowNiAxOTk5DQorKysg bWFpbG1hbi9NYWlsbWFuL0RlZmF1bHRzLnB5LmluCUZyaSBKYW4gIDggMDk6 MzA6MjIgMTk5OQ0KQEAgLTI4MywxMyArMjgzLDE1IEBADQogIyBEYXRhIGZp bGUgdmVyc2lvbiBudW1iZXINCiBEQVRBX0ZJTEVfVkVSU0lPTiA9IDEzDQog DQorIyBDR0kgZmlsZXMNCiANCi0NCi0NCi0NCi0NCi0NCi0NCi0NCi0NCi0N CithZG1pbl9jZ2kJPSAiYWRtaW5AQ0dJRVhUQCINCithZG1pbmRiX2NnaQk9 ICJhZG1pbmRiQENHSUVYVEAiDQorYXJjaGl2ZV9jZ2kJPSAiYXJjaGl2ZUBD R0lFWFRAIg0KK2VkaXRodG1sX2NnaQk9ICJlZGl0aHRtbEBDR0lFWFRAIg0K K2hhbmRsZV9vcHRzX2NnaQk9ICJoYW5kbGVfb3B0c0BDR0lFWFRAIg0KK2xp c3RpbmZvX2NnaQk9ICJsaXN0aW5mb0BDR0lFWFRAIg0KK29wdGlvbnNfY2dp CT0gIm9wdGlvbnNAQ0dJRVhUQCINCityb3N0ZXJfY2dpCT0gInJvc3RlckBD R0lFWFRAIg0KK3N1YnNjcmliZV9jZ2kJPSAic3Vic2NyaWJlQENHSUVYVEAi DQorcHJpdmF0ZV9jZ2kJPSAicHJpdmF0ZUBDR0lFWFRAIg0KZGlmZiAtcnVO IG1haWxtYW4tMS1jbWRoYW5kbGVyL01haWxtYW4vRGVsaXZlcmVyLnB5IG1h aWxtYW4vTWFpbG1hbi9EZWxpdmVyZXIucHkNCi0tLSBtYWlsbWFuLTEtY21k aGFuZGxlci9NYWlsbWFuL0RlbGl2ZXJlci5weQlGcmkgSmFuICA4IDA5OjE4 OjA2IDE5OTkNCisrKyBtYWlsbWFuL01haWxtYW4vRGVsaXZlcmVyLnB5CUZy aSBKYW4gIDggMDk6MzA6MjIgMTk5OQ0KQEAgLTIwNiw3ICsyMDYsNyBAQA0K ICAgICAgICAgICAgICdwb3N0YWNrLnR4dCcsDQogICAgICAgICAgICAgeydz dWJqZWN0JyAgICAgOiBzdWJqZWN0LA0KICAgICAgICAgICAgICAnbGlzdG5h bWUnICAgIDogc2VsZi5yZWFsX25hbWUsDQotICAgICAgICAgICAgICdsaXN0 aW5mb191cmwnOiBzZWxmLkdldEFic29sdXRlU2NyaXB0VVJMKCdsaXN0aW5m bycpLA0KKyAgICAgICAgICAgICAnbGlzdGluZm9fdXJsJzogc2VsZi5HZXRB YnNvbHV0ZVNjcmlwdFVSTChtbV9jZmcubGlzdGluZm9fY2dpKSwNCiAgICAg ICAgICAgICAgfSkNCiAJc2VsZi5TZW5kVGV4dFRvVXNlcignJXMgcG9zdCBh Y2tub3dsZWdlbWVudCcgJSBzZWxmLnJlYWxfbmFtZSwNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgYm9keSwgc2VuZGVyKQ0KQEAgLTIzMyw3ICsy MzMsNyBAQA0KICAgICAgICAgICAgICAnd2VsY29tZScgICAgIDogd2VsY29t ZSwNCiAgICAgICAgICAgICAgJ3VtYnJlbGxhJyAgICA6IHVtYnJlbGxhLA0K ICAgICAgICAgICAgICAnZW1haWxhZGRyJyAgIDogc2VsZi5HZXRMaXN0RW1h aWwoKSwNCi0gICAgICAgICAgICAgJ2xpc3RpbmZvX3VybCc6IHNlbGYuR2V0 QWJzb2x1dGVTY3JpcHRVUkwoJ2xpc3RpbmZvJyksDQorICAgICAgICAgICAg ICdsaXN0aW5mb191cmwnOiBzZWxmLkdldEFic29sdXRlU2NyaXB0VVJMKG1t X2NmZy5saXN0aW5mb19jZ2kpLA0KICAgICAgICAgICAgICAnb3B0aW9uc3Vy bCcgIDogc2VsZi5HZXRBYnNvbHV0ZU9wdGlvbnNVUkwobmFtZSksDQogICAg ICAgICAgICAgICdwYXNzd29yZCcgICAgOiBwYXNzd29yZCwNCiAgICAgICAg ICAgICAgfSkNCmRpZmYgLXJ1TiBtYWlsbWFuLTEtY21kaGFuZGxlci9NYWls bWFuL0RpZ2VzdGVyLnB5IG1haWxtYW4vTWFpbG1hbi9EaWdlc3Rlci5weQ0K LS0tIG1haWxtYW4tMS1jbWRoYW5kbGVyL01haWxtYW4vRGlnZXN0ZXIucHkJ U2F0IERlYyAxMiAxOTowMzozNCAxOTk4DQorKysgbWFpbG1hbi9NYWlsbWFu L0RpZ2VzdGVyLnB5CUZyaSBKYW4gIDggMDk6MzA6MjIgMTk5OQ0KQEAgLTMz Miw3ICszMzIsNyBAQA0KICAgICAgICAgICAgIHN1YnN0cyA9IHt9DQogICAg ICAgICAgICAgc3Vic3RzLnVwZGF0ZShsc3QuX19kaWN0X18pDQogICAgICAg ICAgICAgc3Vic3RzLnVwZGF0ZSh7J2dvdF9saXN0aW5mb191cmwnOiANCi0g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbHN0Lkdl dEFic29sdXRlU2NyaXB0VVJMKCdsaXN0aW5mbycpLA0KKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsc3QuR2V0QWJzb2x1dGVT Y3JpcHRVUkwobW1fY2ZnLmxpc3RpbmZvX2NnaSksDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgJ2dvdF9yZXF1ZXN0X2VtYWlsJzogbHN0LkdldFJl cXVlc3RFbWFpbCgpLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICdn b3RfbGlzdF9lbWFpbCc6IGxzdC5HZXRMaXN0RW1haWwoKSwNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAnZ290X293bmVyX2VtYWlsJzogbHN0Lkdl dEFkbWluRW1haWwoKSwNCmRpZmYgLXJ1TiBtYWlsbWFuLTEtY21kaGFuZGxl ci9NYWlsbWFuL0hUTUxGb3JtYXR0ZXIucHkgbWFpbG1hbi9NYWlsbWFuL0hU TUxGb3JtYXR0ZXIucHkNCi0tLSBtYWlsbWFuLTEtY21kaGFuZGxlci9NYWls bWFuL0hUTUxGb3JtYXR0ZXIucHkJVGh1IERlYyAxNyAxMTowMDoxMyAxOTk4 DQorKysgbWFpbG1hbi9NYWlsbWFuL0hUTUxGb3JtYXR0ZXIucHkJRnJpIEph biAgOCAwOTozMDoyMiAxOTk5DQpAQCAtODgsNyArODgsNyBAQA0KICAJZWxz ZToNCiAgCSAgICBjb25jZWFsZWQgPSAiIg0KICAgICAgICAgT2JzY3VyZUVt YWlsID0gVXRpbHMuT2JzY3VyZUVtYWlsDQotICAgICAgICBvcHRpb25zX3Vy bCA9IHNlbGYuR2V0UmVsYXRpdmVTY3JpcHRVUkwoJ29wdGlvbnMnKQ0KKyAg ICAgICAgb3B0aW9uc191cmwgPSBzZWxmLkdldFJlbGF0aXZlU2NyaXB0VVJM KG1tX2NmZy5vcHRpb25zX2NnaSkNCiAgICAgICAgIGRpc2RlbCA9IG1tX2Nm Zy5EaXNhYmxlRGVsaXZlcnkNCiAgICAgICAgIGl0ZW1zID0gW10NCiAgICAg ICAgIGZvciBwZXJzb24gaW4gcGVvcGxlOg0KZGlmZiAtcnVOIG1haWxtYW4t MS1jbWRoYW5kbGVyL01haWxtYW4vTGlzdEFkbWluLnB5IG1haWxtYW4vTWFp bG1hbi9MaXN0QWRtaW4ucHkNCi0tLSBtYWlsbWFuLTEtY21kaGFuZGxlci9N YWlsbWFuL0xpc3RBZG1pbi5weQlTYXQgRGVjIDEyIDE5OjAzOjM5IDE5OTgN CisrKyBtYWlsbWFuL01haWxtYW4vTGlzdEFkbWluLnB5CUZyaSBKYW4gIDgg MDk6MzA6MjIgMTk5OQ0KQEAgLTI3LDcgKzI3LDcgQEANCiBpbXBvcnQgRXJy b3JzDQogaW1wb3J0IE1lc3NhZ2UNCiBpbXBvcnQgVXRpbHMNCi0NCitpbXBv cnQgbW1fY2ZnDQogDQogY2xhc3MgTGlzdEFkbWluOg0KICAgICBkZWYgSW5p dFZhcnMoc2VsZik6DQpAQCAtNTUsNyArNTUsNyBAQA0KICAgICAgICAgICAg ICAgICAgICAgeyd1c2VybmFtZScgICA6IHdobywNCiAgICAgICAgICAgICAg ICAgICAgICAnbGlzdG5hbWUnICAgOiBzZWxmLnJlYWxfbmFtZSwNCiAgICAg ICAgICAgICAgICAgICAgICAnaG9zdG5hbWUnICAgOiBzZWxmLmhvc3RfbmFt ZSwNCi0gICAgICAgICAgICAgICAgICAgICAnYWRtaW5kYl91cmwnOiBzZWxm LkdldEFic29sdXRlU2NyaXB0VVJMKCdhZG1pbmRiJyksDQorICAgICAgICAg ICAgICAgICAgICAgJ2FkbWluZGJfdXJsJzogc2VsZi5HZXRBYnNvbHV0ZVNj cmlwdFVSTChtbV9jZmcuYWRtaW5kYl9jZ2kpLA0KICAgICAgICAgICAgICAg ICAgICAgIH0pDQogCQlzZWxmLlNlbmRUZXh0VG9Vc2VyKHN1YmplY3QgPSBz dWJqLA0KIAkJCQkgICAgcmVjaXBpZW50ID0gc2VsZi5HZXRBZG1pbkVtYWls KCksDQpAQCAtNzgsNyArNzgsNyBAQA0KICAgICAgICAgICAgICAgICAgICAg ICdyZWFzb24nICAgICA6IHJlYXNvbiwNCiAgICAgICAgICAgICAgICAgICAg ICAnc2VuZGVyJyAgICAgOiBzZW5kZXIsDQogICAgICAgICAgICAgICAgICAg ICAgJ3N1YmplY3QnICAgIDogc3ViamVjdCwNCi0gICAgICAgICAgICAgICAg ICAgICAnYWRtaW5kYl91cmwnOiBzZWxmLkdldEFic29sdXRlU2NyaXB0VVJM KCdhZG1pbmRiJyksDQorICAgICAgICAgICAgICAgICAgICAgJ2FkbWluZGJf dXJsJzogc2VsZi5HZXRBYnNvbHV0ZVNjcmlwdFVSTChtbV9jZmcuYWRtaW5k Yl9jZ2kpLA0KICAgICAgICAgICAgICAgICAgICAgIH0pDQogCQlzZWxmLlNl bmRUZXh0VG9Vc2VyKHN1YmplY3QgPSBzdWJqLA0KIAkJCQkgICAgcmVjaXBp ZW50ID0gc2VsZi5HZXRBZG1pbkVtYWlsKCksDQpkaWZmIC1ydU4gbWFpbG1h bi0xLWNtZGhhbmRsZXIvTWFpbG1hbi9NYWlsQ29tbWFuZEhhbmRsZXIucHkg bWFpbG1hbi9NYWlsbWFuL01haWxDb21tYW5kSGFuZGxlci5weQ0KLS0tIG1h aWxtYW4tMS1jbWRoYW5kbGVyL01haWxtYW4vTWFpbENvbW1hbmRIYW5kbGVy LnB5CUZyaSBKYW4gIDggMDk6Mjk6MDkgMTk5OQ0KKysrIG1haWxtYW4vTWFp bG1hbi9NYWlsQ29tbWFuZEhhbmRsZXIucHkJRnJpIEphbiAgOCAwOTozMDoy MiAxOTk5DQpAQCAtMzM1LDcgKzMzNSw3IEBADQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgIiBiYWNrZ3JvdW5kIiAlIHNlbGYucmVhbF9uYW1lKQ0K ICAgICAgICAgc2VsZi5BZGRUb1Jlc3BvbnNlKCJhbmQgaW5zdHJ1Y3Rpb25z IGZvciBzdWJzY3JpYmluZyB0byBhbmQiDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgIiB1c2luZyBpdCwgdmlzaXQ6XG5cblx0JXNcbiINCi0gICAg ICAgICAgICAgICAgICAgICAgICAgICAlIHNlbGYuR2V0QWJzb2x1dGVTY3Jp cHRVUkwoJ2xpc3RpbmZvJykpDQorICAgICAgICAgICAgICAgICAgICAgICAg ICAgJSBzZWxmLkdldEFic29sdXRlU2NyaXB0VVJMKG1tX2NmZy5saXN0aW5m b19jZ2kpKQ0KIA0KIAlpZiBub3Qgc2VsZi5pbmZvOg0KIAkgICAgc2VsZi5B ZGRUb1Jlc3BvbnNlKCJObyBvdGhlciBkZXRhaWxzIGFib3V0ICVzIGFyZSBh dmFpbGFibGUuIiAlDQpAQCAtNTUzLDcgKzU1Myw3IEBADQogICAgICAgICAg ICAgJ2hlbHAudHh0JywNCiAgICAgICAgICAgICB7J2xpc3RuYW1lJyAgICA6 IHNlbGYucmVhbF9uYW1lLA0KICAgICAgICAgICAgICAndmVyc2lvbicgICAg IDogbW1fY2ZnLlZFUlNJT04sDQotICAgICAgICAgICAgICdsaXN0aW5mb191 cmwnOiBzZWxmLkdldEFic29sdXRlU2NyaXB0VVJMKCdsaXN0aW5mbycpLA0K KyAgICAgICAgICAgICAnbGlzdGluZm9fdXJsJzogc2VsZi5HZXRBYnNvbHV0 ZVNjcmlwdFVSTChtbV9jZmcubGlzdGluZm9fY2dpKSwNCiAgICAgICAgICAg ICAgJ3JlcXVlc3RhZGRyJyA6IHNlbGYuR2V0UmVxdWVzdEVtYWlsKCksDQog ICAgICAgICAgICAgICdhZG1pbmFkZHInICAgOiBzZWxmLkdldEFkbWluRW1h aWwoKSwNCiAgICAgICAgICAgICAgfSkNCmRpZmYgLXJ1TiBtYWlsbWFuLTEt Y21kaGFuZGxlci9NYWlsbWFuL01haWxMaXN0LnB5IG1haWxtYW4vTWFpbG1h bi9NYWlsTGlzdC5weQ0KLS0tIG1haWxtYW4tMS1jbWRoYW5kbGVyL01haWxt YW4vTWFpbExpc3QucHkJRnJpIEphbiAgOCAwOToxODoxNiAxOTk5DQorKysg bWFpbG1hbi9NYWlsbWFuL01haWxMaXN0LnB5CUZyaSBKYW4gIDggMDk6MzA6 MjIgMTk5OQ0KQEAgLTE1NCw3ICsxNTQsNyBAQA0KIA0KIA0KICAgICBkZWYg R2V0QWJzb2x1dGVPcHRpb25zVVJMKHNlbGYsIGFkZHIsIG9ic2N1cmVkPTAs KToNCi0Jb3B0aW9ucyA9IHNlbGYuR2V0QWJzb2x1dGVTY3JpcHRVUkwoJ29w dGlvbnMnKQ0KKwlvcHRpb25zID0gc2VsZi5HZXRBYnNvbHV0ZVNjcmlwdFVS TChtbV9jZmcub3B0aW9uc19jZ2kpDQogICAgICAgICBpZiBvYnNjdXJlZDoN CiAgICAgICAgICAgICB0cmVhdGVkID0gVXRpbHMuT2JzY3VyZUVtYWlsKGFk ZHIsIGZvcl90ZXh0PTApDQogICAgICAgICBlbHNlOg0KQEAgLTQ5Nyw3ICs0 OTcsNyBAQA0KICAgICAgICAgICAgICIgY292ZXJpbmcgbWVtYmVycyBhbmQg b3V0c2lkZXJzLiINCiAgICAgICAgICAgICAnICAoU2VlIGFsc28gdGhlIDxh IGhyZWY9IiVzL2FyY2hpdmUiPkFyY2hpdmFsIE9wdGlvbnMnDQogICAgICAg ICAgICAgJyBzZWN0aW9uPC9hPiBmb3Igc2VwYXJhdGUgYXJjaGl2ZS1wcml2 YWN5IHNldHRpbmdzLiknDQotICAgICAgICAgICAgJSAoc2VsZi5HZXRSZWxh dGl2ZVNjcmlwdFVSTCgnYWRtaW4nKSksDQorICAgICAgICAgICAgJSAoc2Vs Zi5HZXRSZWxhdGl2ZVNjcmlwdFVSTChtbV9jZmcuYWRtaW5fY2dpKSksDQog DQogCSAgICAiU3Vic2NyaWJpbmciLA0KIA0KZGlmZiAtcnVOIG1haWxtYW4t MS1jbWRoYW5kbGVyL01haWxtYW4vbW1fY2ZnLnB5LmRpc3QuaW4gbWFpbG1h bi9NYWlsbWFuL21tX2NmZy5weS5kaXN0LmluDQotLS0gbWFpbG1hbi0xLWNt ZGhhbmRsZXIvTWFpbG1hbi9tbV9jZmcucHkuZGlzdC5pbglGcmkgSnVuIDE5 IDIyOjExOjMyIDE5OTgNCisrKyBtYWlsbWFuL01haWxtYW4vbW1fY2ZnLnB5 LmRpc3QuaW4JRnJpIEphbiAgOCAwOTozMDoyMiAxOTk5DQpAQCAtNTIsOCAr NTIsOCBAQA0KIA0KIE1BSUxNQU5fT1dORVIgICAgID0gJ21haWxtYW4tb3du ZXJAJXMnICUgREVGQVVMVF9IT1NUX05BTUUNCiANCi1QVUJMSUNfQVJDSElW RV9VUkwgPSAnL3BpcGVybWFpbCcNCi1QUklWQVRFX0FSQ0hJVkVfVVJMID0g Jy9tYWlsbWFuL3ByaXZhdGUnDQorUFVCTElDX0FSQ0hJVkVfVVJMID0gJy9w aXBlcm1haWxAQ0dJRVhUQCcNCitQUklWQVRFX0FSQ0hJVkVfVVJMID0gJy9t YWlsbWFuL3ByaXZhdGVAQ0dJRVhUQCcNCiANCiAjIE5vdGUgLSBpZiB5b3Un cmUgbG9va2luZyBmb3Igc29tZXRoaW5nIHRoYXQgaXMgaW1wb3J0ZWQgZnJv bSBtbV9jZmcsIGJ1dCB5b3UNCiAjIGRpZG4ndCBmaW5kIGl0IGFib3ZlLCBp dCdzIHByb2JhYmx5IGluIERlZmF1bHRzLnB5Lg0KZGlmZiAtcnVOIG1haWxt YW4tMS1jbWRoYW5kbGVyL2Jpbi9hZGRfbWVtYmVycyBtYWlsbWFuL2Jpbi9h ZGRfbWVtYmVycw0KLS0tIG1haWxtYW4tMS1jbWRoYW5kbGVyL2Jpbi9hZGRf bWVtYmVycwlUaHUgRGVjIDE3IDExOjAwOjE3IDE5OTgNCisrKyBtYWlsbWFu L2Jpbi9hZGRfbWVtYmVycwlGcmkgSmFuICA4IDA5OjMwOjIyIDE5OTkNCkBA IC05Myw3ICs5Myw3IEBADQogICAgIGRpY3QgPSB7J2xpc3RuYW1lJyAgICA6 IG1sLnJlYWxfbmFtZSwNCiAgICAgICAgICAgICAnbGlzdGhvc3QnICAgIDog bWwuaG9zdF9uYW1lLA0KICAgICAgICAgICAgICdsaXN0YWRkcicgICAgOiBt bC5HZXRMaXN0RW1haWwoKSwNCi0gICAgICAgICAgICAnbGlzdGluZm9fdXJs JzogbWwuR2V0QWJzb2x1dGVTY3JpcHRVUkwoJ2xpc3RpbmZvJyksDQorICAg ICAgICAgICAgJ2xpc3RpbmZvX3VybCc6IG1sLkdldEFic29sdXRlU2NyaXB0 VVJMKG1tX2NmZy5saXN0aW5mb19jZ2kpLA0KICAgICAgICAgICAgICdyZXF1 ZXN0YWRkcicgOiBtbC5HZXRSZXF1ZXN0RW1haWwoKSwNCiAgICAgICAgICAg ICAnYWRtaW5hZGRyJyAgIDogbWwuR2V0QWRtaW5FbWFpbCgpLA0KICAgICAg ICAgICAgICd2ZXJzaW9uJyAgICAgOiBNYWlsbWFuLm1tX2NmZy5WRVJTSU9O LA0KZGlmZiAtcnVOIG1haWxtYW4tMS1jbWRoYW5kbGVyL2Jpbi9uZXdsaXN0 IG1haWxtYW4vYmluL25ld2xpc3QNCi0tLSBtYWlsbWFuLTEtY21kaGFuZGxl ci9iaW4vbmV3bGlzdAlUaHUgT2N0IDIyIDA5OjI5OjI3IDE5OTgNCisrKyBt YWlsbWFuL2Jpbi9uZXdsaXN0CUZyaSBKYW4gIDggMDk6MzA6MjIgMTk5OQ0K QEAgLTEyMCw4ICsxMjAsOCBAQA0KICAgICAgICAgJ25ld2xpc3QudHh0JywN CiAgICAgICAgIHsnbGlzdG5hbWUnICAgIDogbGlzdF9uYW1lLA0KICAgICAg ICAgICdwYXNzd29yZCcgICAgOiBsaXN0X3B3LCANCi0gICAgICAgICAnYWRt aW5fdXJsJyAgIDogbmV3bGlzdC5HZXRBYnNvbHV0ZVNjcmlwdFVSTCgnYWRt aW4nKSwgDQotICAgICAgICAgJ2xpc3RpbmZvX3VybCc6IG5ld2xpc3QuR2V0 QWJzb2x1dGVTY3JpcHRVUkwoJ2xpc3RpbmZvJyksDQorICAgICAgICAgJ2Fk bWluX3VybCcgICA6IG5ld2xpc3QuR2V0QWJzb2x1dGVTY3JpcHRVUkwobW1f Y2ZnLmFkbWluX2NnaSksIA0KKyAgICAgICAgICdsaXN0aW5mb191cmwnOiBu ZXdsaXN0LkdldEFic29sdXRlU2NyaXB0VVJMKG1tX2NmZy5saXN0aW5mb19j Z2kpLA0KICAgICAgICAgICdyZXF1ZXN0YWRkcicgOiAiJXMtcmVxdWVzdEAl cyIgJSAobGlzdF9uYW1lLCBuZXdsaXN0Lmhvc3RfbmFtZSksDQogICAgICAg ICAgJ2hvc3RuYW1lJyAgICA6IG5ld2xpc3QuaG9zdF9uYW1lLA0KICAgICAg ICAgIH0pDQpkaWZmIC1ydU4gbWFpbG1hbi0xLWNtZGhhbmRsZXIvY29uZmln dXJlIG1haWxtYW4vY29uZmlndXJlDQotLS0gbWFpbG1hbi0xLWNtZGhhbmRs ZXIvY29uZmlndXJlCUZyaSBKYW4gIDggMDk6MzA6MTUgMTk5OQ0KKysrIG1h aWxtYW4vY29uZmlndXJlCUZyaSBKYW4gIDggMDk6MzI6MjkgMTk5OQ0KQEAg LTI1LDYgKzI1LDkgQEANCiBhY19oZWxwPSIkYWNfaGVscA0KIA0KIAktLXdp dGgtY2dpLWdpZCAgCXNwZWNpZnkgR0lEIENHSSBwcm9ncmFtcyBydW4gYXMi DQorYWNfaGVscD0iJGFjX2hlbHANCisNCisgICAgICAgLS13aXRoLWNnaS1l eHQgICAgICAgIHNwZWNpZnkgZXh0ZW5zaW9ucyBvZiBDR0kgcHJvZ3JhbXMi DQogDQogIyBJbml0aWFsaXplIHNvbWUgdmFyaWFibGVzIHNldCBieSBvcHRp b25zLg0KICMgVGhlIHZhcmlhYmxlcyBoYXZlIHRoZSBzYW1lIG5hbWVzIGFz IHRoZSBvcHRpb25zLCB3aXRoDQpAQCAtNTQ1LDcgKzU0OCw3IEBADQogDQog IyBDaGVjayBmb3IgUHl0aG9uISAgQmV0dGVyIGJlIGZvdW5kIG9uICRQQVRI DQogZWNobyAkYWNfbiAiY2hlY2tpbmcgZm9yIC0td2l0aC1weXRob24iIi4u LiAkYWNfYyIgMT4mNg0KLWVjaG8gImNvbmZpZ3VyZTo1NDk6IGNoZWNraW5n IGZvciAtLXdpdGgtcHl0aG9uIiA+JjUNCitlY2hvICJjb25maWd1cmU6NTUy OiBjaGVja2luZyBmb3IgLS13aXRoLXB5dGhvbiIgPiY1DQogIyBDaGVjayB3 aGV0aGVyIC0td2l0aC1weXRob24gb3IgLS13aXRob3V0LXB5dGhvbiB3YXMg Z2l2ZW4uDQogaWYgdGVzdCAiJHt3aXRoX3B5dGhvbitzZXR9IiA9IHNldDsg dGhlbg0KICAgd2l0aHZhbD0iJHdpdGhfcHl0aG9uIg0KQEAgLTU1OSw3ICs1 NjIsNyBAQA0KIAkjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgInB5dGhv biIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuDQog c2V0IGR1bW15IHB5dGhvbjsgYWNfd29yZD0kMg0KIGVjaG8gJGFjX24gImNo ZWNraW5nIGZvciAkYWNfd29yZCIiLi4uICRhY19jIiAxPiY2DQotZWNobyAi Y29uZmlndXJlOjU2MzogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUNCitl Y2hvICJjb25maWd1cmU6NTY2OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4m NQ0KIGlmIGV2YWwgInRlc3QgXCJgZWNobyAnJCcneydhY19jdl9wYXRoX3dp dGhfcHl0aG9uJytzZXR9J2BcIiA9IHNldCI7IHRoZW4NCiAgIGVjaG8gJGFj X24gIihjYWNoZWQpICRhY19jIiAxPiY2DQogZWxzZQ0KQEAgLTU5MSw3ICs1 OTQsNyBAQA0KIGZpDQogDQogZWNobyAkYWNfbiAiY2hlY2tpbmcgUHl0aG9u IGludGVycHJldGVyIiIuLi4gJGFjX2MiIDE+JjYNCi1lY2hvICJjb25maWd1 cmU6NTk1OiBjaGVja2luZyBQeXRob24gaW50ZXJwcmV0ZXIiID4mNQ0KK2Vj aG8gImNvbmZpZ3VyZTo1OTg6IGNoZWNraW5nIFB5dGhvbiBpbnRlcnByZXRl ciIgPiY1DQogaWYgdGVzdCAhIC14ICR3aXRoX3B5dGhvbg0KIHRoZW4NCiAg ICAgeyBlY2hvICJjb25maWd1cmU6IGVycm9yOiANCkBAIC02MzUsNyArNjM4 LDcgQEANCiAjIFNWUjQgL3Vzci91Y2IvaW5zdGFsbCwgd2hpY2ggdHJpZXMg dG8gdXNlIHRoZSBub25leGlzdGVudCBncm91cCAic3RhZmYiDQogIyAuL2lu c3RhbGwsIHdoaWNoIGNhbiBiZSBlcnJvbmVvdXNseSBjcmVhdGVkIGJ5IG1h a2UgZnJvbSAuL2luc3RhbGwuc2guDQogZWNobyAkYWNfbiAiY2hlY2tpbmcg Zm9yIGEgQlNEIGNvbXBhdGlibGUgaW5zdGFsbCIiLi4uICRhY19jIiAxPiY2 DQotZWNobyAiY29uZmlndXJlOjYzOTogY2hlY2tpbmcgZm9yIGEgQlNEIGNv bXBhdGlibGUgaW5zdGFsbCIgPiY1DQorZWNobyAiY29uZmlndXJlOjY0Mjog Y2hlY2tpbmcgZm9yIGEgQlNEIGNvbXBhdGlibGUgaW5zdGFsbCIgPiY1DQog aWYgdGVzdCAteiAiJElOU1RBTEwiOyB0aGVuDQogaWYgZXZhbCAidGVzdCBc ImBlY2hvICckJyd7J2FjX2N2X3BhdGhfaW5zdGFsbCcrc2V0fSdgXCIgPSBz ZXQiOyB0aGVuDQogICBlY2hvICRhY19uICIoY2FjaGVkKSAkYWNfYyIgMT4m Ng0KQEAgLTY4NSw3ICs2ODgsNyBAQA0KIHRlc3QgLXogIiRJTlNUQUxMX0RB VEEiICYmIElOU1RBTExfREFUQT0nJHtJTlNUQUxMfSAtbSA2NDQnDQogDQog ZWNobyAkYWNfbiAiY2hlY2tpbmcgd2hldGhlciAke01BS0UtbWFrZX0gc2V0 cyBcJHtNQUtFfSIiLi4uICRhY19jIiAxPiY2DQotZWNobyAiY29uZmlndXJl OjY4OTogY2hlY2tpbmcgd2hldGhlciAke01BS0UtbWFrZX0gc2V0cyBcJHtN QUtFfSIgPiY1DQorZWNobyAiY29uZmlndXJlOjY5MjogY2hlY2tpbmcgd2hl dGhlciAke01BS0UtbWFrZX0gc2V0cyBcJHtNQUtFfSIgPiY1DQogc2V0IGR1 bW15ICR7TUFLRS1tYWtlfTsgYWNfbWFrZT1gZWNobyAiJDIiIHwgc2VkICd5 JS4vKy0lX19wXyUnYA0KIGlmIGV2YWwgInRlc3QgXCJgZWNobyAnJCcneydh Y19jdl9wcm9nX21ha2VfJHthY19tYWtlfV9zZXQnK3NldH0nYFwiID0gc2V0 IjsgdGhlbg0KICAgZWNobyAkYWNfbiAiKGNhY2hlZCkgJGFjX2MiIDE+JjYN CkBAIC03MTQsNyArNzE3LDcgQEANCiANCiAjIEZpbmQgY29tcGlsZXIsIGFs bG93IGFsdGVybmF0aXZlcyB0byBnY2MNCiBlY2hvICRhY19uICJjaGVja2lu ZyBmb3IgLS13aXRob3V0LWdjYyIiLi4uICRhY19jIiAxPiY2DQotZWNobyAi Y29uZmlndXJlOjcxODogY2hlY2tpbmcgZm9yIC0td2l0aG91dC1nY2MiID4m NQ0KK2VjaG8gImNvbmZpZ3VyZTo3MjE6IGNoZWNraW5nIGZvciAtLXdpdGhv dXQtZ2NjIiA+JjUNCiAjIENoZWNrIHdoZXRoZXIgLS13aXRoLWdjYyBvciAt LXdpdGhvdXQtZ2NjIHdhcyBnaXZlbi4NCiBpZiB0ZXN0ICIke3dpdGhfZ2Nj K3NldH0iID0gc2V0OyB0aGVuDQogICB3aXRodmFsPSIkd2l0aF9nY2MiDQpA QCAtNzQzLDcgKzc0Niw3IEBADQogIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3Jk IG9mICJnY2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBh cmdzLg0KIHNldCBkdW1teSBnY2M7IGFjX3dvcmQ9JDINCiBlY2hvICRhY19u ICJjaGVja2luZyBmb3IgJGFjX3dvcmQiIi4uLiAkYWNfYyIgMT4mNg0KLWVj aG8gImNvbmZpZ3VyZTo3NDc6IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1 DQorZWNobyAiY29uZmlndXJlOjc1MDogY2hlY2tpbmcgZm9yICRhY193b3Jk IiA+JjUNCiBpZiBldmFsICJ0ZXN0IFwiYGVjaG8gJyQnJ3snYWNfY3ZfcHJv Z19DQycrc2V0fSdgXCIgPSBzZXQiOyB0aGVuDQogICBlY2hvICRhY19uICIo Y2FjaGVkKSAkYWNfYyIgMT4mNg0KIGVsc2UNCkBAIC03NzIsNyArNzc1LDcg QEANCiAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiY2MiLCBzbyBp dCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLg0KIHNldCBkdW1t eSBjYzsgYWNfd29yZD0kMg0KIGVjaG8gJGFjX24gImNoZWNraW5nIGZvciAk YWNfd29yZCIiLi4uICRhY19jIiAxPiY2DQotZWNobyAiY29uZmlndXJlOjc3 NjogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUNCitlY2hvICJjb25maWd1 cmU6Nzc5OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQ0KIGlmIGV2YWwg InRlc3QgXCJgZWNobyAnJCcneydhY19jdl9wcm9nX0NDJytzZXR9J2BcIiA9 IHNldCI7IHRoZW4NCiAgIGVjaG8gJGFjX24gIihjYWNoZWQpICRhY19jIiAx PiY2DQogZWxzZQ0KQEAgLTgyMCw3ICs4MjMsNyBAQA0KIGZpDQogDQogZWNo byAkYWNfbiAiY2hlY2tpbmcgd2hldGhlciB0aGUgQyBjb21waWxlciAoJEND ICRDRkxBR1MgJExERkxBR1MpIHdvcmtzIiIuLi4gJGFjX2MiIDE+JjYNCi1l Y2hvICJjb25maWd1cmU6ODI0OiBjaGVja2luZyB3aGV0aGVyIHRoZSBDIGNv bXBpbGVyICgkQ0MgJENGTEFHUyAkTERGTEFHUykgd29ya3MiID4mNQ0KK2Vj aG8gImNvbmZpZ3VyZTo4Mjc6IGNoZWNraW5nIHdoZXRoZXIgdGhlIEMgY29t cGlsZXIgKCRDQyAkQ0ZMQUdTICRMREZMQUdTKSB3b3JrcyIgPiY1DQogDQog YWNfZXh0PWMNCiAjIENGTEFHUyBpcyBub3QgaW4gYWNfY3BwIGJlY2F1c2Ug LWcsIC1PLCBldGMuIGFyZSBub3QgdmFsaWQgY3BwIG9wdGlvbnMuDQpAQCAt ODMwLDExICs4MzMsMTEgQEANCiBjcm9zc19jb21waWxpbmc9JGFjX2N2X3By b2dfY2NfY3Jvc3MNCiANCiBjYXQgPiBjb25mdGVzdC4kYWNfZXh0IDw8RU9G DQotI2xpbmUgODM0ICJjb25maWd1cmUiDQorI2xpbmUgODM3ICJjb25maWd1 cmUiDQogI2luY2x1ZGUgImNvbmZkZWZzLmgiDQogbWFpbigpe3JldHVybigw KTt9DQogRU9GDQotaWYgeyAoZXZhbCBlY2hvIGNvbmZpZ3VyZTo4Mzg6IFwi JGFjX2xpbmtcIikgMT4mNTsgKGV2YWwgJGFjX2xpbmspIDI+JjU7IH0gJiYg dGVzdCAtcyBjb25mdGVzdDsgdGhlbg0KK2lmIHsgKGV2YWwgZWNobyBjb25m aWd1cmU6ODQxOiBcIiRhY19saW5rXCIpIDE+JjU7IChldmFsICRhY19saW5r KSAyPiY1OyB9ICYmIHRlc3QgLXMgY29uZnRlc3Q7IHRoZW4NCiAgIGFjX2N2 X3Byb2dfY2Nfd29ya3M9eWVzDQogICAjIElmIHdlIGNhbid0IHJ1biBhIHRy aXZpYWwgcHJvZ3JhbSwgd2UgYXJlIHByb2JhYmx5IHVzaW5nIGEgY3Jvc3Mg Y29tcGlsZXIuDQogICBpZiAoLi9jb25mdGVzdDsgZXhpdCkgMj4vZGV2L251 bGw7IHRoZW4NCkBAIC04NTQsMTIgKzg1NywxMiBAQA0KICAgeyBlY2hvICJj b25maWd1cmU6IGVycm9yOiBpbnN0YWxsYXRpb24gb3IgY29uZmlndXJhdGlv biBwcm9ibGVtOiBDIGNvbXBpbGVyIGNhbm5vdCBjcmVhdGUgZXhlY3V0YWJs ZXMuIiAxPiYyOyBleGl0IDE7IH0NCiBmaQ0KIGVjaG8gJGFjX24gImNoZWNr aW5nIHdoZXRoZXIgdGhlIEMgY29tcGlsZXIgKCRDQyAkQ0ZMQUdTICRMREZM QUdTKSBpcyBhIGNyb3NzLWNvbXBpbGVyIiIuLi4gJGFjX2MiIDE+JjYNCi1l Y2hvICJjb25maWd1cmU6ODU4OiBjaGVja2luZyB3aGV0aGVyIHRoZSBDIGNv bXBpbGVyICgkQ0MgJENGTEFHUyAkTERGTEFHUykgaXMgYSBjcm9zcy1jb21w aWxlciIgPiY1DQorZWNobyAiY29uZmlndXJlOjg2MTogY2hlY2tpbmcgd2hl dGhlciB0aGUgQyBjb21waWxlciAoJENDICRDRkxBR1MgJExERkxBR1MpIGlz IGEgY3Jvc3MtY29tcGlsZXIiID4mNQ0KIGVjaG8gIiRhY190IiIkYWNfY3Zf cHJvZ19jY19jcm9zcyIgMT4mNg0KIGNyb3NzX2NvbXBpbGluZz0kYWNfY3Zf cHJvZ19jY19jcm9zcw0KIA0KIGVjaG8gJGFjX24gImNoZWNraW5nIHdoZXRo ZXIgd2UgYXJlIHVzaW5nIEdOVSBDIiIuLi4gJGFjX2MiIDE+JjYNCi1lY2hv ICJjb25maWd1cmU6ODYzOiBjaGVja2luZyB3aGV0aGVyIHdlIGFyZSB1c2lu ZyBHTlUgQyIgPiY1DQorZWNobyAiY29uZmlndXJlOjg2NjogY2hlY2tpbmcg d2hldGhlciB3ZSBhcmUgdXNpbmcgR05VIEMiID4mNQ0KIGlmIGV2YWwgInRl c3QgXCJgZWNobyAnJCcneydhY19jdl9wcm9nX2djYycrc2V0fSdgXCIgPSBz ZXQiOyB0aGVuDQogICBlY2hvICRhY19uICIoY2FjaGVkKSAkYWNfYyIgMT4m Ng0KIGVsc2UNCkBAIC04NjgsNyArODcxLDcgQEANCiAgIHllczsNCiAjZW5k aWYNCiBFT0YNCi1pZiB7IGFjX3RyeT0nJHtDQy1jY30gLUUgY29uZnRlc3Qu Yyc7IHsgKGV2YWwgZWNobyBjb25maWd1cmU6ODcyOiBcIiRhY190cnlcIikg MT4mNTsgKGV2YWwgJGFjX3RyeSkgMj4mNTsgfTsgfSB8IGVncmVwIHllcyA+ L2Rldi9udWxsIDI+JjE7IHRoZW4NCitpZiB7IGFjX3RyeT0nJHtDQy1jY30g LUUgY29uZnRlc3QuYyc7IHsgKGV2YWwgZWNobyBjb25maWd1cmU6ODc1OiBc IiRhY190cnlcIikgMT4mNTsgKGV2YWwgJGFjX3RyeSkgMj4mNTsgfTsgfSB8 IGVncmVwIHllcyA+L2Rldi9udWxsIDI+JjE7IHRoZW4NCiAgIGFjX2N2X3By b2dfZ2NjPXllcw0KIGVsc2UNCiAgIGFjX2N2X3Byb2dfZ2NjPW5vDQpAQCAt ODgzLDcgKzg4Niw3IEBADQogICBhY19zYXZlX0NGTEFHUz0iJENGTEFHUyIN CiAgIENGTEFHUz0NCiAgIGVjaG8gJGFjX24gImNoZWNraW5nIHdoZXRoZXIg JHtDQy1jY30gYWNjZXB0cyAtZyIiLi4uICRhY19jIiAxPiY2DQotZWNobyAi Y29uZmlndXJlOjg4NzogY2hlY2tpbmcgd2hldGhlciAke0NDLWNjfSBhY2Nl cHRzIC1nIiA+JjUNCitlY2hvICJjb25maWd1cmU6ODkwOiBjaGVja2luZyB3 aGV0aGVyICR7Q0MtY2N9IGFjY2VwdHMgLWciID4mNQ0KIGlmIGV2YWwgInRl c3QgXCJgZWNobyAnJCcneydhY19jdl9wcm9nX2NjX2cnK3NldH0nYFwiID0g c2V0IjsgdGhlbg0KICAgZWNobyAkYWNfbiAiKGNhY2hlZCkgJGFjX2MiIDE+ JjYNCiBlbHNlDQpAQCAtOTMxLDcgKzkzNCw3IEBADQogIyBQdWxsIHRoZSBo YXNoIG1hcmsgb3V0IG9mIHRoZSBtYWNybyBjYWxsIHRvIGF2b2lkIG00IHBy b2JsZW1zLg0KIGFjX21zZz0id2hldGhlciAjISB3b3JrcyBpbiBzaGVsbCBz Y3JpcHRzIg0KIGVjaG8gJGFjX24gImNoZWNraW5nICRhY19tc2ciIi4uLiAk YWNfYyIgMT4mNg0KLWVjaG8gImNvbmZpZ3VyZTo5MzU6IGNoZWNraW5nICRh Y19tc2ciID4mNQ0KK2VjaG8gImNvbmZpZ3VyZTo5Mzg6IGNoZWNraW5nICRh Y19tc2ciID4mNQ0KIGlmIGV2YWwgInRlc3QgXCJgZWNobyAnJCcneydhY19j dl9zeXNfaW50ZXJwcmV0ZXInK3NldH0nYFwiID0gc2V0IjsgdGhlbg0KICAg ZWNobyAkYWNfbiAiKGNhY2hlZCkgJGFjX2MiIDE+JjYNCiBlbHNlDQpAQCAt OTY4LDcgKzk3MSw3IEBADQogDQogIyBVc2VyIGBtYWlsbWFuJyBtdXN0IGV4 aXN0DQogZWNobyAkYWNfbiAiY2hlY2tpbmcgZm9yIG1haWxtYW4gVUlEIiIu Li4gJGFjX2MiIDE+JjYNCi1lY2hvICJjb25maWd1cmU6OTcyOiBjaGVja2lu ZyBmb3IgbWFpbG1hbiBVSUQiID4mNQ0KK2VjaG8gImNvbmZpZ3VyZTo5NzU6 IGNoZWNraW5nIGZvciBtYWlsbWFuIFVJRCIgPiY1DQogDQogIyBNQUlMTUFO X1VJRCA9PSB2YXJpYWJsZSBuYW1lDQogIyBtYWlsbWFuID09IHVzZXIgaWQg dG8gY2hlY2sgZm9yDQpAQCAtMTAxMSw3ICsxMDE0LDcgQEANCiANCiAjIEdy b3VwIGBtYWlsbWFuJyBtdXN0IGV4aXN0DQogZWNobyAkYWNfbiAiY2hlY2tp bmcgZm9yIG1haWxtYW4gR0lEIiIuLi4gJGFjX2MiIDE+JjYNCi1lY2hvICJj b25maWd1cmU6MTAxNTogY2hlY2tpbmcgZm9yIG1haWxtYW4gR0lEIiA+JjUN CitlY2hvICJjb25maWd1cmU6MTAxODogY2hlY2tpbmcgZm9yIG1haWxtYW4g R0lEIiA+JjUNCiANCiAjIE1BSUxNQU5fR0lEID09IHZhcmlhYmxlIG5hbWUN CiAjIG1haWxtYW4gPT0gdXNlciBpZCB0byBjaGVjayBmb3INCkBAIC0xMDYz LDcgKzEwNjYsNyBAQA0KIGZpDQogDQogZWNobyAkYWNfbiAiY2hlY2tpbmcg cGVybWlzc2lvbnMgb24gJHByZWZpeGNoZWNrIiIuLi4gJGFjX2MiIDE+JjYN Ci1lY2hvICJjb25maWd1cmU6MTA2NzogY2hlY2tpbmcgcGVybWlzc2lvbnMg b24gJHByZWZpeGNoZWNrIiA+JjUNCitlY2hvICJjb25maWd1cmU6MTA3MDog Y2hlY2tpbmcgcGVybWlzc2lvbnMgb24gJHByZWZpeGNoZWNrIiA+JjUNCiAN CiBjYXQgPiBjb25mdGVzdC5weSA8PEVPRg0KIGltcG9ydCBvcywgZ3JwLCBz dHJpbmcNCkBAIC0xMTA5LDcgKzExMTIsNyBAQA0KICMgTm93IGZpbmQgdGhl IFVJRHMgYW5kIEdJRHMNCiAjIFN1cHBvcnQgLS13aXRoLW1haWwtZ2lkIGFu ZCAtLXdpdGgtY2dpLWdpZA0KIGVjaG8gJGFjX24gImNoZWNraW5nIGZvciBt YWlsIHdyYXBwZXIgR0lEIiIuLi4gJGFjX2MiIDE+JjYNCi1lY2hvICJjb25m aWd1cmU6MTExMzogY2hlY2tpbmcgZm9yIG1haWwgd3JhcHBlciBHSUQiID4m NQ0KK2VjaG8gImNvbmZpZ3VyZToxMTE2OiBjaGVja2luZyBmb3IgbWFpbCB3 cmFwcGVyIEdJRCIgPiY1DQogIyBDaGVjayB3aGV0aGVyIC0td2l0aC1tYWls LWdpZCBvciAtLXdpdGhvdXQtbWFpbC1naWQgd2FzIGdpdmVuLg0KIGlmIHRl c3QgIiR7d2l0aF9tYWlsX2dpZCtzZXR9IiA9IHNldDsgdGhlbg0KICAgd2l0 aHZhbD0iJHdpdGhfbWFpbF9naWQiDQpAQCAtMTE3MCw3ICsxMTczLDcgQEAN CiANCiANCiBlY2hvICRhY19uICJjaGVja2luZyBmb3IgQ0dJIHdyYXBwZXIg R0lEIiIuLi4gJGFjX2MiIDE+JjYNCi1lY2hvICJjb25maWd1cmU6MTE3NDog Y2hlY2tpbmcgZm9yIENHSSB3cmFwcGVyIEdJRCIgPiY1DQorZWNobyAiY29u ZmlndXJlOjExNzc6IGNoZWNraW5nIGZvciBDR0kgd3JhcHBlciBHSUQiID4m NQ0KICMgQ2hlY2sgd2hldGhlciAtLXdpdGgtY2dpLWdpZCBvciAtLXdpdGhv dXQtY2dpLWdpZCB3YXMgZ2l2ZW4uDQogaWYgdGVzdCAiJHt3aXRoX2NnaV9n aWQrc2V0fSIgPSBzZXQ7IHRoZW4NCiAgIHdpdGh2YWw9IiR3aXRoX2NnaV9n aWQiDQpAQCAtMTIzMCw2ICsxMjMzLDI1IEBADQogZmkNCiANCiANCisjIENH SSBleHRlbnNpb24gY2hlY2tpbmcNCisNCitlY2hvICRhY19uICJjaGVja2lu ZyBmb3IgQ0dJIGV4dGVuc2lvbiIiLi4uICRhY19jIiAxPiY2DQorZWNobyAi Y29uZmlndXJlOjEyNDA6IGNoZWNraW5nIGZvciBDR0kgZXh0ZW5zaW9uIiA+ JjUNCisjIENoZWNrIHdoZXRoZXIgLS13aXRoLWNnaS1leHQgb3IgLS13aXRo b3V0LWNnaS1leHQgd2FzIGdpdmVuLg0KK2lmIHRlc3QgIiR7d2l0aF9jZ2lf ZXh0K3NldH0iID0gc2V0OyB0aGVuDQorICB3aXRodmFsPSIkd2l0aF9jZ2lf ZXh0Ig0KKyAgOg0KK2ZpDQorDQoraWYgdGVzdCAteiAiJHdpdGhfY2dpX2V4 dCINCit0aGVuDQorICAgIENHSUVYVD0nJw0KKyAgICB3aXRoX2NnaV9leHQ9 J25vJw0KK2Vsc2UNCisgICAgQ0dJRVhUPSR3aXRoX2NnaV9leHQNCitmaQ0K K2VjaG8gIiRhY190IiIkd2l0aF9jZ2lfZXh0IiAxPiY2DQorDQogI01NX0ZJ TkRfVVNFUl9JRChBTElBU19VSUQsIG1haWxtYW4sIGFsaWFzX3dyYXBwZXIp DQogI01NX0ZJTkRfR1JPVVBfSUQoQUxJQVNfR0lELCBtYWlsLCBhbGlhc193 cmFwcGVyKQ0KIA0KQEAgLTEyNjUsMTQgKzEyODcsMTQgQEANCiAkUFlUSE9O IGNvbmZ0ZXN0LnB5DQogDQogZWNobyAkYWNfbiAiY2hlY2tpbmcgZm9yIGRl ZmF1bHQgZnVsbHkgcXVhbGlmaWVkIGhvc3QgbmFtZSIiLi4uICRhY19jIiAx PiY2DQotZWNobyAiY29uZmlndXJlOjEyNjk6IGNoZWNraW5nIGZvciBkZWZh dWx0IGZ1bGx5IHF1YWxpZmllZCBob3N0IG5hbWUiID4mNQ0KK2VjaG8gImNv bmZpZ3VyZToxMjkxOiBjaGVja2luZyBmb3IgZGVmYXVsdCBmdWxseSBxdWFs aWZpZWQgaG9zdCBuYW1lIiA+JjUNCiBpZiB0ZXN0IC16ICIkRlFETiINCiB0 aGVuDQogICAgIEZRRE49YGhlYWQgLTEgY29uZnRlc3Qub3V0YA0KIGZpDQog ZWNobyAiJGFjX3QiIiRGUUROIiAxPiY2DQogZWNobyAkYWNfbiAiY2hlY2tp bmcgZm9yIGRlZmF1bHQgVVJMIGhvc3QgY29tcG9uZW50IiIuLi4gJGFjX2Mi IDE+JjYNCi1lY2hvICJjb25maWd1cmU6MTI3NjogY2hlY2tpbmcgZm9yIGRl ZmF1bHQgVVJMIGhvc3QgY29tcG9uZW50IiA+JjUNCitlY2hvICJjb25maWd1 cmU6MTI5ODogY2hlY2tpbmcgZm9yIGRlZmF1bHQgVVJMIGhvc3QgY29tcG9u ZW50IiA+JjUNCiBpZiB0ZXN0IC16ICIkVVJMIg0KIHRoZW4NCiAgICAgVVJM PWB0YWlsIC0xIGNvbmZ0ZXN0Lm91dGANCkBAIC0xMjg0LDEyICsxMzA2LDEy IEBADQogZm9yIGFjX2Z1bmMgaW4gc3RyZXJyb3INCiBkbw0KIGVjaG8gJGFj X24gImNoZWNraW5nIGZvciAkYWNfZnVuYyIiLi4uICRhY19jIiAxPiY2DQot ZWNobyAiY29uZmlndXJlOjEyODg6IGNoZWNraW5nIGZvciAkYWNfZnVuYyIg PiY1DQorZWNobyAiY29uZmlndXJlOjEzMTA6IGNoZWNraW5nIGZvciAkYWNf ZnVuYyIgPiY1DQogaWYgZXZhbCAidGVzdCBcImBlY2hvICckJyd7J2FjX2N2 X2Z1bmNfJGFjX2Z1bmMnK3NldH0nYFwiID0gc2V0IjsgdGhlbg0KICAgZWNo byAkYWNfbiAiKGNhY2hlZCkgJGFjX2MiIDE+JjYNCiBlbHNlDQogICBjYXQg PiBjb25mdGVzdC4kYWNfZXh0IDw8RU9GDQotI2xpbmUgMTI5MyAiY29uZmln dXJlIg0KKyNsaW5lIDEzMTUgImNvbmZpZ3VyZSINCiAjaW5jbHVkZSAiY29u ZmRlZnMuaCINCiAvKiBTeXN0ZW0gaGVhZGVyIHRvIGRlZmluZSBfX3N0dWIg bWFjcm9zIGFuZCBob3BlZnVsbHkgZmV3IHByb3RvdHlwZXMsDQogICAgIHdo aWNoIGNhbiBjb25mbGljdCB3aXRoIGNoYXIgJGFjX2Z1bmMoKTsgYmVsb3cu ICAqLw0KQEAgLTEzMTIsNyArMTMzNCw3IEBADQogDQogOyByZXR1cm4gMDsg fQ0KIEVPRg0KLWlmIHsgKGV2YWwgZWNobyBjb25maWd1cmU6MTMxNjogXCIk YWNfbGlua1wiKSAxPiY1OyAoZXZhbCAkYWNfbGluaykgMj4mNTsgfSAmJiB0 ZXN0IC1zIGNvbmZ0ZXN0OyB0aGVuDQoraWYgeyAoZXZhbCBlY2hvIGNvbmZp Z3VyZToxMzM4OiBcIiRhY19saW5rXCIpIDE+JjU7IChldmFsICRhY19saW5r KSAyPiY1OyB9ICYmIHRlc3QgLXMgY29uZnRlc3Q7IHRoZW4NCiAgIHJtIC1y ZiBjb25mdGVzdCoNCiAgIGV2YWwgImFjX2N2X2Z1bmNfJGFjX2Z1bmM9eWVz Ig0KIGVsc2UNCkBAIC0xMzM5LDcgKzEzNjEsNyBAQA0KIA0KICMgQ2hlY2tz IGZvciBoZWFkZXIgZmlsZXMuDQogZWNobyAkYWNfbiAiY2hlY2tpbmcgaG93 IHRvIHJ1biB0aGUgQyBwcmVwcm9jZXNzb3IiIi4uLiAkYWNfYyIgMT4mNg0K LWVjaG8gImNvbmZpZ3VyZToxMzQzOiBjaGVja2luZyBob3cgdG8gcnVuIHRo ZSBDIHByZXByb2Nlc3NvciIgPiY1DQorZWNobyAiY29uZmlndXJlOjEzNjU6 IGNoZWNraW5nIGhvdyB0byBydW4gdGhlIEMgcHJlcHJvY2Vzc29yIiA+JjUN CiAjIE9uIFN1bnMsIHNvbWV0aW1lcyAkQ1BQIG5hbWVzIGEgZGlyZWN0b3J5 Lg0KIGlmIHRlc3QgLW4gIiRDUFAiICYmIHRlc3QgLWQgIiRDUFAiOyB0aGVu DQogICBDUFA9DQpAQCAtMTM1NCwxMyArMTM3NiwxMyBAQA0KICAgIyBPbiB0 aGUgTmVYVCwgY2MgLUUgcnVucyB0aGUgY29kZSB0aHJvdWdoIHRoZSBjb21w aWxlcidzIHBhcnNlciwNCiAgICMgbm90IGp1c3QgdGhyb3VnaCBjcHAuDQog ICBjYXQgPiBjb25mdGVzdC4kYWNfZXh0IDw8RU9GDQotI2xpbmUgMTM1OCAi Y29uZmlndXJlIg0KKyNsaW5lIDEzODAgImNvbmZpZ3VyZSINCiAjaW5jbHVk ZSAiY29uZmRlZnMuaCINCiAjaW5jbHVkZSA8YXNzZXJ0Lmg+DQogU3ludGF4 IEVycm9yDQogRU9GDQogYWNfdHJ5PSIkYWNfY3BwIGNvbmZ0ZXN0LiRhY19l eHQgPi9kZXYvbnVsbCAyPmNvbmZ0ZXN0Lm91dCINCi17IChldmFsIGVjaG8g Y29uZmlndXJlOjEzNjQ6IFwiJGFjX3RyeVwiKSAxPiY1OyAoZXZhbCAkYWNf dHJ5KSAyPiY1OyB9DQoreyAoZXZhbCBlY2hvIGNvbmZpZ3VyZToxMzg2OiBc IiRhY190cnlcIikgMT4mNTsgKGV2YWwgJGFjX3RyeSkgMj4mNTsgfQ0KIGFj X2Vycj1gZ3JlcCAtdiAnXiAqKycgY29uZnRlc3Qub3V0YA0KIGlmIHRlc3Qg LXogIiRhY19lcnIiOyB0aGVuDQogICA6DQpAQCAtMTM3MSwxMyArMTM5Mywx MyBAQA0KICAgcm0gLXJmIGNvbmZ0ZXN0Kg0KICAgQ1BQPSIke0NDLWNjfSAt RSAtdHJhZGl0aW9uYWwtY3BwIg0KICAgY2F0ID4gY29uZnRlc3QuJGFjX2V4 dCA8PEVPRg0KLSNsaW5lIDEzNzUgImNvbmZpZ3VyZSINCisjbGluZSAxMzk3 ICJjb25maWd1cmUiDQogI2luY2x1ZGUgImNvbmZkZWZzLmgiDQogI2luY2x1 ZGUgPGFzc2VydC5oPg0KIFN5bnRheCBFcnJvcg0KIEVPRg0KIGFjX3RyeT0i JGFjX2NwcCBjb25mdGVzdC4kYWNfZXh0ID4vZGV2L251bGwgMj5jb25mdGVz dC5vdXQiDQoteyAoZXZhbCBlY2hvIGNvbmZpZ3VyZToxMzgxOiBcIiRhY190 cnlcIikgMT4mNTsgKGV2YWwgJGFjX3RyeSkgMj4mNTsgfQ0KK3sgKGV2YWwg ZWNobyBjb25maWd1cmU6MTQwMzogXCIkYWNfdHJ5XCIpIDE+JjU7IChldmFs ICRhY190cnkpIDI+JjU7IH0NCiBhY19lcnI9YGdyZXAgLXYgJ14gKisnIGNv bmZ0ZXN0Lm91dGANCiBpZiB0ZXN0IC16ICIkYWNfZXJyIjsgdGhlbg0KICAg Og0KQEAgLTE0MDAsMTIgKzE0MjIsMTIgQEANCiBlY2hvICIkYWNfdCIiJENQ UCIgMT4mNg0KIA0KIGVjaG8gJGFjX24gImNoZWNraW5nIGZvciBBTlNJIEMg aGVhZGVyIGZpbGVzIiIuLi4gJGFjX2MiIDE+JjYNCi1lY2hvICJjb25maWd1 cmU6MTQwNDogY2hlY2tpbmcgZm9yIEFOU0kgQyBoZWFkZXIgZmlsZXMiID4m NQ0KK2VjaG8gImNvbmZpZ3VyZToxNDI2OiBjaGVja2luZyBmb3IgQU5TSSBD IGhlYWRlciBmaWxlcyIgPiY1DQogaWYgZXZhbCAidGVzdCBcImBlY2hvICck Jyd7J2FjX2N2X2hlYWRlcl9zdGRjJytzZXR9J2BcIiA9IHNldCI7IHRoZW4N CiAgIGVjaG8gJGFjX24gIihjYWNoZWQpICRhY19jIiAxPiY2DQogZWxzZQ0K ICAgY2F0ID4gY29uZnRlc3QuJGFjX2V4dCA8PEVPRg0KLSNsaW5lIDE0MDkg ImNvbmZpZ3VyZSINCisjbGluZSAxNDMxICJjb25maWd1cmUiDQogI2luY2x1 ZGUgImNvbmZkZWZzLmgiDQogI2luY2x1ZGUgPHN0ZGxpYi5oPg0KICNpbmNs dWRlIDxzdGRhcmcuaD4NCkBAIC0xNDEzLDcgKzE0MzUsNyBAQA0KICNpbmNs dWRlIDxmbG9hdC5oPg0KIEVPRg0KIGFjX3RyeT0iJGFjX2NwcCBjb25mdGVz dC4kYWNfZXh0ID4vZGV2L251bGwgMj5jb25mdGVzdC5vdXQiDQoteyAoZXZh bCBlY2hvIGNvbmZpZ3VyZToxNDE3OiBcIiRhY190cnlcIikgMT4mNTsgKGV2 YWwgJGFjX3RyeSkgMj4mNTsgfQ0KK3sgKGV2YWwgZWNobyBjb25maWd1cmU6 MTQzOTogXCIkYWNfdHJ5XCIpIDE+JjU7IChldmFsICRhY190cnkpIDI+JjU7 IH0NCiBhY19lcnI9YGdyZXAgLXYgJ14gKisnIGNvbmZ0ZXN0Lm91dGANCiBp ZiB0ZXN0IC16ICIkYWNfZXJyIjsgdGhlbg0KICAgcm0gLXJmIGNvbmZ0ZXN0 Kg0KQEAgLTE0MzAsNyArMTQ1Miw3IEBADQogaWYgdGVzdCAkYWNfY3ZfaGVh ZGVyX3N0ZGMgPSB5ZXM7IHRoZW4NCiAgICMgU3VuT1MgNC54IHN0cmluZy5o IGRvZXMgbm90IGRlY2xhcmUgbWVtKiwgY29udHJhcnkgdG8gQU5TSS4NCiBj YXQgPiBjb25mdGVzdC4kYWNfZXh0IDw8RU9GDQotI2xpbmUgMTQzNCAiY29u ZmlndXJlIg0KKyNsaW5lIDE0NTYgImNvbmZpZ3VyZSINCiAjaW5jbHVkZSAi Y29uZmRlZnMuaCINCiAjaW5jbHVkZSA8c3RyaW5nLmg+DQogRU9GDQpAQCAt MTQ0OCw3ICsxNDcwLDcgQEANCiBpZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3Rk YyA9IHllczsgdGhlbg0KICAgIyBJU0MgMi4wLjIgc3RkbGliLmggZG9lcyBu b3QgZGVjbGFyZSBmcmVlLCBjb250cmFyeSB0byBBTlNJLg0KIGNhdCA+IGNv bmZ0ZXN0LiRhY19leHQgPDxFT0YNCi0jbGluZSAxNDUyICJjb25maWd1cmUi DQorI2xpbmUgMTQ3NCAiY29uZmlndXJlIg0KICNpbmNsdWRlICJjb25mZGVm cy5oIg0KICNpbmNsdWRlIDxzdGRsaWIuaD4NCiBFT0YNCkBAIC0xNDY5LDcg KzE0OTEsNyBAQA0KICAgOg0KIGVsc2UNCiAgIGNhdCA+IGNvbmZ0ZXN0LiRh Y19leHQgPDxFT0YNCi0jbGluZSAxNDczICJjb25maWd1cmUiDQorI2xpbmUg MTQ5NSAiY29uZmlndXJlIg0KICNpbmNsdWRlICJjb25mZGVmcy5oIg0KICNp bmNsdWRlIDxjdHlwZS5oPg0KICNkZWZpbmUgSVNMT1dFUihjKSAoJ2EnIDw9 IChjKSAmJiAoYykgPD0gJ3onKQ0KQEAgLTE0ODAsNyArMTUwMiw3IEBADQog ZXhpdCAoMCk7IH0NCiANCiBFT0YNCi1pZiB7IChldmFsIGVjaG8gY29uZmln dXJlOjE0ODQ6IFwiJGFjX2xpbmtcIikgMT4mNTsgKGV2YWwgJGFjX2xpbmsp IDI+JjU7IH0gJiYgdGVzdCAtcyBjb25mdGVzdCAmJiAoLi9jb25mdGVzdDsg ZXhpdCkgMj4vZGV2L251bGwNCitpZiB7IChldmFsIGVjaG8gY29uZmlndXJl OjE1MDY6IFwiJGFjX2xpbmtcIikgMT4mNTsgKGV2YWwgJGFjX2xpbmspIDI+ JjU7IH0gJiYgdGVzdCAtcyBjb25mdGVzdCAmJiAoLi9jb25mdGVzdDsgZXhp dCkgMj4vZGV2L251bGwNCiB0aGVuDQogICA6DQogZWxzZQ0KQEAgLTE1MDcs MTcgKzE1MjksMTcgQEANCiBkbw0KIGFjX3NhZmU9YGVjaG8gIiRhY19oZHIi IHwgc2VkICd5JS4vKy0lX19wXyUnYA0KIGVjaG8gJGFjX24gImNoZWNraW5n IGZvciAkYWNfaGRyIiIuLi4gJGFjX2MiIDE+JjYNCi1lY2hvICJjb25maWd1 cmU6MTUxMTogY2hlY2tpbmcgZm9yICRhY19oZHIiID4mNQ0KK2VjaG8gImNv bmZpZ3VyZToxNTMzOiBjaGVja2luZyBmb3IgJGFjX2hkciIgPiY1DQogaWYg ZXZhbCAidGVzdCBcImBlY2hvICckJyd7J2FjX2N2X2hlYWRlcl8kYWNfc2Fm ZScrc2V0fSdgXCIgPSBzZXQiOyB0aGVuDQogICBlY2hvICRhY19uICIoY2Fj aGVkKSAkYWNfYyIgMT4mNg0KIGVsc2UNCiAgIGNhdCA+IGNvbmZ0ZXN0LiRh Y19leHQgPDxFT0YNCi0jbGluZSAxNTE2ICJjb25maWd1cmUiDQorI2xpbmUg MTUzOCAiY29uZmlndXJlIg0KICNpbmNsdWRlICJjb25mZGVmcy5oIg0KICNp bmNsdWRlIDwkYWNfaGRyPg0KIEVPRg0KIGFjX3RyeT0iJGFjX2NwcCBjb25m dGVzdC4kYWNfZXh0ID4vZGV2L251bGwgMj5jb25mdGVzdC5vdXQiDQoteyAo ZXZhbCBlY2hvIGNvbmZpZ3VyZToxNTIxOiBcIiRhY190cnlcIikgMT4mNTsg KGV2YWwgJGFjX3RyeSkgMj4mNTsgfQ0KK3sgKGV2YWwgZWNobyBjb25maWd1 cmU6MTU0MzogXCIkYWNfdHJ5XCIpIDE+JjU7IChldmFsICRhY190cnkpIDI+ JjU7IH0NCiBhY19lcnI9YGdyZXAgLXYgJ14gKisnIGNvbmZ0ZXN0Lm91dGAN CiBpZiB0ZXN0IC16ICIkYWNfZXJyIjsgdGhlbg0KICAgcm0gLXJmIGNvbmZ0 ZXN0Kg0KQEAgLTE1NDYsMTIgKzE1NjgsMTIgQEANCiANCiAjIENoZWNrcyBm b3IgdHlwZWRlZnMsIHN0cnVjdHVyZXMsIGFuZCBjb21waWxlciBjaGFyYWN0 ZXJpc3RpY3MuDQogZWNobyAkYWNfbiAiY2hlY2tpbmcgZm9yIHVpZF90IGlu IHN5cy90eXBlcy5oIiIuLi4gJGFjX2MiIDE+JjYNCi1lY2hvICJjb25maWd1 cmU6MTU1MDogY2hlY2tpbmcgZm9yIHVpZF90IGluIHN5cy90eXBlcy5oIiA+ JjUNCitlY2hvICJjb25maWd1cmU6MTU3MjogY2hlY2tpbmcgZm9yIHVpZF90 IGluIHN5cy90eXBlcy5oIiA+JjUNCiBpZiBldmFsICJ0ZXN0IFwiYGVjaG8g JyQnJ3snYWNfY3ZfdHlwZV91aWRfdCcrc2V0fSdgXCIgPSBzZXQiOyB0aGVu DQogICBlY2hvICRhY19uICIoY2FjaGVkKSAkYWNfYyIgMT4mNg0KIGVsc2UN CiAgIGNhdCA+IGNvbmZ0ZXN0LiRhY19leHQgPDxFT0YNCi0jbGluZSAxNTU1 ICJjb25maWd1cmUiDQorI2xpbmUgMTU3NyAiY29uZmlndXJlIg0KICNpbmNs dWRlICJjb25mZGVmcy5oIg0KICNpbmNsdWRlIDxzeXMvdHlwZXMuaD4NCiBF T0YNCkBAIC0xNTgwLDcgKzE2MDIsNyBAQA0KIGZpDQogDQogZWNobyAkYWNf biAiY2hlY2tpbmcgdHlwZSBvZiBhcnJheSBhcmd1bWVudCB0byBnZXRncm91 cHMiIi4uLiAkYWNfYyIgMT4mNg0KLWVjaG8gImNvbmZpZ3VyZToxNTg0OiBj aGVja2luZyB0eXBlIG9mIGFycmF5IGFyZ3VtZW50IHRvIGdldGdyb3VwcyIg PiY1DQorZWNobyAiY29uZmlndXJlOjE2MDY6IGNoZWNraW5nIHR5cGUgb2Yg YXJyYXkgYXJndW1lbnQgdG8gZ2V0Z3JvdXBzIiA+JjUNCiBpZiBldmFsICJ0 ZXN0IFwiYGVjaG8gJyQnJ3snYWNfY3ZfdHlwZV9nZXRncm91cHMnK3NldH0n YFwiID0gc2V0IjsgdGhlbg0KICAgZWNobyAkYWNfbiAiKGNhY2hlZCkgJGFj X2MiIDE+JjYNCiBlbHNlDQpAQCAtMTU4OCw3ICsxNjEwLDcgQEANCiAgIGFj X2N2X3R5cGVfZ2V0Z3JvdXBzPWNyb3NzDQogZWxzZQ0KICAgY2F0ID4gY29u ZnRlc3QuJGFjX2V4dCA8PEVPRg0KLSNsaW5lIDE1OTIgImNvbmZpZ3VyZSIN CisjbGluZSAxNjE0ICJjb25maWd1cmUiDQogI2luY2x1ZGUgImNvbmZkZWZz LmgiDQogDQogLyogVGhhbmtzIHRvIE1pa2UgUmVuZGVsbCBmb3IgdGhpcyB0 ZXN0LiAgKi8NCkBAIC0xNjEzLDcgKzE2MzUsNyBAQA0KIH0NCiANCiBFT0YN Ci1pZiB7IChldmFsIGVjaG8gY29uZmlndXJlOjE2MTc6IFwiJGFjX2xpbmtc IikgMT4mNTsgKGV2YWwgJGFjX2xpbmspIDI+JjU7IH0gJiYgdGVzdCAtcyBj b25mdGVzdCAmJiAoLi9jb25mdGVzdDsgZXhpdCkgMj4vZGV2L251bGwNCitp ZiB7IChldmFsIGVjaG8gY29uZmlndXJlOjE2Mzk6IFwiJGFjX2xpbmtcIikg MT4mNTsgKGV2YWwgJGFjX2xpbmspIDI+JjU7IH0gJiYgdGVzdCAtcyBjb25m dGVzdCAmJiAoLi9jb25mdGVzdDsgZXhpdCkgMj4vZGV2L251bGwNCiB0aGVu DQogICAgIGFjX2N2X3R5cGVfZ2V0Z3JvdXBzPWdpZF90DQogZWxzZQ0KQEAg LTE2MjcsNyArMTY0OSw3IEBADQogDQogaWYgdGVzdCAkYWNfY3ZfdHlwZV9n ZXRncm91cHMgPSBjcm9zczsgdGhlbg0KICAgICAgICAgY2F0ID4gY29uZnRl c3QuJGFjX2V4dCA8PEVPRg0KLSNsaW5lIDE2MzEgImNvbmZpZ3VyZSINCisj bGluZSAxNjUzICJjb25maWd1cmUiDQogI2luY2x1ZGUgImNvbmZkZWZzLmgi DQogI2luY2x1ZGUgPHVuaXN0ZC5oPg0KIEVPRg0KQEAgLTE2NTMsMTIgKzE2 NzUsMTIgQEANCiANCiAjIENoZWNrcyBmb3IgbGlicmFyeSBmdW5jdGlvbnMu DQogZWNobyAkYWNfbiAiY2hlY2tpbmcgZm9yIHZwcmludGYiIi4uLiAkYWNf YyIgMT4mNg0KLWVjaG8gImNvbmZpZ3VyZToxNjU3OiBjaGVja2luZyBmb3Ig dnByaW50ZiIgPiY1DQorZWNobyAiY29uZmlndXJlOjE2Nzk6IGNoZWNraW5n IGZvciB2cHJpbnRmIiA+JjUNCiBpZiBldmFsICJ0ZXN0IFwiYGVjaG8gJyQn J3snYWNfY3ZfZnVuY192cHJpbnRmJytzZXR9J2BcIiA9IHNldCI7IHRoZW4N CiAgIGVjaG8gJGFjX24gIihjYWNoZWQpICRhY19jIiAxPiY2DQogZWxzZQ0K ICAgY2F0ID4gY29uZnRlc3QuJGFjX2V4dCA8PEVPRg0KLSNsaW5lIDE2NjIg ImNvbmZpZ3VyZSINCisjbGluZSAxNjg0ICJjb25maWd1cmUiDQogI2luY2x1 ZGUgImNvbmZkZWZzLmgiDQogLyogU3lzdGVtIGhlYWRlciB0byBkZWZpbmUg X19zdHViIG1hY3JvcyBhbmQgaG9wZWZ1bGx5IGZldyBwcm90b3R5cGVzLA0K ICAgICB3aGljaCBjYW4gY29uZmxpY3Qgd2l0aCBjaGFyIHZwcmludGYoKTsg YmVsb3cuICAqLw0KQEAgLTE2ODEsNyArMTcwMyw3IEBADQogDQogOyByZXR1 cm4gMDsgfQ0KIEVPRg0KLWlmIHsgKGV2YWwgZWNobyBjb25maWd1cmU6MTY4 NTogXCIkYWNfbGlua1wiKSAxPiY1OyAoZXZhbCAkYWNfbGluaykgMj4mNTsg fSAmJiB0ZXN0IC1zIGNvbmZ0ZXN0OyB0aGVuDQoraWYgeyAoZXZhbCBlY2hv IGNvbmZpZ3VyZToxNzA3OiBcIiRhY19saW5rXCIpIDE+JjU7IChldmFsICRh Y19saW5rKSAyPiY1OyB9ICYmIHRlc3QgLXMgY29uZnRlc3Q7IHRoZW4NCiAg IHJtIC1yZiBjb25mdGVzdCoNCiAgIGV2YWwgImFjX2N2X2Z1bmNfdnByaW50 Zj15ZXMiDQogZWxzZQ0KQEAgLTE3MDUsMTIgKzE3MjcsMTIgQEANCiANCiBp ZiB0ZXN0ICIkYWNfY3ZfZnVuY192cHJpbnRmIiAhPSB5ZXM7IHRoZW4NCiBl Y2hvICRhY19uICJjaGVja2luZyBmb3IgX2RvcHJudCIiLi4uICRhY19jIiAx PiY2DQotZWNobyAiY29uZmlndXJlOjE3MDk6IGNoZWNraW5nIGZvciBfZG9w cm50IiA+JjUNCitlY2hvICJjb25maWd1cmU6MTczMTogY2hlY2tpbmcgZm9y IF9kb3BybnQiID4mNQ0KIGlmIGV2YWwgInRlc3QgXCJgZWNobyAnJCcneydh Y19jdl9mdW5jX19kb3BybnQnK3NldH0nYFwiID0gc2V0IjsgdGhlbg0KICAg ZWNobyAkYWNfbiAiKGNhY2hlZCkgJGFjX2MiIDE+JjYNCiBlbHNlDQogICBj YXQgPiBjb25mdGVzdC4kYWNfZXh0IDw8RU9GDQotI2xpbmUgMTcxNCAiY29u ZmlndXJlIg0KKyNsaW5lIDE3MzYgImNvbmZpZ3VyZSINCiAjaW5jbHVkZSAi Y29uZmRlZnMuaCINCiAvKiBTeXN0ZW0gaGVhZGVyIHRvIGRlZmluZSBfX3N0 dWIgbWFjcm9zIGFuZCBob3BlZnVsbHkgZmV3IHByb3RvdHlwZXMsDQogICAg IHdoaWNoIGNhbiBjb25mbGljdCB3aXRoIGNoYXIgX2RvcHJudCgpOyBiZWxv dy4gICovDQpAQCAtMTczMyw3ICsxNzU1LDcgQEANCiANCiA7IHJldHVybiAw OyB9DQogRU9GDQotaWYgeyAoZXZhbCBlY2hvIGNvbmZpZ3VyZToxNzM3OiBc IiRhY19saW5rXCIpIDE+JjU7IChldmFsICRhY19saW5rKSAyPiY1OyB9ICYm IHRlc3QgLXMgY29uZnRlc3Q7IHRoZW4NCitpZiB7IChldmFsIGVjaG8gY29u ZmlndXJlOjE3NTk6IFwiJGFjX2xpbmtcIikgMT4mNTsgKGV2YWwgJGFjX2xp bmspIDI+JjU7IH0gJiYgdGVzdCAtcyBjb25mdGVzdDsgdGhlbg0KICAgcm0g LXJmIGNvbmZ0ZXN0Kg0KICAgZXZhbCAiYWNfY3ZfZnVuY19fZG9wcm50PXll cyINCiBlbHNlDQpAQCAtMTkxOSw2ICsxOTQxLDcgQEANCiBzJUBNQUlMTUFO X0dJREAlJE1BSUxNQU5fR0lEJWcNCiBzJUBNQUlMX0dJREAlJE1BSUxfR0lE JWcNCiBzJUBDR0lfR0lEQCUkQ0dJX0dJRCVnDQorcyVAQ0dJRVhUQCUkQ0dJ RVhUJWcNCiBzJUBGUUROQCUkRlFETiVnDQogcyVAVVJMQCUkVVJMJWcNCiBz JUBDUFBAJSRDUFAlZw0KZGlmZiAtcnVOIG1haWxtYW4tMS1jbWRoYW5kbGVy L2NvbmZpZ3VyZS5pbiBtYWlsbWFuL2NvbmZpZ3VyZS5pbg0KLS0tIG1haWxt YW4tMS1jbWRoYW5kbGVyL2NvbmZpZ3VyZS5pbglGcmkgSmFuICA4IDA5OjE4 OjAzIDE5OTkNCisrKyBtYWlsbWFuL2NvbmZpZ3VyZS5pbglGcmkgSmFuICA4 IDA5OjMwOjIyIDE5OTkNCkBAIC0yOTgsNiArMjk4LDIwIEBADQogZmkNCiAN CiANCisjIENHSSBleHRlbnNpb24gY2hlY2tpbmcNCitBQ19TVUJTVChDR0lF WFQpDQorQUNfTVNHX0NIRUNLSU5HKGZvciBDR0kgZXh0ZW5zaW9uKQ0KK0FD X0FSR19XSVRIKGNnaS1leHQsIFsNCisgICAgICAgLS13aXRoLWNnaS1leHQg ICAgICAgIHNwZWNpZnkgZXh0ZW5zaW9ucyBvZiBDR0kgcHJvZ3JhbXNdKQ0K K2lmIHRlc3QgLXogIiR3aXRoX2NnaV9leHQiDQordGhlbg0KKyAgICBDR0lF WFQ9JycNCisgICAgd2l0aF9jZ2lfZXh0PSdubycNCitlbHNlDQorICAgIENH SUVYVD0kd2l0aF9jZ2lfZXh0DQorZmkNCitBQ19NU0dfUkVTVUxUKCR3aXRo X2NnaV9leHQpDQorDQogI01NX0ZJTkRfVVNFUl9JRChBTElBU19VSUQsIG1h aWxtYW4sIGFsaWFzX3dyYXBwZXIpDQogI01NX0ZJTkRfR1JPVVBfSUQoQUxJ QVNfR0lELCBtYWlsLCBhbGlhc193cmFwcGVyKQ0KIA0KZGlmZiAtcnVOIG1h aWxtYW4tMS1jbWRoYW5kbGVyL2Nyb24vY2hlY2tkYnMgbWFpbG1hbi9jcm9u L2NoZWNrZGJzDQotLS0gbWFpbG1hbi0xLWNtZGhhbmRsZXIvY3Jvbi9jaGVj a2RicwlGcmkgQXVnIDE0IDIzOjU2OjA2IDE5OTgNCisrKyBtYWlsbWFuL2Ny b24vY2hlY2tkYnMJRnJpIEphbiAgOCAwOTozMDoyMiAxOTk5DQpAQCAtMzYs NyArMzYsNyBAQA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB7J2NvdW50JzogY291bnQsDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAnaG9zdF9uYW1lJzogbGlzdC5ob3N0X25hbWUsDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAnYWRtaW5EQic6DQot ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsaXN0LkdldEFi c29sdXRlU2NyaXB0VVJMKCdhZG1pbmRiJyksDQorICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBsaXN0LkdldEFic29sdXRlU2NyaXB0VVJM KG1tX2NmZy5hZG1pbmRiX2NnaSksDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAncmVhbF9uYW1lJzogbGlzdC5yZWFsX25hbWUsDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB9KQ0KIAkgICAg bGlzdC5TZW5kVGV4dFRvVXNlcihzdWJqZWN0ID0gJyVkICVzIGFkbWluIHJl cXVlc3Qocykgd2FpdGluZycgJSANCmRpZmYgLXJ1TiBtYWlsbWFuLTEtY21k aGFuZGxlci9zY3JpcHRzL01ha2VmaWxlLmluIG1haWxtYW4vc2NyaXB0cy9N YWtlZmlsZS5pbg0KLS0tIG1haWxtYW4tMS1jbWRoYW5kbGVyL3NjcmlwdHMv TWFrZWZpbGUuaW4JVGh1IE9jdCAyMiAwOToyOToyNyAxOTk4DQorKysgbWFp bG1hbi9zY3JpcHRzL01ha2VmaWxlLmluCUZyaSBKYW4gIDggMDk6MzA6MjIg MTk5OQ0KQEAgLTMxLDcgKzMxLDcgQEANCiBDQz0JCUBDQ0ANCiBDSE1PRD0g IAlAQ0hNT0RADQogSU5TVEFMTD0JQElOU1RBTExADQotDQorQ0dJRVhUPQkJ QENHSUVYVEANCiBERUZTPSAgIAlAREVGU0ANCiANCiAjIEN1c3RvbWl6YWJs ZSBidXQgbm90IHNldCBieSBjb25maWd1cmUNCmRpZmYgLXJ1TiBtYWlsbWFu LTEtY21kaGFuZGxlci9zcmMvTWFrZWZpbGUuaW4gbWFpbG1hbi9zcmMvTWFr ZWZpbGUuaW4NCi0tLSBtYWlsbWFuLTEtY21kaGFuZGxlci9zcmMvTWFrZWZp bGUuaW4JRnJpIEphbiAgOCAwOToyMzo0MiAxOTk5DQorKysgbWFpbG1hbi9z cmMvTWFrZWZpbGUuaW4JRnJpIEphbiAgOCAwOTozMDoyMiAxOTk5DQpAQCAt NDYsNyArNDYsNyBAQA0KIE9QVD0JCUBPUFRADQogQ0ZMQUdTPQkJJChPUFQp ICQoREVGUykNCiBDR0lESVI9IAkkKGV4ZWNfcHJlZml4KS9jZ2ktYmluDQot Q0dJRVhUPQkJDQorQ0dJRVhUPQkJQENHSUVYVEANCiBNQUlMRElSPQkkKGV4 ZWNfcHJlZml4KS9tYWlsDQogDQogU0hFTEw9CQkvYmluL3NoDQo= ---456965764-233999344-915788868=:3512 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="mailman-3-mtu.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="mailman-3-mtu.patch" ZGlmZiAtcnVOIG1haWxtYW4tMi1jZ2lleHQvTWFpbG1hbi9PdXRnb2luZ1F1 ZXVlLnB5IG1haWxtYW4vTWFpbG1hbi9PdXRnb2luZ1F1ZXVlLnB5DQotLS0g bWFpbG1hbi0yLWNnaWV4dC9NYWlsbWFuL091dGdvaW5nUXVldWUucHkJRnJp IEphbiAgOCAwOToxODoxNyAxOTk5DQorKysgbWFpbG1hbi9NYWlsbWFuL091 dGdvaW5nUXVldWUucHkJRnJpIEphbiAgOCAwOTozMzoxNSAxOTk5DQpAQCAt NzcsNiArNzcsOSBAQA0KICMgICAgYW4gYWN0aXZlIHN0YXRlIGZvciB0b28g bG9uZyBhbmQgYXR0ZW1wdCBhIGRlbGl2ZXJ5DQogIw0KIGRlZiBwcm9jZXNz UXVldWUoKToNCisgICAgaW1wb3J0IG1tX2NmZw0KKyAgICBpZiBtbV9jZmcu TUFJTEVSX0NNRDoNCisJcmV0dXJuDQogICAgIGltcG9ydCBmbG9jaw0KICAg ICBpbXBvcnQgdGltZQ0KICAgICBpbXBvcnQgVXRpbHMNCkBAIC0xNzYsNCAr MTc5LDcgQEANCiAjIHJlbW92ZSBpdCBmcm9tIHRoZSBxdWV1ZSANCiAjDQog ZGVmIGRlcXVldWVNZXNzYWdlKHFfZW50cnkpOg0KLSAgICBvcy51bmxpbmso cV9lbnRyeSkNCisgICAgdHJ5Og0KKwlvcy51bmxpbmsocV9lbnRyeSkNCisg ICAgZXhjZXB0Og0KKwlwYXNzDQpkaWZmIC1ydU4gbWFpbG1hbi0yLWNnaWV4 dC9NYWlsbWFuL1V0aWxzLnB5IG1haWxtYW4vTWFpbG1hbi9VdGlscy5weQ0K LS0tIG1haWxtYW4tMi1jZ2lleHQvTWFpbG1hbi9VdGlscy5weQlGcmkgSmFu ICA4IDA5OjE4OjIwIDE5OTkNCisrKyBtYWlsbWFuL01haWxtYW4vVXRpbHMu cHkJRnJpIEphbiAgOCAwOTozNDozNiAxOTk5DQpAQCAtMTY4LDYgKzE2OCwy OSBAQA0KIA0KIA0KIGRlZiBUcnlTTVRQRGVsaXZlcnkocmVjaXBpZW50LCBz ZW5kZXIsIHRleHQsIHF1ZXVlX2VudHJ5KToNCisgICAgaW1wb3J0IHR5cGVz DQorDQorICAgIGlmIHR5cGUobW1fY2ZnLk1BSUxFUl9DTUQpID09IHR5cGVz LlN0cmluZ1R5cGUgYW5kIGxlbihtbV9jZmcuTUFJTEVSX0NNRCk6DQorIAly ZWNpcCA9IFtdDQorIAlpZiB0eXBlKHJlY2lwaWVudCkgPT0gdHlwZXMuU3Ry aW5nVHlwZToNCisgCSAgICByZWNpcCA9IFtyZWNpcGllbnRdDQorIAllbGlm IHR5cGUocmVjaXBpZW50KSA9PSB0eXBlcy5MaXN0VHlwZToNCisgCSAgICBy ZWNpcCA9IHJlY2lwaWVudA0KKyAJZWxzZToNCisgCSAgICByZXR1cm4NCisg CSAgICAjIFdoYXQgZWxzZSB3ZSBjYW4gZG8/IExvZz8NCisgCXRyeToNCisg CSAgICBwcGUgPSBvcy5wb3BlbihtbV9jZmcuTUFJTEVSX0NNRCAlIHsNCisg CQkgICAgJzxtbV9zZW5kZXI+Jzogc2VuZGVyLA0KKyAJCSAgICAnPG1tX3Jl Y2lwaWVudHM+Jzogc3RyaW5nLmpvaW4oJyAnLCByZWNpcCksDQorIAkJfSwg J3cnKQ0KKyAJICAgIHBwZS53cml0ZSh0ZXh0KQ0KKyAJICAgIHBwZS5jbG9z ZSgpDQorIAkgICAgcmV0dXJuDQorIAlleGNlcHQ6DQorIAkgICAgcGFzcw0K KyAJICAgICMgVHJ5IHRvIGRlbGl2ZXIgdmlhIFNNVFAgcG9ydCBpbnN0ZWFk DQorIA0KICAgICBpbXBvcnQgc29ja2V0DQogICAgIGltcG9ydCBPdXRnb2lu Z1F1ZXVlDQogDQpkaWZmIC1ydU4gbWFpbG1hbi0yLWNnaWV4dC9NYWlsbWFu L21tX2NmZy5weS5kaXN0LmluIG1haWxtYW4vTWFpbG1hbi9tbV9jZmcucHku ZGlzdC5pbg0KLS0tIG1haWxtYW4tMi1jZ2lleHQvTWFpbG1hbi9tbV9jZmcu cHkuZGlzdC5pbglGcmkgSmFuICA4IDA5OjMwOjIyIDE5OTkNCisrKyBtYWls bWFuL01haWxtYW4vbW1fY2ZnLnB5LmRpc3QuaW4JRnJpIEphbiAgOCAwOToz MzoxNSAxOTk5DQpAQCAtNTUsNSArNTUsNyBAQA0KIFBVQkxJQ19BUkNISVZF X1VSTCA9ICcvcGlwZXJtYWlsQENHSUVYVEAnDQogUFJJVkFURV9BUkNISVZF X1VSTCA9ICcvbWFpbG1hbi9wcml2YXRlQENHSUVYVEAnDQogDQorTUFJTEVS X0NNRAkgID0gJ0BTRU5ETUFJTEAnDQorDQogIyBOb3RlIC0gaWYgeW91J3Jl IGxvb2tpbmcgZm9yIHNvbWV0aGluZyB0aGF0IGlzIGltcG9ydGVkIGZyb20g bW1fY2ZnLCBidXQgeW91DQogIyBkaWRuJ3QgZmluZCBpdCBhYm92ZSwgaXQn cyBwcm9iYWJseSBpbiBEZWZhdWx0cy5weS4NCmRpZmYgLXJ1TiBtYWlsbWFu LTItY2dpZXh0L2NvbmZpZ3VyZSBtYWlsbWFuL2NvbmZpZ3VyZQ0KLS0tIG1h aWxtYW4tMi1jZ2lleHQvY29uZmlndXJlCUZyaSBKYW4gIDggMDk6MzI6Mjkg MTk5OQ0KKysrIG1haWxtYW4vY29uZmlndXJlCUZyaSBKYW4gIDggMDk6NDg6 MDYgMTk5OQ0KQEAgLTI3LDcgKzI3LDEwIEBADQogCS0td2l0aC1jZ2ktZ2lk ICAJc3BlY2lmeSBHSUQgQ0dJIHByb2dyYW1zIHJ1biBhcyINCiBhY19oZWxw PSIkYWNfaGVscA0KIA0KLSAgICAgICAtLXdpdGgtY2dpLWV4dCAgICAgICAg c3BlY2lmeSBleHRlbnNpb25zIG9mIENHSSBwcm9ncmFtcyINCisJLS13aXRo LWNnaS1leHQgICAgICAgIHNwZWNpZnkgZXh0ZW5zaW9ucyBvZiBDR0kgcHJv Z3JhbXMiDQorYWNfaGVscD0iJGFjX2hlbHANCisNCisJLS13aXRoLXNlbmRt YWlsICAgICAgZG8gZGVsaXZlcmllcyB3aXRoIHRoaXMgcHJvZ3JhbSINCiAN CiAjIEluaXRpYWxpemUgc29tZSB2YXJpYWJsZXMgc2V0IGJ5IG9wdGlvbnMu DQogIyBUaGUgdmFyaWFibGVzIGhhdmUgdGhlIHNhbWUgbmFtZXMgYXMgdGhl IG9wdGlvbnMsIHdpdGgNCkBAIC01NDgsNyArNTUxLDcgQEANCiANCiAjIENo ZWNrIGZvciBQeXRob24hICBCZXR0ZXIgYmUgZm91bmQgb24gJFBBVEgNCiBl Y2hvICRhY19uICJjaGVja2luZyBmb3IgLS13aXRoLXB5dGhvbiIiLi4uICRh Y19jIiAxPiY2DQotZWNobyAiY29uZmlndXJlOjU1MjogY2hlY2tpbmcgZm9y IC0td2l0aC1weXRob24iID4mNQ0KK2VjaG8gImNvbmZpZ3VyZTo1NTU6IGNo ZWNraW5nIGZvciAtLXdpdGgtcHl0aG9uIiA+JjUNCiAjIENoZWNrIHdoZXRo ZXIgLS13aXRoLXB5dGhvbiBvciAtLXdpdGhvdXQtcHl0aG9uIHdhcyBnaXZl bi4NCiBpZiB0ZXN0ICIke3dpdGhfcHl0aG9uK3NldH0iID0gc2V0OyB0aGVu DQogICB3aXRodmFsPSIkd2l0aF9weXRob24iDQpAQCAtNTYyLDcgKzU2NSw3 IEBADQogCSMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAicHl0aG9uIiwg c28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4NCiBzZXQg ZHVtbXkgcHl0aG9uOyBhY193b3JkPSQyDQogZWNobyAkYWNfbiAiY2hlY2tp bmcgZm9yICRhY193b3JkIiIuLi4gJGFjX2MiIDE+JjYNCi1lY2hvICJjb25m aWd1cmU6NTY2OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQ0KK2VjaG8g ImNvbmZpZ3VyZTo1Njk6IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1DQog aWYgZXZhbCAidGVzdCBcImBlY2hvICckJyd7J2FjX2N2X3BhdGhfd2l0aF9w eXRob24nK3NldH0nYFwiID0gc2V0IjsgdGhlbg0KICAgZWNobyAkYWNfbiAi KGNhY2hlZCkgJGFjX2MiIDE+JjYNCiBlbHNlDQpAQCAtNTk0LDcgKzU5Nyw3 IEBADQogZmkNCiANCiBlY2hvICRhY19uICJjaGVja2luZyBQeXRob24gaW50 ZXJwcmV0ZXIiIi4uLiAkYWNfYyIgMT4mNg0KLWVjaG8gImNvbmZpZ3VyZTo1 OTg6IGNoZWNraW5nIFB5dGhvbiBpbnRlcnByZXRlciIgPiY1DQorZWNobyAi Y29uZmlndXJlOjYwMTogY2hlY2tpbmcgUHl0aG9uIGludGVycHJldGVyIiA+ JjUNCiBpZiB0ZXN0ICEgLXggJHdpdGhfcHl0aG9uDQogdGhlbg0KICAgICB7 IGVjaG8gImNvbmZpZ3VyZTogZXJyb3I6IA0KQEAgLTYzOCw3ICs2NDEsNyBA QA0KICMgU1ZSNCAvdXNyL3VjYi9pbnN0YWxsLCB3aGljaCB0cmllcyB0byB1 c2UgdGhlIG5vbmV4aXN0ZW50IGdyb3VwICJzdGFmZiINCiAjIC4vaW5zdGFs bCwgd2hpY2ggY2FuIGJlIGVycm9uZW91c2x5IGNyZWF0ZWQgYnkgbWFrZSBm cm9tIC4vaW5zdGFsbC5zaC4NCiBlY2hvICRhY19uICJjaGVja2luZyBmb3Ig YSBCU0QgY29tcGF0aWJsZSBpbnN0YWxsIiIuLi4gJGFjX2MiIDE+JjYNCi1l Y2hvICJjb25maWd1cmU6NjQyOiBjaGVja2luZyBmb3IgYSBCU0QgY29tcGF0 aWJsZSBpbnN0YWxsIiA+JjUNCitlY2hvICJjb25maWd1cmU6NjQ1OiBjaGVj a2luZyBmb3IgYSBCU0QgY29tcGF0aWJsZSBpbnN0YWxsIiA+JjUNCiBpZiB0 ZXN0IC16ICIkSU5TVEFMTCI7IHRoZW4NCiBpZiBldmFsICJ0ZXN0IFwiYGVj aG8gJyQnJ3snYWNfY3ZfcGF0aF9pbnN0YWxsJytzZXR9J2BcIiA9IHNldCI7 IHRoZW4NCiAgIGVjaG8gJGFjX24gIihjYWNoZWQpICRhY19jIiAxPiY2DQpA QCAtNjg4LDcgKzY5MSw3IEBADQogdGVzdCAteiAiJElOU1RBTExfREFUQSIg JiYgSU5TVEFMTF9EQVRBPScke0lOU1RBTEx9IC1tIDY0NCcNCiANCiBlY2hv ICRhY19uICJjaGVja2luZyB3aGV0aGVyICR7TUFLRS1tYWtlfSBzZXRzIFwk e01BS0V9IiIuLi4gJGFjX2MiIDE+JjYNCi1lY2hvICJjb25maWd1cmU6Njky OiBjaGVja2luZyB3aGV0aGVyICR7TUFLRS1tYWtlfSBzZXRzIFwke01BS0V9 IiA+JjUNCitlY2hvICJjb25maWd1cmU6Njk1OiBjaGVja2luZyB3aGV0aGVy ICR7TUFLRS1tYWtlfSBzZXRzIFwke01BS0V9IiA+JjUNCiBzZXQgZHVtbXkg JHtNQUtFLW1ha2V9OyBhY19tYWtlPWBlY2hvICIkMiIgfCBzZWQgJ3klLi8r LSVfX3BfJSdgDQogaWYgZXZhbCAidGVzdCBcImBlY2hvICckJyd7J2FjX2N2 X3Byb2dfbWFrZV8ke2FjX21ha2V9X3NldCcrc2V0fSdgXCIgPSBzZXQiOyB0 aGVuDQogICBlY2hvICRhY19uICIoY2FjaGVkKSAkYWNfYyIgMT4mNg0KQEAg LTcxNyw3ICs3MjAsNyBAQA0KIA0KICMgRmluZCBjb21waWxlciwgYWxsb3cg YWx0ZXJuYXRpdmVzIHRvIGdjYw0KIGVjaG8gJGFjX24gImNoZWNraW5nIGZv ciAtLXdpdGhvdXQtZ2NjIiIuLi4gJGFjX2MiIDE+JjYNCi1lY2hvICJjb25m aWd1cmU6NzIxOiBjaGVja2luZyBmb3IgLS13aXRob3V0LWdjYyIgPiY1DQor ZWNobyAiY29uZmlndXJlOjcyNDogY2hlY2tpbmcgZm9yIC0td2l0aG91dC1n Y2MiID4mNQ0KICMgQ2hlY2sgd2hldGhlciAtLXdpdGgtZ2NjIG9yIC0td2l0 aG91dC1nY2Mgd2FzIGdpdmVuLg0KIGlmIHRlc3QgIiR7d2l0aF9nY2Mrc2V0 fSIgPSBzZXQ7IHRoZW4NCiAgIHdpdGh2YWw9IiR3aXRoX2djYyINCkBAIC03 NDYsNyArNzQ5LDcgQEANCiAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2Yg ImdjYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3Mu DQogc2V0IGR1bW15IGdjYzsgYWNfd29yZD0kMg0KIGVjaG8gJGFjX24gImNo ZWNraW5nIGZvciAkYWNfd29yZCIiLi4uICRhY19jIiAxPiY2DQotZWNobyAi Y29uZmlndXJlOjc1MDogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUNCitl Y2hvICJjb25maWd1cmU6NzUzOiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4m NQ0KIGlmIGV2YWwgInRlc3QgXCJgZWNobyAnJCcneydhY19jdl9wcm9nX0ND JytzZXR9J2BcIiA9IHNldCI7IHRoZW4NCiAgIGVjaG8gJGFjX24gIihjYWNo ZWQpICRhY19jIiAxPiY2DQogZWxzZQ0KQEAgLTc3NSw3ICs3NzgsNyBAQA0K ICAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJjYyIsIHNvIGl0IGNh biBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuDQogc2V0IGR1bW15IGNj OyBhY193b3JkPSQyDQogZWNobyAkYWNfbiAiY2hlY2tpbmcgZm9yICRhY193 b3JkIiIuLi4gJGFjX2MiIDE+JjYNCi1lY2hvICJjb25maWd1cmU6Nzc5OiBj aGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQ0KK2VjaG8gImNvbmZpZ3VyZTo3 ODI6IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1DQogaWYgZXZhbCAidGVz dCBcImBlY2hvICckJyd7J2FjX2N2X3Byb2dfQ0MnK3NldH0nYFwiID0gc2V0 IjsgdGhlbg0KICAgZWNobyAkYWNfbiAiKGNhY2hlZCkgJGFjX2MiIDE+JjYN CiBlbHNlDQpAQCAtODIzLDcgKzgyNiw3IEBADQogZmkNCiANCiBlY2hvICRh Y19uICJjaGVja2luZyB3aGV0aGVyIHRoZSBDIGNvbXBpbGVyICgkQ0MgJENG TEFHUyAkTERGTEFHUykgd29ya3MiIi4uLiAkYWNfYyIgMT4mNg0KLWVjaG8g ImNvbmZpZ3VyZTo4Mjc6IGNoZWNraW5nIHdoZXRoZXIgdGhlIEMgY29tcGls ZXIgKCRDQyAkQ0ZMQUdTICRMREZMQUdTKSB3b3JrcyIgPiY1DQorZWNobyAi Y29uZmlndXJlOjgzMDogY2hlY2tpbmcgd2hldGhlciB0aGUgQyBjb21waWxl ciAoJENDICRDRkxBR1MgJExERkxBR1MpIHdvcmtzIiA+JjUNCiANCiBhY19l eHQ9Yw0KICMgQ0ZMQUdTIGlzIG5vdCBpbiBhY19jcHAgYmVjYXVzZSAtZywg LU8sIGV0Yy4gYXJlIG5vdCB2YWxpZCBjcHAgb3B0aW9ucy4NCkBAIC04MzMs MTEgKzgzNiwxMSBAQA0KIGNyb3NzX2NvbXBpbGluZz0kYWNfY3ZfcHJvZ19j Y19jcm9zcw0KIA0KIGNhdCA+IGNvbmZ0ZXN0LiRhY19leHQgPDxFT0YNCi0j bGluZSA4MzcgImNvbmZpZ3VyZSINCisjbGluZSA4NDAgImNvbmZpZ3VyZSIN CiAjaW5jbHVkZSAiY29uZmRlZnMuaCINCiBtYWluKCl7cmV0dXJuKDApO30N CiBFT0YNCi1pZiB7IChldmFsIGVjaG8gY29uZmlndXJlOjg0MTogXCIkYWNf bGlua1wiKSAxPiY1OyAoZXZhbCAkYWNfbGluaykgMj4mNTsgfSAmJiB0ZXN0 IC1zIGNvbmZ0ZXN0OyB0aGVuDQoraWYgeyAoZXZhbCBlY2hvIGNvbmZpZ3Vy ZTo4NDQ6IFwiJGFjX2xpbmtcIikgMT4mNTsgKGV2YWwgJGFjX2xpbmspIDI+ JjU7IH0gJiYgdGVzdCAtcyBjb25mdGVzdDsgdGhlbg0KICAgYWNfY3ZfcHJv Z19jY193b3Jrcz15ZXMNCiAgICMgSWYgd2UgY2FuJ3QgcnVuIGEgdHJpdmlh bCBwcm9ncmFtLCB3ZSBhcmUgcHJvYmFibHkgdXNpbmcgYSBjcm9zcyBjb21w aWxlci4NCiAgIGlmICguL2NvbmZ0ZXN0OyBleGl0KSAyPi9kZXYvbnVsbDsg dGhlbg0KQEAgLTg1NywxMiArODYwLDEyIEBADQogICB7IGVjaG8gImNvbmZp Z3VyZTogZXJyb3I6IGluc3RhbGxhdGlvbiBvciBjb25maWd1cmF0aW9uIHBy b2JsZW06IEMgY29tcGlsZXIgY2Fubm90IGNyZWF0ZSBleGVjdXRhYmxlcy4i IDE+JjI7IGV4aXQgMTsgfQ0KIGZpDQogZWNobyAkYWNfbiAiY2hlY2tpbmcg d2hldGhlciB0aGUgQyBjb21waWxlciAoJENDICRDRkxBR1MgJExERkxBR1Mp IGlzIGEgY3Jvc3MtY29tcGlsZXIiIi4uLiAkYWNfYyIgMT4mNg0KLWVjaG8g ImNvbmZpZ3VyZTo4NjE6IGNoZWNraW5nIHdoZXRoZXIgdGhlIEMgY29tcGls ZXIgKCRDQyAkQ0ZMQUdTICRMREZMQUdTKSBpcyBhIGNyb3NzLWNvbXBpbGVy IiA+JjUNCitlY2hvICJjb25maWd1cmU6ODY0OiBjaGVja2luZyB3aGV0aGVy IHRoZSBDIGNvbXBpbGVyICgkQ0MgJENGTEFHUyAkTERGTEFHUykgaXMgYSBj cm9zcy1jb21waWxlciIgPiY1DQogZWNobyAiJGFjX3QiIiRhY19jdl9wcm9n X2NjX2Nyb3NzIiAxPiY2DQogY3Jvc3NfY29tcGlsaW5nPSRhY19jdl9wcm9n X2NjX2Nyb3NzDQogDQogZWNobyAkYWNfbiAiY2hlY2tpbmcgd2hldGhlciB3 ZSBhcmUgdXNpbmcgR05VIEMiIi4uLiAkYWNfYyIgMT4mNg0KLWVjaG8gImNv bmZpZ3VyZTo4NjY6IGNoZWNraW5nIHdoZXRoZXIgd2UgYXJlIHVzaW5nIEdO VSBDIiA+JjUNCitlY2hvICJjb25maWd1cmU6ODY5OiBjaGVja2luZyB3aGV0 aGVyIHdlIGFyZSB1c2luZyBHTlUgQyIgPiY1DQogaWYgZXZhbCAidGVzdCBc ImBlY2hvICckJyd7J2FjX2N2X3Byb2dfZ2NjJytzZXR9J2BcIiA9IHNldCI7 IHRoZW4NCiAgIGVjaG8gJGFjX24gIihjYWNoZWQpICRhY19jIiAxPiY2DQog ZWxzZQ0KQEAgLTg3MSw3ICs4NzQsNyBAQA0KICAgeWVzOw0KICNlbmRpZg0K IEVPRg0KLWlmIHsgYWNfdHJ5PScke0NDLWNjfSAtRSBjb25mdGVzdC5jJzsg eyAoZXZhbCBlY2hvIGNvbmZpZ3VyZTo4NzU6IFwiJGFjX3RyeVwiKSAxPiY1 OyAoZXZhbCAkYWNfdHJ5KSAyPiY1OyB9OyB9IHwgZWdyZXAgeWVzID4vZGV2 L251bGwgMj4mMTsgdGhlbg0KK2lmIHsgYWNfdHJ5PScke0NDLWNjfSAtRSBj b25mdGVzdC5jJzsgeyAoZXZhbCBlY2hvIGNvbmZpZ3VyZTo4Nzg6IFwiJGFj X3RyeVwiKSAxPiY1OyAoZXZhbCAkYWNfdHJ5KSAyPiY1OyB9OyB9IHwgZWdy ZXAgeWVzID4vZGV2L251bGwgMj4mMTsgdGhlbg0KICAgYWNfY3ZfcHJvZ19n Y2M9eWVzDQogZWxzZQ0KICAgYWNfY3ZfcHJvZ19nY2M9bm8NCkBAIC04ODYs NyArODg5LDcgQEANCiAgIGFjX3NhdmVfQ0ZMQUdTPSIkQ0ZMQUdTIg0KICAg Q0ZMQUdTPQ0KICAgZWNobyAkYWNfbiAiY2hlY2tpbmcgd2hldGhlciAke0ND LWNjfSBhY2NlcHRzIC1nIiIuLi4gJGFjX2MiIDE+JjYNCi1lY2hvICJjb25m aWd1cmU6ODkwOiBjaGVja2luZyB3aGV0aGVyICR7Q0MtY2N9IGFjY2VwdHMg LWciID4mNQ0KK2VjaG8gImNvbmZpZ3VyZTo4OTM6IGNoZWNraW5nIHdoZXRo ZXIgJHtDQy1jY30gYWNjZXB0cyAtZyIgPiY1DQogaWYgZXZhbCAidGVzdCBc ImBlY2hvICckJyd7J2FjX2N2X3Byb2dfY2NfZycrc2V0fSdgXCIgPSBzZXQi OyB0aGVuDQogICBlY2hvICRhY19uICIoY2FjaGVkKSAkYWNfYyIgMT4mNg0K IGVsc2UNCkBAIC05MzQsNyArOTM3LDcgQEANCiAjIFB1bGwgdGhlIGhhc2gg bWFyayBvdXQgb2YgdGhlIG1hY3JvIGNhbGwgdG8gYXZvaWQgbTQgcHJvYmxl bXMuDQogYWNfbXNnPSJ3aGV0aGVyICMhIHdvcmtzIGluIHNoZWxsIHNjcmlw dHMiDQogZWNobyAkYWNfbiAiY2hlY2tpbmcgJGFjX21zZyIiLi4uICRhY19j IiAxPiY2DQotZWNobyAiY29uZmlndXJlOjkzODogY2hlY2tpbmcgJGFjX21z ZyIgPiY1DQorZWNobyAiY29uZmlndXJlOjk0MTogY2hlY2tpbmcgJGFjX21z ZyIgPiY1DQogaWYgZXZhbCAidGVzdCBcImBlY2hvICckJyd7J2FjX2N2X3N5 c19pbnRlcnByZXRlcicrc2V0fSdgXCIgPSBzZXQiOyB0aGVuDQogICBlY2hv ICRhY19uICIoY2FjaGVkKSAkYWNfYyIgMT4mNg0KIGVsc2UNCkBAIC05NzEs NyArOTc0LDcgQEANCiANCiAjIFVzZXIgYG1haWxtYW4nIG11c3QgZXhpc3QN CiBlY2hvICRhY19uICJjaGVja2luZyBmb3IgbWFpbG1hbiBVSUQiIi4uLiAk YWNfYyIgMT4mNg0KLWVjaG8gImNvbmZpZ3VyZTo5NzU6IGNoZWNraW5nIGZv ciBtYWlsbWFuIFVJRCIgPiY1DQorZWNobyAiY29uZmlndXJlOjk3ODogY2hl Y2tpbmcgZm9yIG1haWxtYW4gVUlEIiA+JjUNCiANCiAjIE1BSUxNQU5fVUlE ID09IHZhcmlhYmxlIG5hbWUNCiAjIG1haWxtYW4gPT0gdXNlciBpZCB0byBj aGVjayBmb3INCkBAIC0xMDE0LDcgKzEwMTcsNyBAQA0KIA0KICMgR3JvdXAg YG1haWxtYW4nIG11c3QgZXhpc3QNCiBlY2hvICRhY19uICJjaGVja2luZyBm b3IgbWFpbG1hbiBHSUQiIi4uLiAkYWNfYyIgMT4mNg0KLWVjaG8gImNvbmZp Z3VyZToxMDE4OiBjaGVja2luZyBmb3IgbWFpbG1hbiBHSUQiID4mNQ0KK2Vj aG8gImNvbmZpZ3VyZToxMDIxOiBjaGVja2luZyBmb3IgbWFpbG1hbiBHSUQi ID4mNQ0KIA0KICMgTUFJTE1BTl9HSUQgPT0gdmFyaWFibGUgbmFtZQ0KICMg bWFpbG1hbiA9PSB1c2VyIGlkIHRvIGNoZWNrIGZvcg0KQEAgLTEwNjYsNyAr MTA2OSw3IEBADQogZmkNCiANCiBlY2hvICRhY19uICJjaGVja2luZyBwZXJt aXNzaW9ucyBvbiAkcHJlZml4Y2hlY2siIi4uLiAkYWNfYyIgMT4mNg0KLWVj aG8gImNvbmZpZ3VyZToxMDcwOiBjaGVja2luZyBwZXJtaXNzaW9ucyBvbiAk cHJlZml4Y2hlY2siID4mNQ0KK2VjaG8gImNvbmZpZ3VyZToxMDczOiBjaGVj a2luZyBwZXJtaXNzaW9ucyBvbiAkcHJlZml4Y2hlY2siID4mNQ0KIA0KIGNh dCA+IGNvbmZ0ZXN0LnB5IDw8RU9GDQogaW1wb3J0IG9zLCBncnAsIHN0cmlu Zw0KQEAgLTExMTIsNyArMTExNSw3IEBADQogIyBOb3cgZmluZCB0aGUgVUlE cyBhbmQgR0lEcw0KICMgU3VwcG9ydCAtLXdpdGgtbWFpbC1naWQgYW5kIC0t d2l0aC1jZ2ktZ2lkDQogZWNobyAkYWNfbiAiY2hlY2tpbmcgZm9yIG1haWwg d3JhcHBlciBHSUQiIi4uLiAkYWNfYyIgMT4mNg0KLWVjaG8gImNvbmZpZ3Vy ZToxMTE2OiBjaGVja2luZyBmb3IgbWFpbCB3cmFwcGVyIEdJRCIgPiY1DQor ZWNobyAiY29uZmlndXJlOjExMTk6IGNoZWNraW5nIGZvciBtYWlsIHdyYXBw ZXIgR0lEIiA+JjUNCiAjIENoZWNrIHdoZXRoZXIgLS13aXRoLW1haWwtZ2lk IG9yIC0td2l0aG91dC1tYWlsLWdpZCB3YXMgZ2l2ZW4uDQogaWYgdGVzdCAi JHt3aXRoX21haWxfZ2lkK3NldH0iID0gc2V0OyB0aGVuDQogICB3aXRodmFs PSIkd2l0aF9tYWlsX2dpZCINCkBAIC0xMTI0LDcgKzExMjcsNyBAQA0KICAg ICBpZiBldmFsICJ0ZXN0IFwiYGVjaG8gJyQnJ3snYWNfY3ZfZ3JvdXBfbWFp bCcrc2V0fSdgXCIgPSBzZXQiOyB0aGVuDQogICBlY2hvICRhY19uICIoY2Fj aGVkKSAkYWNfYyIgMT4mNg0KIGVsc2UNCi0gICAgICBhY19jdl9ncm91cF9t YWlsPSJvdGhlciBtYWlsIGRhZW1vbiINCisgICAgICBhY19jdl9ncm91cF9t YWlsPSJub2ZpbGVzIG90aGVyIG1haWwgZGFlbW9uIg0KIGZpDQogDQogZWxz ZQ0KQEAgLTExNzMsNyArMTE3Niw3IEBADQogDQogDQogZWNobyAkYWNfbiAi Y2hlY2tpbmcgZm9yIENHSSB3cmFwcGVyIEdJRCIiLi4uICRhY19jIiAxPiY2 DQotZWNobyAiY29uZmlndXJlOjExNzc6IGNoZWNraW5nIGZvciBDR0kgd3Jh cHBlciBHSUQiID4mNQ0KK2VjaG8gImNvbmZpZ3VyZToxMTgwOiBjaGVja2lu ZyBmb3IgQ0dJIHdyYXBwZXIgR0lEIiA+JjUNCiAjIENoZWNrIHdoZXRoZXIg LS13aXRoLWNnaS1naWQgb3IgLS13aXRob3V0LWNnaS1naWQgd2FzIGdpdmVu Lg0KIGlmIHRlc3QgIiR7d2l0aF9jZ2lfZ2lkK3NldH0iID0gc2V0OyB0aGVu DQogICB3aXRodmFsPSIkd2l0aF9jZ2lfZ2lkIg0KQEAgLTEyMzIsMTEgKzEy MzUsMTMgQEANCiAqKioqKiBkb2N1bWVudGF0aW9uLCBhbmQgdGhlIElOU1RB TEwgZmlsZSBmb3IgZGV0YWlscyIgMT4mMjsgZXhpdCAxOyB9DQogZmkNCiAN CisjTU1fRklORF9VU0VSX0lEKEFMSUFTX1VJRCwgbWFpbG1hbiwgYWxpYXNf d3JhcHBlcikNCisjTU1fRklORF9HUk9VUF9JRChBTElBU19HSUQsIG1haWws IGFsaWFzX3dyYXBwZXIpDQogDQogIyBDR0kgZXh0ZW5zaW9uIGNoZWNraW5n DQogDQogZWNobyAkYWNfbiAiY2hlY2tpbmcgZm9yIENHSSBleHRlbnNpb24i Ii4uLiAkYWNfYyIgMT4mNg0KLWVjaG8gImNvbmZpZ3VyZToxMjQwOiBjaGVj a2luZyBmb3IgQ0dJIGV4dGVuc2lvbiIgPiY1DQorZWNobyAiY29uZmlndXJl OjEyNDU6IGNoZWNraW5nIGZvciBDR0kgZXh0ZW5zaW9uIiA+JjUNCiAjIENo ZWNrIHdoZXRoZXIgLS13aXRoLWNnaS1leHQgb3IgLS13aXRob3V0LWNnaS1l eHQgd2FzIGdpdmVuLg0KIGlmIHRlc3QgIiR7d2l0aF9jZ2lfZXh0K3NldH0i ID0gc2V0OyB0aGVuDQogICB3aXRodmFsPSIkd2l0aF9jZ2lfZXh0Ig0KQEAg LTEyNTIsOCArMTI1Nyw1NyBAQA0KIGZpDQogZWNobyAiJGFjX3QiIiR3aXRo X2NnaV9leHQiIDE+JjYNCiANCi0jTU1fRklORF9VU0VSX0lEKEFMSUFTX1VJ RCwgbWFpbG1hbiwgYWxpYXNfd3JhcHBlcikNCi0jTU1fRklORF9HUk9VUF9J RChBTElBU19HSUQsIG1haWwsIGFsaWFzX3dyYXBwZXIpDQorZWNobyAkYWNf biAiY2hlY2tpbmcgZm9yIHNlbmRtYWlsIHByb2dyYW1zIiIuLi4gJGFjX2Mi IDE+JjYNCitlY2hvICJjb25maWd1cmU6MTI2MjogY2hlY2tpbmcgZm9yIHNl bmRtYWlsIHByb2dyYW1zIiA+JjUNCisjIENoZWNrIHdoZXRoZXIgLS13aXRo LXNlbmRtYWlsIG9yIC0td2l0aG91dC1zZW5kbWFpbCB3YXMgZ2l2ZW4uDQor aWYgdGVzdCAiJHt3aXRoX3NlbmRtYWlsK3NldH0iID0gc2V0OyB0aGVuDQor ICB3aXRodmFsPSIkd2l0aF9zZW5kbWFpbCINCisgIDoNCitmaQ0KKw0KK2lm IHRlc3QgLXogIiR3aXRoX3NlbmRtYWlsIg0KK3RoZW4NCisgICAgaWYgZXZh bCAidGVzdCBcImBlY2hvICckJyd7J2FjX2N2X3NlbmRtYWlsJytzZXR9J2Bc IiA9IHNldCI7IHRoZW4NCisgIGVjaG8gJGFjX24gIihjYWNoZWQpICRhY19j IiAxPiY2DQorZWxzZQ0KKyAgCWFjX2N2X3NlbmRtYWlsPSIvdmFyL3FtYWls L2Jpbi9xbWFpbC1pbmplY3QgL3Vzci9saWIvc2VuZG1haWwgL3Vzci9zYmlu L3NlbmRtYWlsIC9ldGMvc2VuZG1haWwiDQorZmkNCisNCitlbHNlDQorICAg IGFjX2N2X3NlbmRtYWlsPSR3aXRoX3NlbmRtYWlsDQorZmkNCisNCisNCitj YXQgPiBjb25mdGVzdC5weSA8PEVPRg0KK2ltcG9ydCBvcywgc3RyaW5nDQor ZmlsID0gJycNCitmb3IgZmxlIGluIHN0cmluZy5zcGxpdCgiJGFjX2N2X3Nl bmRtYWlsIik6DQorICAgIHRyeToNCisJbCA9IG9zLnN0YXQoZmxlKQ0KKwlp ZiBsWzBdICYgMHgxMTE6DQorCSAgICBmaWwgPSBmbGUNCisJICAgIGJyZWFr DQorICAgIGV4Y2VwdDoNCisJcGFzcw0KK2ZwID0gb3BlbignY29uZnRlc3Qu b3V0JywgJ3cnKQ0KK2ZwLndyaXRlKCclc1xuJyAlIGZpbCkNCitmcC5jbG9z ZQ0KK0VPRg0KKw0KKyRQWVRIT04gY29uZnRlc3QucHkNCitTRU5ETUFJTD1g Y2F0IGNvbmZ0ZXN0Lm91dGANCisjIFBhcmFtZXRlcnMgYXJlIHRoZSBzYW1l IGZvciBxbWFpbC1pbmplY3QgYW5kIHNlbmRtYWlsLWNsb25lcyBidXQgd2hv IGtub3dzPw0KK2lmIHRlc3QgISAteiAkU0VORE1BSUw7IHRoZW4NCisgICAg aWYgdGVzdCAke1NFTkRNQUlMJSVxbWFpbC1pbmplY3R9ICE9ICRTRU5ETUFJ TDsgdGhlbg0KKwlTRU5ETUFJTD0iJFNFTkRNQUlMIC1mIDxtbV9zZW5kZXI+ IDxtbV9yZWNpcGllbnRzPiINCisgICAgZWxpZiB0ZXN0ICR7U0VORE1BSUwl JXNlbmRtYWlsfSAhPSAkU0VORE1BSUw7IHRoZW4NCisJU0VORE1BSUw9IiRT RU5ETUFJTCAtZiA8bW1fc2VuZGVyPiA8bW1fcmVjaXBpZW50cz4iDQorICAg IGVsc2UNCisJU0VORE1BSUw9DQorICAgIGZpDQorZmkNCitlY2hvICIkYWNf dCIiJFNFTkRNQUlMIiAxPiY2DQorcm0gLWYgY29uZnRlc3Qub3V0IGNvbmZ0 ZXN0LnB5DQogDQogIyBmaWd1cmUgb3V0IHRoZSBERUZBVUxUX0hPU1RfTkFN RSBhbmQgREVGQVVMVF9VUkwNCiANCkBAIC0xMjg3LDE0ICsxMzQxLDE0IEBA DQogJFBZVEhPTiBjb25mdGVzdC5weQ0KIA0KIGVjaG8gJGFjX24gImNoZWNr aW5nIGZvciBkZWZhdWx0IGZ1bGx5IHF1YWxpZmllZCBob3N0IG5hbWUiIi4u LiAkYWNfYyIgMT4mNg0KLWVjaG8gImNvbmZpZ3VyZToxMjkxOiBjaGVja2lu ZyBmb3IgZGVmYXVsdCBmdWxseSBxdWFsaWZpZWQgaG9zdCBuYW1lIiA+JjUN CitlY2hvICJjb25maWd1cmU6MTM0NTogY2hlY2tpbmcgZm9yIGRlZmF1bHQg ZnVsbHkgcXVhbGlmaWVkIGhvc3QgbmFtZSIgPiY1DQogaWYgdGVzdCAteiAi JEZRRE4iDQogdGhlbg0KICAgICBGUUROPWBoZWFkIC0xIGNvbmZ0ZXN0Lm91 dGANCiBmaQ0KIGVjaG8gIiRhY190IiIkRlFETiIgMT4mNg0KIGVjaG8gJGFj X24gImNoZWNraW5nIGZvciBkZWZhdWx0IFVSTCBob3N0IGNvbXBvbmVudCIi Li4uICRhY19jIiAxPiY2DQotZWNobyAiY29uZmlndXJlOjEyOTg6IGNoZWNr aW5nIGZvciBkZWZhdWx0IFVSTCBob3N0IGNvbXBvbmVudCIgPiY1DQorZWNo byAiY29uZmlndXJlOjEzNTI6IGNoZWNraW5nIGZvciBkZWZhdWx0IFVSTCBo b3N0IGNvbXBvbmVudCIgPiY1DQogaWYgdGVzdCAteiAiJFVSTCINCiB0aGVu DQogICAgIFVSTD1gdGFpbCAtMSBjb25mdGVzdC5vdXRgDQpAQCAtMTMwNiwx MiArMTM2MCwxMiBAQA0KIGZvciBhY19mdW5jIGluIHN0cmVycm9yDQogZG8N CiBlY2hvICRhY19uICJjaGVja2luZyBmb3IgJGFjX2Z1bmMiIi4uLiAkYWNf YyIgMT4mNg0KLWVjaG8gImNvbmZpZ3VyZToxMzEwOiBjaGVja2luZyBmb3Ig JGFjX2Z1bmMiID4mNQ0KK2VjaG8gImNvbmZpZ3VyZToxMzY0OiBjaGVja2lu ZyBmb3IgJGFjX2Z1bmMiID4mNQ0KIGlmIGV2YWwgInRlc3QgXCJgZWNobyAn JCcneydhY19jdl9mdW5jXyRhY19mdW5jJytzZXR9J2BcIiA9IHNldCI7IHRo ZW4NCiAgIGVjaG8gJGFjX24gIihjYWNoZWQpICRhY19jIiAxPiY2DQogZWxz ZQ0KICAgY2F0ID4gY29uZnRlc3QuJGFjX2V4dCA8PEVPRg0KLSNsaW5lIDEz MTUgImNvbmZpZ3VyZSINCisjbGluZSAxMzY5ICJjb25maWd1cmUiDQogI2lu Y2x1ZGUgImNvbmZkZWZzLmgiDQogLyogU3lzdGVtIGhlYWRlciB0byBkZWZp bmUgX19zdHViIG1hY3JvcyBhbmQgaG9wZWZ1bGx5IGZldyBwcm90b3R5cGVz LA0KICAgICB3aGljaCBjYW4gY29uZmxpY3Qgd2l0aCBjaGFyICRhY19mdW5j KCk7IGJlbG93LiAgKi8NCkBAIC0xMzM0LDcgKzEzODgsNyBAQA0KIA0KIDsg cmV0dXJuIDA7IH0NCiBFT0YNCi1pZiB7IChldmFsIGVjaG8gY29uZmlndXJl OjEzMzg6IFwiJGFjX2xpbmtcIikgMT4mNTsgKGV2YWwgJGFjX2xpbmspIDI+ JjU7IH0gJiYgdGVzdCAtcyBjb25mdGVzdDsgdGhlbg0KK2lmIHsgKGV2YWwg ZWNobyBjb25maWd1cmU6MTM5MjogXCIkYWNfbGlua1wiKSAxPiY1OyAoZXZh bCAkYWNfbGluaykgMj4mNTsgfSAmJiB0ZXN0IC1zIGNvbmZ0ZXN0OyB0aGVu DQogICBybSAtcmYgY29uZnRlc3QqDQogICBldmFsICJhY19jdl9mdW5jXyRh Y19mdW5jPXllcyINCiBlbHNlDQpAQCAtMTM2MSw3ICsxNDE1LDcgQEANCiAN CiAjIENoZWNrcyBmb3IgaGVhZGVyIGZpbGVzLg0KIGVjaG8gJGFjX24gImNo ZWNraW5nIGhvdyB0byBydW4gdGhlIEMgcHJlcHJvY2Vzc29yIiIuLi4gJGFj X2MiIDE+JjYNCi1lY2hvICJjb25maWd1cmU6MTM2NTogY2hlY2tpbmcgaG93 IHRvIHJ1biB0aGUgQyBwcmVwcm9jZXNzb3IiID4mNQ0KK2VjaG8gImNvbmZp Z3VyZToxNDE5OiBjaGVja2luZyBob3cgdG8gcnVuIHRoZSBDIHByZXByb2Nl c3NvciIgPiY1DQogIyBPbiBTdW5zLCBzb21ldGltZXMgJENQUCBuYW1lcyBh IGRpcmVjdG9yeS4NCiBpZiB0ZXN0IC1uICIkQ1BQIiAmJiB0ZXN0IC1kICIk Q1BQIjsgdGhlbg0KICAgQ1BQPQ0KQEAgLTEzNzYsMTMgKzE0MzAsMTMgQEAN CiAgICMgT24gdGhlIE5lWFQsIGNjIC1FIHJ1bnMgdGhlIGNvZGUgdGhyb3Vn aCB0aGUgY29tcGlsZXIncyBwYXJzZXIsDQogICAjIG5vdCBqdXN0IHRocm91 Z2ggY3BwLg0KICAgY2F0ID4gY29uZnRlc3QuJGFjX2V4dCA8PEVPRg0KLSNs aW5lIDEzODAgImNvbmZpZ3VyZSINCisjbGluZSAxNDM0ICJjb25maWd1cmUi DQogI2luY2x1ZGUgImNvbmZkZWZzLmgiDQogI2luY2x1ZGUgPGFzc2VydC5o Pg0KIFN5bnRheCBFcnJvcg0KIEVPRg0KIGFjX3RyeT0iJGFjX2NwcCBjb25m dGVzdC4kYWNfZXh0ID4vZGV2L251bGwgMj5jb25mdGVzdC5vdXQiDQoteyAo ZXZhbCBlY2hvIGNvbmZpZ3VyZToxMzg2OiBcIiRhY190cnlcIikgMT4mNTsg KGV2YWwgJGFjX3RyeSkgMj4mNTsgfQ0KK3sgKGV2YWwgZWNobyBjb25maWd1 cmU6MTQ0MDogXCIkYWNfdHJ5XCIpIDE+JjU7IChldmFsICRhY190cnkpIDI+ JjU7IH0NCiBhY19lcnI9YGdyZXAgLXYgJ14gKisnIGNvbmZ0ZXN0Lm91dGAN CiBpZiB0ZXN0IC16ICIkYWNfZXJyIjsgdGhlbg0KICAgOg0KQEAgLTEzOTMs MTMgKzE0NDcsMTMgQEANCiAgIHJtIC1yZiBjb25mdGVzdCoNCiAgIENQUD0i JHtDQy1jY30gLUUgLXRyYWRpdGlvbmFsLWNwcCINCiAgIGNhdCA+IGNvbmZ0 ZXN0LiRhY19leHQgPDxFT0YNCi0jbGluZSAxMzk3ICJjb25maWd1cmUiDQor I2xpbmUgMTQ1MSAiY29uZmlndXJlIg0KICNpbmNsdWRlICJjb25mZGVmcy5o Ig0KICNpbmNsdWRlIDxhc3NlcnQuaD4NCiBTeW50YXggRXJyb3INCiBFT0YN CiBhY190cnk9IiRhY19jcHAgY29uZnRlc3QuJGFjX2V4dCA+L2Rldi9udWxs IDI+Y29uZnRlc3Qub3V0Ig0KLXsgKGV2YWwgZWNobyBjb25maWd1cmU6MTQw MzogXCIkYWNfdHJ5XCIpIDE+JjU7IChldmFsICRhY190cnkpIDI+JjU7IH0N Cit7IChldmFsIGVjaG8gY29uZmlndXJlOjE0NTc6IFwiJGFjX3RyeVwiKSAx PiY1OyAoZXZhbCAkYWNfdHJ5KSAyPiY1OyB9DQogYWNfZXJyPWBncmVwIC12 ICdeICorJyBjb25mdGVzdC5vdXRgDQogaWYgdGVzdCAteiAiJGFjX2VyciI7 IHRoZW4NCiAgIDoNCkBAIC0xNDIyLDEyICsxNDc2LDEyIEBADQogZWNobyAi JGFjX3QiIiRDUFAiIDE+JjYNCiANCiBlY2hvICRhY19uICJjaGVja2luZyBm b3IgQU5TSSBDIGhlYWRlciBmaWxlcyIiLi4uICRhY19jIiAxPiY2DQotZWNo byAiY29uZmlndXJlOjE0MjY6IGNoZWNraW5nIGZvciBBTlNJIEMgaGVhZGVy IGZpbGVzIiA+JjUNCitlY2hvICJjb25maWd1cmU6MTQ4MDogY2hlY2tpbmcg Zm9yIEFOU0kgQyBoZWFkZXIgZmlsZXMiID4mNQ0KIGlmIGV2YWwgInRlc3Qg XCJgZWNobyAnJCcneydhY19jdl9oZWFkZXJfc3RkYycrc2V0fSdgXCIgPSBz ZXQiOyB0aGVuDQogICBlY2hvICRhY19uICIoY2FjaGVkKSAkYWNfYyIgMT4m Ng0KIGVsc2UNCiAgIGNhdCA+IGNvbmZ0ZXN0LiRhY19leHQgPDxFT0YNCi0j bGluZSAxNDMxICJjb25maWd1cmUiDQorI2xpbmUgMTQ4NSAiY29uZmlndXJl Ig0KICNpbmNsdWRlICJjb25mZGVmcy5oIg0KICNpbmNsdWRlIDxzdGRsaWIu aD4NCiAjaW5jbHVkZSA8c3RkYXJnLmg+DQpAQCAtMTQzNSw3ICsxNDg5LDcg QEANCiAjaW5jbHVkZSA8ZmxvYXQuaD4NCiBFT0YNCiBhY190cnk9IiRhY19j cHAgY29uZnRlc3QuJGFjX2V4dCA+L2Rldi9udWxsIDI+Y29uZnRlc3Qub3V0 Ig0KLXsgKGV2YWwgZWNobyBjb25maWd1cmU6MTQzOTogXCIkYWNfdHJ5XCIp IDE+JjU7IChldmFsICRhY190cnkpIDI+JjU7IH0NCit7IChldmFsIGVjaG8g Y29uZmlndXJlOjE0OTM6IFwiJGFjX3RyeVwiKSAxPiY1OyAoZXZhbCAkYWNf dHJ5KSAyPiY1OyB9DQogYWNfZXJyPWBncmVwIC12ICdeICorJyBjb25mdGVz dC5vdXRgDQogaWYgdGVzdCAteiAiJGFjX2VyciI7IHRoZW4NCiAgIHJtIC1y ZiBjb25mdGVzdCoNCkBAIC0xNDUyLDcgKzE1MDYsNyBAQA0KIGlmIHRlc3Qg JGFjX2N2X2hlYWRlcl9zdGRjID0geWVzOyB0aGVuDQogICAjIFN1bk9TIDQu eCBzdHJpbmcuaCBkb2VzIG5vdCBkZWNsYXJlIG1lbSosIGNvbnRyYXJ5IHRv IEFOU0kuDQogY2F0ID4gY29uZnRlc3QuJGFjX2V4dCA8PEVPRg0KLSNsaW5l IDE0NTYgImNvbmZpZ3VyZSINCisjbGluZSAxNTEwICJjb25maWd1cmUiDQog I2luY2x1ZGUgImNvbmZkZWZzLmgiDQogI2luY2x1ZGUgPHN0cmluZy5oPg0K IEVPRg0KQEAgLTE0NzAsNyArMTUyNCw3IEBADQogaWYgdGVzdCAkYWNfY3Zf aGVhZGVyX3N0ZGMgPSB5ZXM7IHRoZW4NCiAgICMgSVNDIDIuMC4yIHN0ZGxp Yi5oIGRvZXMgbm90IGRlY2xhcmUgZnJlZSwgY29udHJhcnkgdG8gQU5TSS4N CiBjYXQgPiBjb25mdGVzdC4kYWNfZXh0IDw8RU9GDQotI2xpbmUgMTQ3NCAi Y29uZmlndXJlIg0KKyNsaW5lIDE1MjggImNvbmZpZ3VyZSINCiAjaW5jbHVk ZSAiY29uZmRlZnMuaCINCiAjaW5jbHVkZSA8c3RkbGliLmg+DQogRU9GDQpA QCAtMTQ5MSw3ICsxNTQ1LDcgQEANCiAgIDoNCiBlbHNlDQogICBjYXQgPiBj b25mdGVzdC4kYWNfZXh0IDw8RU9GDQotI2xpbmUgMTQ5NSAiY29uZmlndXJl Ig0KKyNsaW5lIDE1NDkgImNvbmZpZ3VyZSINCiAjaW5jbHVkZSAiY29uZmRl ZnMuaCINCiAjaW5jbHVkZSA8Y3R5cGUuaD4NCiAjZGVmaW5lIElTTE9XRVIo YykgKCdhJyA8PSAoYykgJiYgKGMpIDw9ICd6JykNCkBAIC0xNTAyLDcgKzE1 NTYsNyBAQA0KIGV4aXQgKDApOyB9DQogDQogRU9GDQotaWYgeyAoZXZhbCBl Y2hvIGNvbmZpZ3VyZToxNTA2OiBcIiRhY19saW5rXCIpIDE+JjU7IChldmFs ICRhY19saW5rKSAyPiY1OyB9ICYmIHRlc3QgLXMgY29uZnRlc3QgJiYgKC4v Y29uZnRlc3Q7IGV4aXQpIDI+L2Rldi9udWxsDQoraWYgeyAoZXZhbCBlY2hv IGNvbmZpZ3VyZToxNTYwOiBcIiRhY19saW5rXCIpIDE+JjU7IChldmFsICRh Y19saW5rKSAyPiY1OyB9ICYmIHRlc3QgLXMgY29uZnRlc3QgJiYgKC4vY29u ZnRlc3Q7IGV4aXQpIDI+L2Rldi9udWxsDQogdGhlbg0KICAgOg0KIGVsc2UN CkBAIC0xNTI5LDE3ICsxNTgzLDE3IEBADQogZG8NCiBhY19zYWZlPWBlY2hv ICIkYWNfaGRyIiB8IHNlZCAneSUuLystJV9fcF8lJ2ANCiBlY2hvICRhY19u ICJjaGVja2luZyBmb3IgJGFjX2hkciIiLi4uICRhY19jIiAxPiY2DQotZWNo byAiY29uZmlndXJlOjE1MzM6IGNoZWNraW5nIGZvciAkYWNfaGRyIiA+JjUN CitlY2hvICJjb25maWd1cmU6MTU4NzogY2hlY2tpbmcgZm9yICRhY19oZHIi ID4mNQ0KIGlmIGV2YWwgInRlc3QgXCJgZWNobyAnJCcneydhY19jdl9oZWFk ZXJfJGFjX3NhZmUnK3NldH0nYFwiID0gc2V0IjsgdGhlbg0KICAgZWNobyAk YWNfbiAiKGNhY2hlZCkgJGFjX2MiIDE+JjYNCiBlbHNlDQogICBjYXQgPiBj b25mdGVzdC4kYWNfZXh0IDw8RU9GDQotI2xpbmUgMTUzOCAiY29uZmlndXJl Ig0KKyNsaW5lIDE1OTIgImNvbmZpZ3VyZSINCiAjaW5jbHVkZSAiY29uZmRl ZnMuaCINCiAjaW5jbHVkZSA8JGFjX2hkcj4NCiBFT0YNCiBhY190cnk9IiRh Y19jcHAgY29uZnRlc3QuJGFjX2V4dCA+L2Rldi9udWxsIDI+Y29uZnRlc3Qu b3V0Ig0KLXsgKGV2YWwgZWNobyBjb25maWd1cmU6MTU0MzogXCIkYWNfdHJ5 XCIpIDE+JjU7IChldmFsICRhY190cnkpIDI+JjU7IH0NCit7IChldmFsIGVj aG8gY29uZmlndXJlOjE1OTc6IFwiJGFjX3RyeVwiKSAxPiY1OyAoZXZhbCAk YWNfdHJ5KSAyPiY1OyB9DQogYWNfZXJyPWBncmVwIC12ICdeICorJyBjb25m dGVzdC5vdXRgDQogaWYgdGVzdCAteiAiJGFjX2VyciI7IHRoZW4NCiAgIHJt IC1yZiBjb25mdGVzdCoNCkBAIC0xNTY4LDEyICsxNjIyLDEyIEBADQogDQog IyBDaGVja3MgZm9yIHR5cGVkZWZzLCBzdHJ1Y3R1cmVzLCBhbmQgY29tcGls ZXIgY2hhcmFjdGVyaXN0aWNzLg0KIGVjaG8gJGFjX24gImNoZWNraW5nIGZv ciB1aWRfdCBpbiBzeXMvdHlwZXMuaCIiLi4uICRhY19jIiAxPiY2DQotZWNo byAiY29uZmlndXJlOjE1NzI6IGNoZWNraW5nIGZvciB1aWRfdCBpbiBzeXMv dHlwZXMuaCIgPiY1DQorZWNobyAiY29uZmlndXJlOjE2MjY6IGNoZWNraW5n IGZvciB1aWRfdCBpbiBzeXMvdHlwZXMuaCIgPiY1DQogaWYgZXZhbCAidGVz dCBcImBlY2hvICckJyd7J2FjX2N2X3R5cGVfdWlkX3QnK3NldH0nYFwiID0g c2V0IjsgdGhlbg0KICAgZWNobyAkYWNfbiAiKGNhY2hlZCkgJGFjX2MiIDE+ JjYNCiBlbHNlDQogICBjYXQgPiBjb25mdGVzdC4kYWNfZXh0IDw8RU9GDQot I2xpbmUgMTU3NyAiY29uZmlndXJlIg0KKyNsaW5lIDE2MzEgImNvbmZpZ3Vy ZSINCiAjaW5jbHVkZSAiY29uZmRlZnMuaCINCiAjaW5jbHVkZSA8c3lzL3R5 cGVzLmg+DQogRU9GDQpAQCAtMTYwMiw3ICsxNjU2LDcgQEANCiBmaQ0KIA0K IGVjaG8gJGFjX24gImNoZWNraW5nIHR5cGUgb2YgYXJyYXkgYXJndW1lbnQg dG8gZ2V0Z3JvdXBzIiIuLi4gJGFjX2MiIDE+JjYNCi1lY2hvICJjb25maWd1 cmU6MTYwNjogY2hlY2tpbmcgdHlwZSBvZiBhcnJheSBhcmd1bWVudCB0byBn ZXRncm91cHMiID4mNQ0KK2VjaG8gImNvbmZpZ3VyZToxNjYwOiBjaGVja2lu ZyB0eXBlIG9mIGFycmF5IGFyZ3VtZW50IHRvIGdldGdyb3VwcyIgPiY1DQog aWYgZXZhbCAidGVzdCBcImBlY2hvICckJyd7J2FjX2N2X3R5cGVfZ2V0Z3Jv dXBzJytzZXR9J2BcIiA9IHNldCI7IHRoZW4NCiAgIGVjaG8gJGFjX24gIihj YWNoZWQpICRhY19jIiAxPiY2DQogZWxzZQ0KQEAgLTE2MTAsNyArMTY2NCw3 IEBADQogICBhY19jdl90eXBlX2dldGdyb3Vwcz1jcm9zcw0KIGVsc2UNCiAg IGNhdCA+IGNvbmZ0ZXN0LiRhY19leHQgPDxFT0YNCi0jbGluZSAxNjE0ICJj b25maWd1cmUiDQorI2xpbmUgMTY2OCAiY29uZmlndXJlIg0KICNpbmNsdWRl ICJjb25mZGVmcy5oIg0KIA0KIC8qIFRoYW5rcyB0byBNaWtlIFJlbmRlbGwg Zm9yIHRoaXMgdGVzdC4gICovDQpAQCAtMTYzNSw3ICsxNjg5LDcgQEANCiB9 DQogDQogRU9GDQotaWYgeyAoZXZhbCBlY2hvIGNvbmZpZ3VyZToxNjM5OiBc IiRhY19saW5rXCIpIDE+JjU7IChldmFsICRhY19saW5rKSAyPiY1OyB9ICYm IHRlc3QgLXMgY29uZnRlc3QgJiYgKC4vY29uZnRlc3Q7IGV4aXQpIDI+L2Rl di9udWxsDQoraWYgeyAoZXZhbCBlY2hvIGNvbmZpZ3VyZToxNjkzOiBcIiRh Y19saW5rXCIpIDE+JjU7IChldmFsICRhY19saW5rKSAyPiY1OyB9ICYmIHRl c3QgLXMgY29uZnRlc3QgJiYgKC4vY29uZnRlc3Q7IGV4aXQpIDI+L2Rldi9u dWxsDQogdGhlbg0KICAgICBhY19jdl90eXBlX2dldGdyb3Vwcz1naWRfdA0K IGVsc2UNCkBAIC0xNjQ5LDcgKzE3MDMsNyBAQA0KIA0KIGlmIHRlc3QgJGFj X2N2X3R5cGVfZ2V0Z3JvdXBzID0gY3Jvc3M7IHRoZW4NCiAgICAgICAgIGNh dCA+IGNvbmZ0ZXN0LiRhY19leHQgPDxFT0YNCi0jbGluZSAxNjUzICJjb25m aWd1cmUiDQorI2xpbmUgMTcwNyAiY29uZmlndXJlIg0KICNpbmNsdWRlICJj b25mZGVmcy5oIg0KICNpbmNsdWRlIDx1bmlzdGQuaD4NCiBFT0YNCkBAIC0x Njc1LDEyICsxNzI5LDEyIEBADQogDQogIyBDaGVja3MgZm9yIGxpYnJhcnkg ZnVuY3Rpb25zLg0KIGVjaG8gJGFjX24gImNoZWNraW5nIGZvciB2cHJpbnRm IiIuLi4gJGFjX2MiIDE+JjYNCi1lY2hvICJjb25maWd1cmU6MTY3OTogY2hl Y2tpbmcgZm9yIHZwcmludGYiID4mNQ0KK2VjaG8gImNvbmZpZ3VyZToxNzMz OiBjaGVja2luZyBmb3IgdnByaW50ZiIgPiY1DQogaWYgZXZhbCAidGVzdCBc ImBlY2hvICckJyd7J2FjX2N2X2Z1bmNfdnByaW50Zicrc2V0fSdgXCIgPSBz ZXQiOyB0aGVuDQogICBlY2hvICRhY19uICIoY2FjaGVkKSAkYWNfYyIgMT4m Ng0KIGVsc2UNCiAgIGNhdCA+IGNvbmZ0ZXN0LiRhY19leHQgPDxFT0YNCi0j bGluZSAxNjg0ICJjb25maWd1cmUiDQorI2xpbmUgMTczOCAiY29uZmlndXJl Ig0KICNpbmNsdWRlICJjb25mZGVmcy5oIg0KIC8qIFN5c3RlbSBoZWFkZXIg dG8gZGVmaW5lIF9fc3R1YiBtYWNyb3MgYW5kIGhvcGVmdWxseSBmZXcgcHJv dG90eXBlcywNCiAgICAgd2hpY2ggY2FuIGNvbmZsaWN0IHdpdGggY2hhciB2 cHJpbnRmKCk7IGJlbG93LiAgKi8NCkBAIC0xNzAzLDcgKzE3NTcsNyBAQA0K IA0KIDsgcmV0dXJuIDA7IH0NCiBFT0YNCi1pZiB7IChldmFsIGVjaG8gY29u ZmlndXJlOjE3MDc6IFwiJGFjX2xpbmtcIikgMT4mNTsgKGV2YWwgJGFjX2xp bmspIDI+JjU7IH0gJiYgdGVzdCAtcyBjb25mdGVzdDsgdGhlbg0KK2lmIHsg KGV2YWwgZWNobyBjb25maWd1cmU6MTc2MTogXCIkYWNfbGlua1wiKSAxPiY1 OyAoZXZhbCAkYWNfbGluaykgMj4mNTsgfSAmJiB0ZXN0IC1zIGNvbmZ0ZXN0 OyB0aGVuDQogICBybSAtcmYgY29uZnRlc3QqDQogICBldmFsICJhY19jdl9m dW5jX3ZwcmludGY9eWVzIg0KIGVsc2UNCkBAIC0xNzI3LDEyICsxNzgxLDEy IEBADQogDQogaWYgdGVzdCAiJGFjX2N2X2Z1bmNfdnByaW50ZiIgIT0geWVz OyB0aGVuDQogZWNobyAkYWNfbiAiY2hlY2tpbmcgZm9yIF9kb3BybnQiIi4u LiAkYWNfYyIgMT4mNg0KLWVjaG8gImNvbmZpZ3VyZToxNzMxOiBjaGVja2lu ZyBmb3IgX2RvcHJudCIgPiY1DQorZWNobyAiY29uZmlndXJlOjE3ODU6IGNo ZWNraW5nIGZvciBfZG9wcm50IiA+JjUNCiBpZiBldmFsICJ0ZXN0IFwiYGVj aG8gJyQnJ3snYWNfY3ZfZnVuY19fZG9wcm50JytzZXR9J2BcIiA9IHNldCI7 IHRoZW4NCiAgIGVjaG8gJGFjX24gIihjYWNoZWQpICRhY19jIiAxPiY2DQog ZWxzZQ0KICAgY2F0ID4gY29uZnRlc3QuJGFjX2V4dCA8PEVPRg0KLSNsaW5l IDE3MzYgImNvbmZpZ3VyZSINCisjbGluZSAxNzkwICJjb25maWd1cmUiDQog I2luY2x1ZGUgImNvbmZkZWZzLmgiDQogLyogU3lzdGVtIGhlYWRlciB0byBk ZWZpbmUgX19zdHViIG1hY3JvcyBhbmQgaG9wZWZ1bGx5IGZldyBwcm90b3R5 cGVzLA0KICAgICB3aGljaCBjYW4gY29uZmxpY3Qgd2l0aCBjaGFyIF9kb3By bnQoKTsgYmVsb3cuICAqLw0KQEAgLTE3NTUsNyArMTgwOSw3IEBADQogDQog OyByZXR1cm4gMDsgfQ0KIEVPRg0KLWlmIHsgKGV2YWwgZWNobyBjb25maWd1 cmU6MTc1OTogXCIkYWNfbGlua1wiKSAxPiY1OyAoZXZhbCAkYWNfbGluaykg Mj4mNTsgfSAmJiB0ZXN0IC1zIGNvbmZ0ZXN0OyB0aGVuDQoraWYgeyAoZXZh bCBlY2hvIGNvbmZpZ3VyZToxODEzOiBcIiRhY19saW5rXCIpIDE+JjU7IChl dmFsICRhY19saW5rKSAyPiY1OyB9ICYmIHRlc3QgLXMgY29uZnRlc3Q7IHRo ZW4NCiAgIHJtIC1yZiBjb25mdGVzdCoNCiAgIGV2YWwgImFjX2N2X2Z1bmNf X2RvcHJudD15ZXMiDQogZWxzZQ0KQEAgLTE5NDIsNiArMTk5Niw3IEBADQog cyVATUFJTF9HSURAJSRNQUlMX0dJRCVnDQogcyVAQ0dJX0dJREAlJENHSV9H SUQlZw0KIHMlQENHSUVYVEAlJENHSUVYVCVnDQorcyVAU0VORE1BSUxAJSRT RU5ETUFJTCVnDQogcyVARlFETkAlJEZRRE4lZw0KIHMlQFVSTEAlJFVSTCVn DQogcyVAQ1BQQCUkQ1BQJWcNCmRpZmYgLXJ1TiBtYWlsbWFuLTItY2dpZXh0 L2NvbmZpZ3VyZS5pbiBtYWlsbWFuL2NvbmZpZ3VyZS5pbg0KLS0tIG1haWxt YW4tMi1jZ2lleHQvY29uZmlndXJlLmluCUZyaSBKYW4gIDggMDk6MzA6MjIg MTk5OQ0KKysrIG1haWxtYW4vY29uZmlndXJlLmluCUZyaSBKYW4gIDggMDk6 NDU6MjMgMTk5OQ0KQEAgLTI1OCw3ICsyNTgsNyBAQA0KIGlmIHRlc3QgLXog IiR3aXRoX21haWxfZ2lkIg0KIHRoZW4NCiAgICAgQUNfQ0FDSEVfVkFMKGFj X2N2X2dyb3VwX21haWwsIFtkbmwNCi0gICAgYWNfY3ZfZ3JvdXBfbWFpbD0i b3RoZXIgbWFpbCBkYWVtb24iXSkNCisgICAgYWNfY3ZfZ3JvdXBfbWFpbD0i bm9maWxlcyBvdGhlciBtYWlsIGRhZW1vbiJdKQ0KIGVsc2UNCiAgICAgYWNf Y3ZfZ3JvdXBfbWFpbD0kd2l0aF9tYWlsX2dpZA0KIGZpDQpAQCAtMjk3LDEy ICsyOTcsMTQgQEANCiAqKioqKiBkb2N1bWVudGF0aW9uLCBhbmQgdGhlIElO U1RBTEwgZmlsZSBmb3IgZGV0YWlsc10pDQogZmkNCiANCisjTU1fRklORF9V U0VSX0lEKEFMSUFTX1VJRCwgbWFpbG1hbiwgYWxpYXNfd3JhcHBlcikNCisj TU1fRklORF9HUk9VUF9JRChBTElBU19HSUQsIG1haWwsIGFsaWFzX3dyYXBw ZXIpDQogDQogIyBDR0kgZXh0ZW5zaW9uIGNoZWNraW5nDQogQUNfU1VCU1Qo Q0dJRVhUKQ0KIEFDX01TR19DSEVDS0lORyhmb3IgQ0dJIGV4dGVuc2lvbikN CiBBQ19BUkdfV0lUSChjZ2ktZXh0LCBbDQotICAgICAgIC0td2l0aC1jZ2kt ZXh0ICAgICAgICBzcGVjaWZ5IGV4dGVuc2lvbnMgb2YgQ0dJIHByb2dyYW1z XSkNCisJLS13aXRoLWNnaS1leHQgICAgICAgIHNwZWNpZnkgZXh0ZW5zaW9u cyBvZiBDR0kgcHJvZ3JhbXNdKQ0KIGlmIHRlc3QgLXogIiR3aXRoX2NnaV9l eHQiDQogdGhlbg0KICAgICBDR0lFWFQ9JycNCkBAIC0zMTIsOCArMzE0LDQ4 IEBADQogZmkNCiBBQ19NU0dfUkVTVUxUKCR3aXRoX2NnaV9leHQpDQogDQot I01NX0ZJTkRfVVNFUl9JRChBTElBU19VSUQsIG1haWxtYW4sIGFsaWFzX3dy YXBwZXIpDQotI01NX0ZJTkRfR1JPVVBfSUQoQUxJQVNfR0lELCBtYWlsLCBh bGlhc193cmFwcGVyKQ0KK0FDX01TR19DSEVDS0lORyhmb3Igc2VuZG1haWwg cHJvZ3JhbXMpDQorQUNfQVJHX1dJVEgoc2VuZG1haWwsIFsNCisJLS13aXRo LXNlbmRtYWlsICAgICAgZG8gZGVsaXZlcmllcyB3aXRoIHRoaXMgcHJvZ3Jh bV0pDQoraWYgdGVzdCAteiAiJHdpdGhfc2VuZG1haWwiDQordGhlbg0KKyAg ICBBQ19DQUNIRV9WQUwoYWNfY3Zfc2VuZG1haWwsIFtkbmwNCisJYWNfY3Zf c2VuZG1haWw9Ii92YXIvcW1haWwvYmluL3FtYWlsLWluamVjdCAvdXNyL2xp Yi9zZW5kbWFpbCAvdXNyL3NiaW4vc2VuZG1haWwgL2V0Yy9zZW5kbWFpbCJd KQ0KK2Vsc2UNCisgICAgYWNfY3Zfc2VuZG1haWw9JHdpdGhfc2VuZG1haWwN CitmaQ0KK0FDX1NVQlNUKFNFTkRNQUlMKQ0KK2NoYW5nZXF1b3RlKCwpDQor Y2F0ID4gY29uZnRlc3QucHkgPDxFT0YNCitpbXBvcnQgb3MsIHN0cmluZw0K K2ZpbCA9ICcnDQorZm9yIGZsZSBpbiBzdHJpbmcuc3BsaXQoIiRhY19jdl9z ZW5kbWFpbCIpOg0KKyAgICB0cnk6DQorCWwgPSBvcy5zdGF0KGZsZSkNCisJ aWYgbFswXSAmIDB4MTExOg0KKwkgICAgZmlsID0gZmxlDQorCSAgICBicmVh aw0KKyAgICBleGNlcHQ6DQorCXBhc3MNCitmcCA9IG9wZW4oJ2NvbmZ0ZXN0 Lm91dCcsICd3JykNCitmcC53cml0ZSgnJXNcbicgJSBmaWwpDQorZnAuY2xv c2UNCitFT0YNCitjaGFuZ2VxdW90ZShbLCBdKQ0KKyRQWVRIT04gY29uZnRl c3QucHkNCitTRU5ETUFJTD1gY2F0IGNvbmZ0ZXN0Lm91dGANCisjIFBhcmFt ZXRlcnMgYXJlIHRoZSBzYW1lIGZvciBxbWFpbC1pbmplY3QgYW5kIHNlbmRt YWlsLWNsb25lcyBidXQgd2hvIGtub3dzPw0KK2lmIHRlc3QgISAteiAkU0VO RE1BSUw7IHRoZW4NCisgICAgaWYgdGVzdCAke1NFTkRNQUlMJSVxbWFpbC1p bmplY3R9ICE9ICRTRU5ETUFJTDsgdGhlbg0KKwlTRU5ETUFJTD0iJFNFTkRN QUlMIC1mIDxtbV9zZW5kZXI+IDxtbV9yZWNpcGllbnRzPiINCisgICAgZWxp ZiB0ZXN0ICR7U0VORE1BSUwlJXNlbmRtYWlsfSAhPSAkU0VORE1BSUw7IHRo ZW4NCisJU0VORE1BSUw9IiRTRU5ETUFJTCAtZiA8bW1fc2VuZGVyPiA8bW1f cmVjaXBpZW50cz4iDQorICAgIGVsc2UNCisJU0VORE1BSUw9DQorICAgIGZp DQorZmkNCitBQ19NU0dfUkVTVUxUKCRTRU5ETUFJTCkNCitybSAtZiBjb25m dGVzdC5vdXQgY29uZnRlc3QucHkNCiANCiAjIGZpZ3VyZSBvdXQgdGhlIERF RkFVTFRfSE9TVF9OQU1FIGFuZCBERUZBVUxUX1VSTA0KIEFDX1NVQlNUKEZR RE4pDQo= ---456965764-233999344-915788868=:3512-- From droege@uni-koblenz.de Fri Jan 8 11:46:46 1999 From: droege@uni-koblenz.de (Detlev Droege) Date: Fri, 8 Jan 99 12:46:46 +0100 Subject: [Mailman-Developers] Mailman 1.0b7 bug reports Message-ID: <199901081146.MAA19567@mailhost.uni-koblenz.de> Hi Mailman Developers, thanks for Mailman - its great to have that tool ! We did set up Mailman at http://mailhost.uni-koblenz.de/mailman/admin/ mostly to admin local user groups. I'm the list-admin of the single non-local group (EINST-Mitglieder). Most things run just fine, however I had following problems: 1 - I did a bulk subscribe for approx. 100 members via the HTML interface. I overlooked a bogus line when pasting the addresses into the textfield and Mailman generated a strange entry. A syntax check on the mail addresses would be helpful. [The bogus address had a pending closing paranthesis: "AUser@somewhere.com)" ] 2 - The abovementioned list of email addresses did contain mixed-case entries like "Detlev.Droege@uni-koblenz.de". Mailman did lowercase them in most places, but not in all places. The subscription welcome message to those members contained URLs like http://host/mailman/options/einst-mitglieder/Detlev.Droege@uni-koblenz.de to access the specific member record (note the upper case letters). The "options" program does not recognize these entries unles all letters are changed to lower case. Either the case in the generated mail should be changed or, even better, "options" should accept valid mail addresses in any case. 3 - When the first external member submitted an article, its From: address differed from the subscribed address, so I as the list admin was asked to approve the message. I did so, however the message was never sent out to the list members. It appears in the "post" logfile, it is archived in the HTML archive, but it was never mailed to the list members. Our postmaster could not detect any failure of our mail system nor any error messages. Is it possible Mailman just forgot to send it out ? 4 - As list admin I'd like to have an interface to change the mail address of list members. I allready got several requests to do so. It's a little boring to do so by unsubscribing the old and then subscribing the new address. Moreover, this generates a useles "Good Bye" and "Welcome" message which might confuse the subscriber. Anyway - Mailman is a great tool and I like it a lot ! Don't take this as complaint, but as my (very) small effort to make it even better. Detlev --- Detlev Droege, Uni Koblenz, FB Informatik, Rheinau 1, D-56075 Koblenz, Germany Fon: +49 261 287-2769 (NEU !) | Email: droege@informatik Fax: +49 261 287-2745 (NEU !) | .uni-koblenz.de From julian7@kva.hu Fri Jan 8 17:31:45 1999 From: julian7@kva.hu (Balazs Nagy) Date: Fri, 8 Jan 1999 18:31:45 +0100 (CET) Subject: [Mailman-Developers] Admindb bug Message-ID: Hiyas, There's an error in admindb in the login form. Here's the fast patch against the latest CVS snapshots: --- admindb.py.orig Fri Jan 8 18:23:22 1999 +++ admindb.py Fri Jan 8 18:23:44 1999 @@ -113,7 +113,7 @@ 'admlogin.txt', {'listname': list_name, 'path' : os.environ.get('REQUEST_URI', - '/mailman/admin/' + list_name), + '/mailman/admindb/' + list_name), 'message' : message, }) print text ... and of course against my patches: --- admindb.py.orig Fri Jan 8 18:20:15 1999 +++ admindb.py Fri Jan 8 17:45:02 1999 @@ -113,7 +113,7 @@ 'admlogin.txt', {'listname': list_name, 'path' : os.environ.get('REQUEST_URI', - '/mailman/' + mm_cfg.admin_cgi + '/' + list_name), + '/mailman/' + mm_cfg.admindb_cgi + '/' + list_name), 'message' : message, }) print text Regards: Jul -- Linux Supporting Center -- Red Hat Qmail packages -- http://lsc.kva.hu PGP 0x1DE3631D / A8 B4 92 EE 1F 55 27 C8 86 64 9C 42 41 A4 BD B8 Don't spell GLIB backwards! From grin@tolna.net Fri Jan 8 19:08:19 1999 From: grin@tolna.net (Peter Gervai) Date: Fri, 8 Jan 1999 20:08:19 +0100 Subject: [Mailman-Developers] is restricted unsubscribe possible? Message-ID: <19990108200819.H25894@mail.tolna.net> I think I failed to see how can I make a list set up so that its members cannot unsubscribe without owner's approval? (Or does "approval for subscribe" setting cover unsub messages as well?) I would like to use a list as our 'problem notification' service but I don't want to see clueless idiots, erm, I mean, windows users :) playing with subscriptions at all. It should be act just like a 'glorified alias file' (but much easier to handle). bye, grin From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Jan 8 19:39:05 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 8 Jan 1999 14:39:05 -0500 (EST) Subject: [Mailman-Developers] Little bug(?) in admindb References: <13973.43448.461046.183947@anthem.cnri.reston.va.us> Message-ID: <13974.24281.760791.768849@anthem.cnri.reston.va.us> >>>>> "BN" == Balazs Nagy writes: BN> I didn't have a mouse but a simple console screen with lynx. BN> Here's my new test: BN> With one pending: OK BN> With two or more pendings: I'm unable to reproduce this, but I can see how this might happen. Please try this patch instead. -Barry -------------------- snip snip -------------------- Index: admindb.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/Cgi/admindb.py,v retrieving revision 1.7 diff -c -r1.7 admindb.py *** admindb.py 1998/12/19 04:43:46 1.7 --- admindb.py 1999/01/08 19:34:49 *************** *** 192,199 **** ignore_subscribes = 1 SubscribeNone() for k in form.keys(): try: ! v = int(form[k].value) request_id = int(k) except ValueError: continue --- 192,202 ---- ignore_subscribes = 1 SubscribeNone() for k in form.keys(): + formv = form[k] + if type(formv) == types.ListType: + continue try: ! v = int(formv.value) request_id = int(k) except ValueError: continue From Harald.Meland@usit.uio.no Fri Jan 8 21:55:53 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 08 Jan 1999 22:55:53 +0100 Subject: [Mailman-Developers] fwd: Cron /usr/bin/python /home/mailman/cron/senddigests (fwd) In-Reply-To: Jerry Adlersfluegel's message of "Wed, 6 Jan 1999 17:20:55 -0600 (CST)" References: Message-ID: [Jerry Adlersfluegel] > Traceback (innermost last): > File "/home/mailman/cron/senddigests", line 37, in ? > main() > File "/home/mailman/cron/senddigests", line 34, in main > list.SendDigestIfAny() > File "/home/mailman/Mailman/Digester.py", line 194, in SendDigestIfAny > self.SendDigestOnSize(0) > File "/home/mailman/Mailman/Digester.py", line 206, in SendDigestOnSize > self.SendDigest() > File "/home/mailman/Mailman/Digester.py", line 290, in SendDigest > self.DeliverToList(d.Present(mime=0), > File "/home/mailman/Mailman/Deliverer.py", line 172, in DeliverToList > status = cmdproc.close() > IOError: (10, 'No child processes') > > > Any ideas? Yup. I believe this is a known problem with at least some RedHat cron daemons -- they run their jobs with some (rather vital, like SIGCHLD) signals set up to be ignored. Workaround: I think that adding something like this to the top of any script that is to be run from cron would work (as long as it is SIGCHLD that is being incorrectly ignored, anyway): import signal signal.signal(signal.SIGCHLD, signal.SIG_DFL) If this workaround does the job, it would IMHO be less obtrusive than the workaround currently in CVS. -- Harald From jerrya@fastrans.net Fri Jan 8 22:21:30 1999 From: jerrya@fastrans.net (Jerry Adlersfluegel) Date: Fri, 08 Jan 1999 16:21:30 -0600 Subject: [Mailman-Developers] fwd: Cron /usr/bin/python /home/mailman/cron/senddigests (fwd) References: Message-ID: <369684EA.4920C5CF@fastrans.net> Harald Meland wrote: > > [Jerry Adlersfluegel] > > > Traceback (innermost last): > > File "/home/mailman/cron/senddigests", line 37, in ? > > main() > > File "/home/mailman/cron/senddigests", line 34, in main > > list.SendDigestIfAny() > > File "/home/mailman/Mailman/Digester.py", line 194, in SendDigestIfAny > > self.SendDigestOnSize(0) > > File "/home/mailman/Mailman/Digester.py", line 206, in SendDigestOnSize > > self.SendDigest() > > File "/home/mailman/Mailman/Digester.py", line 290, in SendDigest > > self.DeliverToList(d.Present(mime=0), > > File "/home/mailman/Mailman/Deliverer.py", line 172, in DeliverToList > > status = cmdproc.close() > > IOError: (10, 'No child processes') > > > > > > Any ideas? > > Yup. I believe this is a known problem with at least some RedHat cron > daemons -- they run their jobs with some (rather vital, like SIGCHLD) > signals set up to be ignored. > > Workaround: I think that adding something like this to the top of any > script that is to be run from cron would work (as long as it is > SIGCHLD that is being incorrectly ignored, anyway): > > import signal > signal.signal(signal.SIGCHLD, signal.SIG_DFL) > > If this workaround does the job, it would IMHO be less obtrusive than > the workaround currently in CVS. > -- > Harald I have been paying attention, and that error report does not get sent every day. I think it only went out two or three times this week. I did not get that error today or yesterday. I haven't applied anything to the 1.0b7 installation. I'll pay attention to what happens. Thanks! From gstein@lyra.org Sat Jan 9 02:06:52 1999 From: gstein@lyra.org (Greg Stein) Date: Fri, 08 Jan 1999 18:06:52 -0800 Subject: [Mailman-Developers] Digests and Cron and Signals Message-ID: <3696B9BC.19691E55@lyra.org> [ responding from the archive, so this message will be formatted funny... ] ----INCLUDED MESSAGE---- I have upgraded mailman to the new release, 1.0b7, on my redhat 5 system. $ uname -a Linux jerrya 2.0.32 #4 Wed Jan 7 23:14:32 CST 1998 i486 unknown I still receive the following message every day when the digests go out. They are going out successfully, but this message still gets delivered. [snip of Cron Daemon traceback...] ----INCLUDED MESSAGE---- Actually, if you run MULTIPLE lists, then your mail is NOT being delivered. The traceback will occur on the FIRST mail list, preventing the rest from being delivered. I run into this EVERY day with mine and I patched my installation to ignore the error so that digests can go out for all lists. I put in a hack, though, to ignore it (similar to Barry's). I'm going to try Harald's signal patch (cool!) and report back on its success. If I stop getting my noon cron reports of failure, then we'll be golden. Note: mine is occuring on a RedHat 5.1 system. -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Sat Jan 9 02:16:17 1999 From: gstein@lyra.org (Greg Stein) Date: Fri, 08 Jan 1999 18:16:17 -0800 Subject: [Mailman-Developers] shipstopper bug Message-ID: <3696BBF0.31971360@lyra.org> This is a multi-part message in MIME format. --------------2F2A7A284F92DB72623DFFB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I've reported this before, and I will reiterate it again. Moreover, I would call it a "shipstopper" for the 1.0 release. I'm using 1.0b6 here. This has hit me FIVE times in the past 24 hours. Each time, I have to take manual action to fix things (as reported before). Basically, shutting down the sendmail listener to stop the mail loop, clearing the Mailman queue and sendmail queue of the loop-inducing garbage, and then bringing it back up. What happens is that somebody types in a request to the Mailman subscription page with a *local* mail address (i.e. no domain name). The confirmation email then gets sent. This bounces back to Mailman, but it doesn't understand that it is a bounce and tries to process the dumb thing. That fails massively (as seen in the attached mail), and responds to mailer-daemon with the error. More on this in a bit. What appears wonky is that Mailman seems to attempt to deliver the confirmation over and over, nonstop. Here is a portion of the mail log for RAB25492: Jan 8 17:18:19 ns1 sendmail[25492]: RAA25492: ... User unknown Jan 8 17:18:19 ns1 sendmail[25492]: lost input channel from localhost [127.0.0.1] Jan 8 17:18:19 ns1 sendmail[25492]: RAA25492: from=, size=0, class=0, pri=0, nrcpts=0, proto=SMTP, relay=localhost [127.0.0.1] Jan 8 17:18:19 ns1 sendmail[25492]: RAA25492: RAB25492: DSN: ... User unknown Jan 8 17:18:27 ns1 sendmail[25492]: RAB25492: to=|"/home/mailman/install/mail/wrapper mailcmd hognews", delay=00:00:08, xdelay=00:00:07, mailer=prog, stat=Sent Note the "lost input channel". I don't think that is right. The cycle above repeats at 17:18:32. This goes on until I kill it. In the above case, the mailer-deamon is responding to Mailman (the last line). Mailman then processes that mail, and returns a message like the attached garbage to root. I just deleted 1400 messages from my root mailbox. Some more information: In logs/error, I see the following traceback repeated every 30 minutes: Jan 08 11:12:07 1999 smtplib: Traceback (innermost last): smtplib: File "/home/mailman/install/cron/run_queue", line 31, in ? smtplib: OutgoingQueue.processQueue() smtplib: File "/home/mailman/install/Mailman/OutgoingQueue.py", line 38, in processQueue smtplib: Utils.TrySMTPDelivery(recip,sender,text,full_fname) smtplib: File "/home/mailman/install/Mailman/Utils.py", line 201, in TrySMTPDelivery smtplib: con.send(to=recipient,frm=sender,text=text) smtplib: File "/home/mailman/install/Mailman/smtplib.py", line 75, in send smtplib: self.getresp() smtplib: File "/home/mailman/install/Mailman/smtplib.py", line 147, in getresp smtplib: raise bad, resp smtplib: smtplib.error_proto : 550 ... User unknown I suspect that the "lost input channel" further above is due to a similar condition. The traceback drops the socket, fails to log anything, and fails to clear the confirmation email from the outgoing queue. Mailman processes the error response from mailer-daemon and drops it into the queue. It runs the queue which processes that response (flooding the root email box) along with the confirmation (again), which starts the loop again. I also believe that I now understand why my machine died back in August due to this bug, but that hasn't happened to me recently. Because of the queueing nature of Mailman, there is only one loop occurring at a time. HOWEVER: if that cron job wakes up and processes the queue, then it starts a second, simultaneous loop. If enough of those 30-minute cron-caused loop-creations occurs, then your machine is completely dead as it thrashes, trying to process all those loops. I've been catching them relatively soon in this past spate of them (although I did miss one last night for a long while, causing my loadavg to hit 15... heh. it's also a DNS server and its response became SLOWWWWWW... which led me to look into it) So, I see one or more errors here: 1) a possible traceback not being logged during Q processing 2) said traceback fouling the outgoing mail queue processing 3) should probably disallow domain-less addresses in all places 4) bounce detection needs to recognize the mail that caused the attached response (read between the lines for the content) And because this can swamp a box, I would highly recommend it gets fixed :-) thx -g -- Greg Stein, http://www.lyra.org/ --------------2F2A7A284F92DB72623DFFB Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from ns1.lyra.org (root@ns1.lyra.org [208.192.43.10]) by svpal.svpal.org (8.9.0/8.9.0) with ESMTP id RAA12486 for ; Fri, 8 Jan 1999 17:05:39 -0800 (PST) Received: (from root@localhost) by ns1.lyra.org (8.8.5/8.8.5) id RAA25542 for gstein@lyra.org; Fri, 8 Jan 1999 17:19:53 -0800 Date: Fri, 8 Jan 1999 17:19:53 -0800 From: Greg Stein Message-Id: <199901090119.RAA25542@ns1.lyra.org> To: gstein@lyra.org ( Subject: Mailman results for Hognews To: mailer-daemon@ns1.lyra.org **** Subject line ignored: Returned mail: ... User unknown >>>> This is a MIME-encapsulated message **** this: Command UNKNOWN. >>>> --RAB25528.915844738/ns1.lyra.org **** --rab25528.915844738/ns1.lyra.org: Command UNKNOWN. >>>> The original message was received at Fri, 8 Jan 1999 17:18:56 -0800 **** the: Command UNKNOWN. >>>> from localhost [127.0.0.1] **** from: Command UNKNOWN. >>>> ----- The following addresses had permanent fatal errors ----- **** -----: Command UNKNOWN. >>>> **** : Command UNKNOWN. >>>> ----- Transcript of session follows ----- **** -----: Command UNKNOWN. >>>> <<< RCPT TO: **** <<<: Command UNKNOWN. >>>> 550 ... User unknown **** 550: Command UNKNOWN. >>>> 421 ns1.lyra.org Lost input channel from localhost [127.0.0.1] **** 421: Command UNKNOWN. >>>> ns1.lyra.org Lost input channel from localhost [127.0.0.1] **** ns1.lyra.org: Command UNKNOWN. >>>> --RAB25528.915844738/ns1.lyra.org **** --rab25528.915844738/ns1.lyra.org: Command UNKNOWN. >>>> Content-Type: message/delivery-status **** content-type:: Command UNKNOWN. >>>> Reporting-MTA: dns; ns1.lyra.org **** reporting-mta:: Command UNKNOWN. >>>> Received-From-MTA: DNS; localhost **** received-from-mta:: Command UNKNOWN. >>>> Arrival-Date: Fri, 8 Jan 1999 17:18:56 -0800 **** arrival-date:: Command UNKNOWN. >>>> Final-Recipient: RFC822; ch9517@ns1.lyra.org **** final-recipient:: Command UNKNOWN. >>>> Action: failed **** action:: Command UNKNOWN. >>>> Status: 5.1.1 **** status:: Command UNKNOWN. >>>> Last-Attempt-Date: Fri, 8 Jan 1999 17:18:58 -0800 **** last-attempt-date:: Command UNKNOWN. >>>> --RAB25528.915844738/ns1.lyra.org-- **** --rab25528.915844738/ns1.lyra.org--: Command UNKNOWN. --------------2F2A7A284F92DB72623DFFB-- From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Jan 9 06:06:28 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sat, 9 Jan 1999 01:06:28 -0500 (EST) Subject: [Mailman-Developers] Mailman 1.0b7 bug reports References: <199901081146.MAA19567@mailhost.uni-koblenz.de> Message-ID: <13974.61924.456561.780766@anthem.cnri.reston.va.us> >>>>> "DD" == Detlev Droege writes: DD> We did set up Mailman at DD> http://mailhost.uni-koblenz.de/mailman/admin/ mostly to admin DD> local user groups. I'm the list-admin of the single non-local DD> group (EINST-Mitglieder). I see you're using 1.0b7, so I can't chalk your problems up to an old release ;-) DD> 1 - I did a bulk subscribe for approx. 100 members via the DD> HTML interface. I overlooked a bogus line when pasting DD> the addresses into the textfield and Mailman generated DD> a strange entry. A syntax check on the mail addresses DD> would be helpful. [The bogus address had a pending DD> closing paranthesis: "AUser@somewhere.com)" ] I've added more checks on the email address for the next release. You should not be able to subscribe any address that starts with a -, has any of []<>()|; in the address, or be unqualified (i.e. local; have no `@' in the string). DD> 2 - The abovementioned list of email addresses did contain DD> mixed-case entries like "Detlev.Droege@uni-koblenz.de". DD> Mailman did lowercase them in most places, but not in all DD> places. To be RFC compliant, Mailman case-preserves the username portion of the email address for sending email. Almost everywhere else, the email address should just be lower cased. You found one place that we missed. This will be fixed in the next release. DD> 3 - When the first external member submitted an article, its DD> From: address differed from the subscribed address, so I as DD> the list admin was asked to approve the message. I did so, DD> however the message was never sent out to the list members. DD> It appears in the "post" logfile, it is archived in the DD> HTML archive, but it was never mailed to the list members. DD> Our postmaster could not detect any failure of our mail DD> system nor any error messages. Is it possible Mailman DD> just forgot to send it out ? Sure, anything's possible, but I haven't been able to reproduce this problem. I set up a list that does not require admin approval, but does restrict postings to members. Then I sent a message with a non-member From: line, and went through approval Web page. The message got posted to the list. I'll need some help, or more information, to help debug this. DD> 4 - As list admin I'd like to have an interface to change DD> the mail address of list members. I allready got several DD> requests to do so. It's a little boring to do so by DD> unsubscribing the old and then subscribing the new address. DD> Moreover, this generates a useles "Good Bye" and "Welcome" DD> message which might confuse the subscriber. This is definitely on the list, but it requires some architectural changes to Mailman, so we're putting anything like this off for a while. One thing we though might not be too hard would be the ability to `clone' a user to a new address. You'd still have to remove the old address, but at least you wouldn't have to go and reset all their options. Still, I don't think we'll do this for 1.0, but perhaps for 1.1. DD> Anyway - Mailman is a great tool and I like it a lot ! DD> Don't take this as complaint, but as my (very) small effort DD> to make it even better. And we appreciate it! Hopefully we can get more information and figure out what's going on with #3 above. Thanks, -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Jan 9 06:29:49 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sat, 9 Jan 1999 01:29:49 -0500 (EST) Subject: [Mailman-Developers] is restricted unsubscribe possible? References: <19990108200819.H25894@mail.tolna.net> Message-ID: <13974.63325.280292.249197@anthem.cnri.reston.va.us> >>>>> "PG" == Peter Gervai writes: PG> I think I failed to see how can I make a list set up so that PG> its members cannot unsubscribe without owner's approval? (Or PG> does "approval for subscribe" setting cover unsub messages as PG> well?) Nope, can't currently be done. PG> I would like to use a list as our 'problem notification' PG> service but I don't want to see clueless idiots, erm, I mean, PG> windows users :) playing with subscriptions at all. It should PG> be act just like a 'glorified alias file' (but much easier to PG> handle). Would you also want the ability to not allow users to edit their options? Anyway, I've put both these suggestions on the TODO list. -Barry From markw98@ibm.net Sat Jan 9 18:33:31 1999 From: markw98@ibm.net (Mark Williamson) Date: Sat, 9 Jan 1999 10:33:31 -0800 Subject: [Mailman-Developers] New to Mailman, Question on Platforms Message-ID: <005801be3bfe$8f581900$aad9fea9@mark.pacbell.net> I've looked through the archives, but i couldn't find the answer to my question. I am not proficient at all on Linux/Unix systems, just a novice. The bulk of my experience has been on NT. That leads to my question: SInce Python has been ported to NT, can mailman run on this platform? Are there any FAQ's, docs or links that i can read on how to do this? Or is this undoable because of the need to compile some of the .C programs? Can the .C program's functionality be duplicated on NT or rewritten in Python? Regards, Mark Williamson From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Jan 9 19:10:04 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sat, 9 Jan 1999 14:10:04 -0500 (EST) Subject: [Mailman-Developers] New to Mailman, Question on Platforms References: <005801be3bfe$8f581900$aad9fea9@mark.pacbell.net> Message-ID: <13975.43404.933257.241961@anthem.cnri.reston.va.us> >>>>> "MW" == Mark Williamson writes: MW> That leads to my question: SInce Python has been ported to NT, MW> can mailman run on this platform? Are there any FAQ's, docs MW> or links that i can read on how to do this? Or is this MW> undoable because of the need to compile some of the .C MW> programs? Can the .C program's functionality be duplicated on MW> NT or rewritten in Python? At this point, I think it's mostly undoable because of our heavy reliance on a forking model. Win32 doesn't have fork(). We've talked about moving to a threaded long-running server model, or adopting Zope as a platform, and both of those (very future) developments would probably let us support NT. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Jan 9 19:24:41 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sat, 9 Jan 1999 14:24:41 -0500 (EST) Subject: [Mailman-Developers] shipstopper bug References: <3696BBF0.31971360@lyra.org> Message-ID: <13975.44281.396310.817435@anthem.cnri.reston.va.us> >>>>> "GS" == Greg Stein writes: GS> What happens is that somebody types in a request to the GS> Mailman subscription page with a *local* mail address (i.e. no GS> domain name). The confirmation email then gets sent. This GS> bounces back to Mailman, but it doesn't understand that it is GS> a bounce and tries to process the dumb thing. That fails GS> massively (as seen in the attached mail), and responds to GS> mailer-daemon with the error. More on this in a bit. GS> 3) should probably disallow domain-less addresses in all GS> places Greg, It should now (with 1.0b7+) be impossible to subscribe a domainless email address. I've verified this with the Membership Management interface, a normal user's use of the subscribe page, attempting to subscribe via email directly, and using bin/add_members. If this means that from now on, no one will encounter the problem, I'm tempted not to investigate further. My question to the developers is, how important do you think it is to fix this problem for the early adopters? You guys can `just' delete the unqualified addresses and force those people to re-subscribe using a now valid address. Would this be a huge burden? Of course, if anybody's seen this happen for qualified addresses, then obviously we need to debug it. -Barry From John@list.org Sat Jan 9 19:59:55 1999 From: John@list.org (John Viega) Date: Sat, 9 Jan 1999 11:59:55 -0800 Subject: [Mailman-Developers] New to Mailman, Question on Platforms In-Reply-To: <13975.43404.933257.241961@anthem.cnri.reston.va.us>; from Barry A. Warsaw on Sat, Jan 09, 1999 at 02:10:04PM -0500 References: <005801be3bfe$8f581900$aad9fea9@mark.pacbell.net> <13975.43404.933257.241961@anthem.cnri.reston.va.us> Message-ID: <19990109115955.B2647@viega.org> I mostly agree with Barry's answer, but for different reasons. You can use the cygwin stuff to get fork(), etc... under windows. There is no reasonable *free* mail transport for windows that I know of, but you could always pass that off to another machine, with some hacking. I don't know what web servers look like for windows. All in all, the pieces are probably all there, but there would be a lot of work involved in getting everything working. John On Sat, Jan 09, 1999 at 02:10:04PM -0500, Barry A. Warsaw wrote: > > >>>>> "MW" == Mark Williamson writes: > > At this point, I think it's mostly undoable because of our heavy > reliance on a forking model. Win32 doesn't have fork(). > > We've talked about moving to a threaded long-running server model, or > adopting Zope as a platform, and both of those (very > future) developments would probably let us support NT. > > -Barry > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Jan 9 19:48:18 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sat, 9 Jan 1999 14:48:18 -0500 (EST) Subject: [Mailman-Developers] Logo contest Message-ID: <13975.45698.360777.704107@anthem.cnri.reston.va.us> I would like to have a Mailman logo, that would serve a function similar to Just van Rossum's excellent "Python Powered" logo. I am not much of a (visual :-) artist so if I had to do it, I'd probably hack around with Gimp's logo scripts for an hour or so and come up with something really cheezy. So I figured I'd open up a logo contents with y'all to tap the fast energies and talents of our community. See http://www.python.org/psa/Logo.html for the logos that Just came up with for Python. Here are my requirements: - The phrase should be "Delivered by Mailman" - We should have a large logo and a small logo, of approximately the sizes Just chose, but I'm not as concerned about animated versions. - I'm thinking that the background should be a simple caricature of an envelope, either of the obverse side (with a stamp in the upper left corner), or the reverse side, with flap lines. This is just a suggestion. - Colors and fonts are up to you, but readability is of utmost importance. - GIF is probably the best format. - You will have to GPL your logo, and be willing to assign it to the FSF (and probably have your employer do the same). Send your submissions to me -- MIME is fine. I'll post them on the Web so we can all see and vote on them. The winner gets his or her little chunk of net.immortality and the eternal thanks of Mailman users for years to come. I would like to have a logo for the 1.0 release, which I think will realistically be end-of-January. Thanks, -Barry From markw98@ibm.net Sat Jan 9 21:57:30 1999 From: markw98@ibm.net (Mark Williamson) Date: Sat, 9 Jan 1999 13:57:30 -0800 Subject: [Mailman-Developers] New to Mailman, Question on Platforms Message-ID: <015901be3c1b$0ed6e320$aad9fea9@mark.pacbell.net> i.e. not worth the effort :) hehehe, always knew i'd put this redhat disk to use -----Original Message----- From: John Viega To: Barry A. Warsaw ; Mark Williamson Cc: mailman-developers@python.org Date: Saturday, January 09, 1999 11:47 AM Subject: Re: [Mailman-Developers] New to Mailman, Question on Platforms >I mostly agree with Barry's answer, but for different reasons. You >can use the cygwin stuff to get fork(), etc... under windows. There >is no reasonable *free* mail transport for windows that I know of, but >you could always pass that off to another machine, with some hacking. >I don't know what web servers look like for windows. All in all, the >pieces are probably all there, but there would be a lot of work >involved in getting everything working. > >John > > >On Sat, Jan 09, 1999 at 02:10:04PM -0500, Barry A. Warsaw wrote: >> >> >>>>> "MW" == Mark Williamson writes: >> >> At this point, I think it's mostly undoable because of our heavy >> reliance on a forking model. Win32 doesn't have fork(). >> >> We've talked about moving to a threaded long-running server model, or >> adopting Zope as a platform, and both of those (very >> future) developments would probably let us support NT. >> >> -Barry >> >> _______________________________________________ >> Mailman-Developers maillist - Mailman-Developers@python.org >> http://www.python.org/mailman/listinfo/mailman-developers > From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Jan 9 22:53:19 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sat, 9 Jan 1999 17:53:19 -0500 (EST) Subject: [Mailman-Developers] New to Mailman, Question on Platforms References: <005801be3bfe$8f581900$aad9fea9@mark.pacbell.net> <13975.43404.933257.241961@anthem.cnri.reston.va.us> <19990109115955.B2647@viega.org> Message-ID: <13975.56799.556929.398149@anthem.cnri.reston.va.us> >>>>> "JV" == John Viega writes: JV> I mostly agree with Barry's answer, but for different reasons. JV> You can use the cygwin stuff to get fork(), etc... under JV> windows. The problem is that there isn't a standard Python distribution built on top of cygwin. I don't know if anybody's tried to that either. -Barry From gorgo@caesar.elte.hu Sun Jan 10 01:41:38 1999 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Sun, 10 Jan 1999 02:41:38 +0100 (MET) Subject: [Mailman-Developers] error message from cron Message-ID: Hello, Since I upgraded to 1.0b7 I get a couple of these messages each day. Any ideas why ? Traceback (innermost last): File "/usr/lib/mailman/cron/run_queue", line 27, in ? OutgoingQueue.processQueue() File "/usr/lib/mailman/Mailman/OutgoingQueue.py", line 126, in processQueue Utils.TrySMTPDelivery(recip,sender,text,full_fname) File "/usr/lib/mailman/Mailman/Utils.py", line 217, in TrySMTPDelivery OutgoingQueue.dequeueMessage(queue_entry) File "/usr/lib/mailman/Mailman/OutgoingQueue.py", line 184, in dequeueMessage os.unlink(q_entry) os.error: (2, 'No such file or directory') Greg From grin@tolna.net Sun Jan 10 16:43:08 1999 From: grin@tolna.net (Peter Gervai) Date: Sun, 10 Jan 1999 17:43:08 +0100 Subject: [Mailman-Developers] colored columns in memberlist management table Message-ID: <19990110174308.C16780@mail.tolna.net> Would be quite easy to gray the background of even coloumns of the membership management table to make it easier to see which switch goes for what settings. And maybe the header at the end of the table wouldn't hurt as well. (My screen is maybe too small and the header gets scrolled off the screen when I go to the bottom of the memberlist.) bye, grin From julian7@kva.hu Mon Jan 11 08:41:32 1999 From: julian7@kva.hu (Balazs Nagy) Date: Mon, 11 Jan 1999 09:41:32 +0100 (CET) Subject: [Mailman-Developers] error message from cron In-Reply-To: Message-ID: On Sun, 10 Jan 1999, Gergely Madarasz wrote: > Hello, > > Since I upgraded to 1.0b7 I get a couple of these messages each day. Any > ideas why ? > > Traceback (innermost last): > File "/usr/lib/mailman/cron/run_queue", line 27, in ? > OutgoingQueue.processQueue() > File "/usr/lib/mailman/Mailman/OutgoingQueue.py", line 126, in processQueue > Utils.TrySMTPDelivery(recip,sender,text,full_fname) > File "/usr/lib/mailman/Mailman/Utils.py", line 217, in TrySMTPDelivery > OutgoingQueue.dequeueMessage(queue_entry) > File "/usr/lib/mailman/Mailman/OutgoingQueue.py", line 184, in dequeueMessage > os.unlink(q_entry) > os.error: (2, 'No such file or directory') Fast fix: --- OutgoingQueue.py.orig Mon Jan 11 09:40:30 1999 +++ OutgoingQueue.py Mon Jan 11 09:40:50 1999 @@ -176,4 +176,7 @@ # remove it from the queue # def dequeueMessage(q_entry): - os.unlink(q_entry) + try: + os.unlink(q_entry) + except: + pass -- Linux Supporting Center -- Red Hat Qmail packages -- http://lsc.kva.hu PGP 0x1DE3631D / A8 B4 92 EE 1F 55 27 C8 86 64 9C 42 41 A4 BD B8 Don't spell GLIB backwards! From klm@python.org Mon Jan 11 16:57:32 1999 From: klm@python.org (Ken Manheimer) Date: Mon, 11 Jan 1999 11:57:32 -0500 (EST) Subject: [Mailman-Developers] error message from cron In-Reply-To: Message-ID: On Mon, 11 Jan 1999, Balazs Nagy wrote: > On Sun, 10 Jan 1999, Gergely Madarasz wrote: > > [...] > > os.error: (2, 'No such file or directory') > > Fast fix: > > --- OutgoingQueue.py.orig Mon Jan 11 09:40:30 1999 > +++ OutgoingQueue.py Mon Jan 11 09:40:50 1999 > @@ -176,4 +176,7 @@ > # remove it from the queue > # > def dequeueMessage(q_entry): > - os.unlink(q_entry) > + try: > + os.unlink(q_entry) > + except: > + pass (Thanks for the suggestion! Due to some overriding other concerns i won't have time immediately to look at incorporating it - maybe one of the other central folks will - but i do have a fairly important coding practice to suggest for mailman submissions. Avoid using unqualified 'excepts' unless the exception case code does something specific with the results. Ie, prevent hiding unanticipated exceptions, just catch the ones you mean to catch. In this case, something like 'except os.error' instead of 'except'. And that's just for the fast fix - a real fix should take check that the os.error is "no such file...", and perhaps log something... We're urgently trying to eliminate anything that hides bugs, otherwise the system's operation becomes full of mysteries, and not approachable as an open source effort. (Hidden bugs are nuisances in *any* context.) Please don't take this as a criticism of your input - i'm just taking the opportunity to make this practice clear to everyone.) ken manheimer klm@python.org From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Tue Jan 12 20:26:54 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 12 Jan 1999 15:26:54 -0500 (EST) Subject: [Mailman-Developers] Re: [Mailman-Users] Wierd Mailman problem References: <369B7E1A.B3A5F822@blowtorch.com> Message-ID: <13979.45070.392127.454362@anthem.cnri.reston.va.us> >>>>> "GH" == George Hartz writes: GH> The web interface seems to work okay, although I don't get GH> anything in the archives. Should clicking on the archives link GH> work before any messages have been posted to the list? No, that's a buglet. The archive link is not functional until at least one message has been posted to the list. GH> Anyway the problem I seem to be having is that Mailman is GH> failing without any errors at all. User and group ID's seem to GH> be set correctly. The wrapper programs aren't logging any GH> errors for bad UID's. (And running the programs as an GH> incorrect user *does* log them, so I know the logging itself GH> works. I'm sure you know that if the error occurs because of a gid mismatch, in either the CGI wrapper or the mail wrapper, errors are only logged to syslog, not to $prefix/logs/error. For mail, you ought to also get a bounce containing the error message, and for CGI -- with the next version -- you will get a more useful Web diagnostic page. Once control has been passed to the Python world (e.g. the `driver' script for CGI, or `post' for mail), then errors get logged to Mailman's log files. Note that a misconfiguration of syslog or your mail system might mean that those pre-Python errors are getting lost. [This is probably more useful to mailman-developers] Once you're in the Python world, there are several ways to log error messages for debugging. My favorite is, once I have a MailList object, I like to call the LogMsg() method with kind=='debug', kind of like so: mlistobj.LogMsg('debug', 'I got to here: %s', 'foo method') This will timestamp the message, and write it to $prefix/errors/debug. -Barry From klm@python.org Tue Jan 12 21:02:14 1999 From: klm@python.org (Ken Manheimer) Date: Tue, 12 Jan 1999 16:02:14 -0500 (EST) Subject: [Mailman-Developers] mailman FAQ? Message-ID: <13979.46721.23513.829273@glyph.cnri.reston.va.us> I'm scrambling with a job change (possibly an exciting one for mailman, as well as for me), but have an idea i'd like to put out there, in the meanwhile. Barry, and harald, and others - thanks all! - have been answering some questions that are clearly coming up Frequently - seems like perfect fodder for the start of a mailman FAQ. Would anyone like to form such a thing? How about a mailman faq wizard, somewhere on list.org? Or maybe python.org? I won't have time to set it up - but it probably ought be... (The questions that i clearly see are setting of the mailman UID/GID, debugging it when it goes awry, and dealing with the archives stuff, particularly the slightly surprising fact that a public archive link is not created until the first posting, while the actual private-dir file already is there. While barry's recent checkin to make the UID/GID setting error message provide more info should go a long way to helping (and ought to be factored in to any explanation), it still may be worth answering OAFA - once and for all. Any other hidden items worth mentioning?) ken manheimer klm@python.org From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Tue Jan 12 21:09:07 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 12 Jan 1999 16:09:07 -0500 (EST) Subject: [Mailman-Developers] mailman FAQ? References: <13979.46721.23513.829273@glyph.cnri.reston.va.us> Message-ID: <13979.47603.491341.234786@anthem.cnri.reston.va.us> >>>>> "KM" == Ken Manheimer writes: KM> How about a mailman faq wizard, somewhere on list.org? Or KM> maybe python.org? I won't have time to set it up - but it KM> probably ought be... The distrib now has a FAQ file (renamed from PROBLEMS which no one seemed to read :-). A faqwiz on python.org or list.org is definitely something I'd like to set up, when I get some time. -Barry From gstein@lyra.org Wed Jan 13 12:12:00 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 13 Jan 1999 04:12:00 -0800 Subject: [Mailman-Developers] Re: Digests and Cron and Signals References: <3696B9BC.19691E55@lyra.org> Message-ID: <369C8D90.22C53D8@lyra.org> Harald's signal patch worked on my system. No more annoying reports from Cron about "No such process". Thanx, Harald! For my particular test, I added the two lines to cron/senddigests. I would recommend that the next Mailman release include the two lines in each of cron/*. thx, -g Greg Stein wrote: > > [ responding from the archive, so this message will be formatted > funny... ] > > ----INCLUDED MESSAGE---- > I have upgraded mailman to the new release, 1.0b7, on my redhat 5 > system. > > $ uname -a > Linux jerrya 2.0.32 #4 Wed Jan 7 23:14:32 CST 1998 i486 unknown > > I still receive the following message every day when the digests go out. > They are going out successfully, but this message still gets delivered. > > [snip of Cron Daemon traceback...] > ----INCLUDED MESSAGE---- > > Actually, if you run MULTIPLE lists, then your mail is NOT being > delivered. The traceback will occur on the FIRST mail list, preventing > the rest from being delivered. > > I run into this EVERY day with mine and I patched my installation to > ignore the error so that digests can go out for all lists. > > I put in a hack, though, to ignore it (similar to Barry's). I'm going to > try Harald's signal patch (cool!) and report back on its success. If I > stop getting my noon cron reports of failure, then we'll be golden. > > Note: mine is occuring on a RedHat 5.1 system. > > -g > > -- > Greg Stein, http://www.lyra.org/ -- Greg Stein, http://www.lyra.org/ From andy@nachoz.com Wed Jan 13 15:20:30 1999 From: andy@nachoz.com (Andy Harrison) Date: Wed, 13 Jan 1999 10:20:30 -0500 (EST) Subject: [Mailman-Developers] Re: [Mailman-Users] Wierd Mailman problem In-Reply-To: <13979.45070.392127.454362@anthem.cnri.reston.va.us> Message-ID: On 12-Jan-99 Barry A. Warsaw wrote: > >>>>>> "GH" == George Hartz writes: > > GH> The web interface seems to work okay, although I don't get > GH> anything in the archives. Should clicking on the archives link > GH> work before any messages have been posted to the list? > > No, that's a buglet. The archive link is not functional until at > least one message has been posted to the list. > What if messages have been posted to the list but the archiving still isn't working? --------------------------------- E-Mail: Andy Harrison Date: 13-Jan-99 Time: 10:15:31 This message was sent by XFMail --------------------------------- From gstein@lyra.org Wed Jan 13 17:18:48 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 13 Jan 1999 09:18:48 -0800 Subject: [Mailman-Developers] BUG: virtual hosting (was Re: [Mailman-Users] Bug in b7?) References: Message-ID: <369CD578.3E955457@lyra.org> Ken Manheimer wrote: > On Wed, 13 Jan 1999, Greg Stein wrote: > ... > > Could this be due to the "per-virtual host" list option? I don't recall > > exactly how/where you set that, but I've got it set on my mailman > > installation. Lists will only appear if the hostname in the URL matches > > the hostname listed in the configuration for the "URL root" or whatever it > > is called. > > Correct - jason, you might try adding the line: > > VIRTUAL_HOST_OVERVIEW = 0 > > to the end of Mailman/mm_cfg.py. > > By inhibiting VIRTUAL_HOST_OVERVIEW you set the overview pages to show > all the advertised hosts, not just the hosts which have a "preferred" > host name that's the same as the one by which people are getting to the > overview page. If it works, then you may want to check the setting for > DEFAULT_HOST_NAME, also in mm_cfg.py (or Defaults.py in the same dir, if > it was never overridden). You can also specify the preferred host name > on a per-list basis - it's one of the the options at the bottom of the > admin 'general options' page. Speaking of virtual hosts... BUG REPORT: When the automated, monthly reminder goes out, the text uses a host name that might not apply to all the mailing lists in the combined reminder(!). I got a number of emails on January 1 when people received their mailing list reminder for harleydavidson.com (I run a mailing list for that domain). People couldn't quite see how the Python2C Announcement list should be hosted on harleydavidson.com :-) The combined report is cool and all :-), but I would recommend that it only combines reports for lists on the same virtual host! thx -g -- Greg Stein, http://www.lyra.org/ From klm@python.org Wed Jan 13 19:08:55 1999 From: klm@python.org (Ken Manheimer) Date: Wed, 13 Jan 1999 14:08:55 -0500 (EST) Subject: [Mailman-Developers] BUG: virtual hosting (was Re: [Mailman-Users] Bug in b7?) In-Reply-To: <369CD578.3E955457@lyra.org> Message-ID: On Wed, 13 Jan 1999, Greg Stein wrote: > Speaking of virtual hosts... > > BUG REPORT: > > When the automated, monthly reminder goes out, the text uses a host name > that might not apply to all the mailing lists in the combined > reminder(!). > > I got a number of emails on January 1 when people received their mailing > list reminder for harleydavidson.com (I run a mailing list for that > domain). People couldn't quite see how the Python2C Announcement list > should be hosted on harleydavidson.com :-) Yikes! But with an amusing touch of irony, i must say:-) > The combined report is cool and all :-), but I would recommend that it > only combines reports for lists on the same virtual host! Good point. It should not be hard. All the relevant logic is in ~mailman/cron/mailpasswds. The fragment that does the grouping needs to be more discerning about how it groups, factoring in virtual host, and then the messages need to be sent out as if from mailman-admin on that virtual host. (Hmm - that's a bit of a problem, because currently mailman doesn't distinguish a number of owners. It can be kludged for now in mailpasswd, but a functional interface should be created to provide an owner address distinguished by host.) If anyone want to look at it, please do so - but realize that changes to mailpasswds requires good testing, because it only happens periodically, and causes a lot of traffic, quite a nuisance if it goes awry. I usually test with a version where the actual sends are inhibited, producing output to identify that it's doing what i want, before committing anything. If no one gets to it, i should before the end of the year. (Kidding - but i really do not know when i will next be able to change anything in mailman and have adquate time for testing the changes - no point in hacking if i can't be confident it works!) Ken From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Jan 15 02:46:05 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 14 Jan 1999 21:46:05 -0500 (EST) Subject: [Mailman-Developers] Re: [Mailman-Users] Wierd Mailman problem References: <13979.45070.392127.454362@anthem.cnri.reston.va.us> Message-ID: <13982.44013.659040.374536@anthem.cnri.reston.va.us> >>>>> "AH" == Andy Harrison writes: AH> What if messages have been posted to the list but the AH> archiving still isn't working? Even if you toggle to private archiving, that doesn't work either? What does the listing of the archives directory look like? -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Jan 15 04:40:18 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 14 Jan 1999 23:40:18 -0500 (EST) Subject: [Mailman-Developers] [ANNOUNCE] Mailman 1.0b8 Message-ID: <13982.50866.34365.722114@anthem.cnri.reston.va.us> While there are still a few outstanding problems reported by users, I think we've nailed enough bugs since 1.0b7 to warrant a new release, so I'm announcing 1.0b8 tonight. As usual, feel free to pick it up from www.list.org. I think we're getting really close. I'm hoping my last minute changes didn't bust anything, and I'm also hoping we can nail down the last few showstoppers people have reported (in particular the archiving problems). I also want to get Scott's envelope-sender change backed out. Please give 1.0b8 a shot and let us know if you have any problems. Feel free to continue to send ideas and suggestions. I'm in conservative mode now though -- let's get 1.0 out so we can start working on some of those cool ideas. Thanks, -Barry From julian7@kva.hu Fri Jan 15 14:10:05 1999 From: julian7@kva.hu (Balazs Nagy) Date: Fri, 15 Jan 1999 15:10:05 +0100 (CET) Subject: [Mailman-Developers] My new patches Message-ID: Hiyas, I have fixed some bugs in my MTA package and fitted to the latest CVS snapshot. You can download'em from http://www.kva.hu/~mailman/mailman-patches-19910115.tar.bz2 or http://www.kva.hu/~mailman/mailman-patches-19910115.tgz These patches apply 1 - a little code fix for the 'set' email command 2 - CGI extension handling 3 - Usage of Message Transfer Unit (sendmail and others) instead of SMTP (but uses SMTP if MTU sending doesn't work) Download it, apply it, use it, collect it! Send bugs to me, success stories to the list. Regards: Balazs -- #!/bin/perl -sp0777i I wrote two patches: -sendcommand: it creates two new command. The 'filelist' command sends the list of documents located in the $listdir/documents directory (filenames beginning with a '.' aren't included). The 'send filename' command sends a document to the user via email. This is only a quick code, because I needed it, please comment (I used the another parts of the code, because I'm not perfect in python...) (patch-sendcommand) -hungarian patch: perhaps this is useful for hungarian users. It includes the hungarian version of most of the files in the templates/ directory, and the hungarian version of the e-mail-messages (confirmation, welcome, request etc.) (patch-mailmanhu-1.0b8) Location: ftp://ftp.kma.bme.hu/pub/bence/mailman Regards: Bence From julian7@kva.hu Mon Jan 18 13:26:15 1999 From: julian7@kva.hu (Balazs Nagy) Date: Mon, 18 Jan 1999 14:26:15 +0100 (CET) Subject: [Mailman-Developers] Two patches In-Reply-To: Message-ID: On Mon, 18 Jan 1999, Hermann Benedek wrote: > I wrote two patches: > > -sendcommand: it creates two new command. The 'filelist' command sends the > list of documents located in the $listdir/documents directory (filenames > beginning with a '.' aren't included). The 'send filename' command sends a > document to the user via email. This is only a quick code, because I needed > it, please comment (I used the another parts of the code, because I'm not > perfect in python...) > (patch-sendcommand) I think we want to define a method how to handle - admin requests - document services via email. I wrote a similar patch to handle admin requests, but I'll wait until the stable release. > -hungarian patch: perhaps this is useful for hungarian users. It includes > the hungarian version of most of the files in the templates/ directory, and > the hungarian version of the e-mail-messages (confirmation, welcome, request > etc.) > (patch-mailmanhu-1.0b8) This is great because nowadays internationalization (i18n) is a great effort in every package. BUT... Did you try to enter an accented string to a WWW admin page? For example 'általános' (== general in Hungarian). It will say '\341ltal\341nos' next time. If you press a simple OK, you'll see '\\341ltal\\341nos' next time. This is due to string parsing in Python and I don't know how to handle it. Regards: Jul (aka Balazs) -- #!/bin/perl -sp0777i Hiyas, Three days ago I downloaded the latest CVS snapshot and I applied my patches to it. Now my users reported that their letters didn't posted to the list. I found that there's an error in MailList.py (I think). These fast fixes comes from experience and not from evidence :-> --- MailList.py.orig Mon Jan 11 09:33:44 1999 +++ MailList.py Mon Jan 18 15:33:35 1999 @@ -1140,7 +1140,7 @@ members = self.GetDeliveryMembers() if dont_send_to_sender: try: - recipients.remove(members) + recips.remove(members) # # sender not in list (case sensitive username problem?) # @@ -1149,14 +1149,14 @@ "couldn't remove %s from recipient list: %s", sender, str(members)) - recipients = [] + recips = [] for m in members: if not self.GetUserOption(m, mm_cfg.DisableDelivery): - recipients.append(m) + recips.append(m) self.LogMsg("post", "post to %s from %s size=%d", self._internal_name, msg.GetSender(), len(msg.body)) - self.DeliverToList(msg, recipients, + self.DeliverToList(msg, recips, header = self.msg_header % self.__dict__, footer = self.msg_footer % self.__dict__) if ack_post: -- #!/bin/perl -sp0777i >BUT... Did you try to enter an accented string to a WWW admin page? For >example '=E1ltal=E1nos' (=3D=3D general in Hungarian). It will say >'\341ltal\341nos' next time. If you press a simple OK, you'll see >'\\341ltal\\341nos' next time. This is due to string parsing in Python and I used only english characters (non-accented) in the email-messages. Not too good, but works with all system. I tried to write a 'MIME' line to the header, but I don't know how to do it in the MailCommandhandler.py. Is there a function that writes a string to the header, and can be used from MailCommandhandler? Web-admin page: I have the problem too. It works good until you change the page next time. Regards, Bence From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Tue Jan 19 05:15:59 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 19 Jan 1999 00:15:59 -0500 (EST) Subject: [Mailman-Developers] Mailman logo submission Message-ID: <13988.5391.688604.511812@anthem.cnri.reston.va.us> Hi folks, we have our first Mailman logo submission! Heidi Henderson has contributed a very cool logo -- see www.list.org for the large and small version. -Barry From tomas@euronetics.se Wed Jan 20 18:58:39 1999 From: tomas@euronetics.se (Tomas Fasth) Date: Wed, 20 Jan 1999 19:58:39 +0100 Subject: [Mailman-Developers] Mailman archive and MIME Message-ID: <00a301be44a6$e70c3770$f6d52dc1@bishop.twinspot.net> This is a multi-part message in MIME format. ------=_NextPart_000_00A0_01BE44AF.45E23210 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi. Are there anyone on this list currently working on a MIME fix for = mailman pipermail archiving? It currently (1.0b8) lack even the simplest = MIME support, as far as I understand. If you browse a pipermail archive = any MIME composed messages appears right out ugly and sometimes = unreadable (a matter of skill of course). There are at least two angles on this. One is that when MIME encoding = (quoted-printable,base64) has been applied it looks messy in raw format. = The other is that some mailers (outlook express...) can be configured to = send multipart/alternative with message in both HTML and plain text = versions. Looks even more messy in raw format. I know you guys are working hard to get a stable release of 1.0 out on = the streets. But before that happens I highly recommend to have this = particular issue addressed somehow. My point is: making a stable release = of a email/web based software in the year of 1999 without basic support = for MIME is a big shame. Hopefully, I am plain wrong about the whole = issue. May be I have missed the obvious. Of course, it is my hope that someone already have a solution on the = problem, or working on one. If not, as a last resort, I may volunteer but not before a few weeks = from now. Comments, any? Tomas ------=_NextPart_000_00A0_01BE44AF.45E23210 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi.
Are there = anyone on this=20 list currently working on a MIME fix for mailman pipermail archiving?=20 It currently (1.0b8) lack = even the=20 simplest MIME support, as far as I understand. If you browse a pipermail = archive any MIME=20 composed messages appears right out ugly and sometimes unreadable (a = matter of=20 skill of course).
There are at=20 least two angles on this. One is that when MIME encoding=20 (quoted-printable,base64) has been applied it looks messy in raw format. = The=20 other is that some mailers (outlook express...) can be configured to = send=20 multipart/alternative with message in both HTML and plain text versions. = Looks=20 even more messy in raw format.
I know you guys are working hard to get a stable release of 1.0 out = on the=20 streets. But before that happens I = highly=20 recommend to have this particular issue addressed somehow. My point is: making a stable release of a email/web based = software in the=20 year of 1999 without basic support for MIME is a big shame. Hopefully, I am plain wrong about the whole issue. May be I = have missed=20 the obvious.
Of course, it is my hope that someone already have a = solution=20 on the problem, or working on one.
If not, as a last resort, I may volunteer but not = before a few=20 weeks from now.
 
Comments, any?
 
Tomas
 
------=_NextPart_000_00A0_01BE44AF.45E23210-- From julian7@kva.hu Thu Jan 21 07:13:23 1999 From: julian7@kva.hu (Balazs Nagy) Date: Thu, 21 Jan 1999 08:13:23 +0100 (CET) Subject: [Mailman-Developers] Mailman archive and MIME In-Reply-To: <00a301be44a6$e70c3770$f6d52dc1@bishop.twinspot.net> Message-ID: On Wed, 20 Jan 1999, Tomas Fasth wrote: > Hi. > Are there anyone on this list currently working on a MIME fix for mailman > pipermail archiving? It currently (1.0b8) lack even the simplest MIME > support, as far as I understand. If you browse a pipermail archive any Not just the pipermail archiving lacks any mail support but admindb too. Just check out any admindb warning. Can you see any email addresses in <>s? The most important thing to replace < > and & characters, outside of any MIME encoded things. > MIME composed messages appears right out ugly and sometimes unreadable (a > matter of skill of course). > There are at least two angles on this. One is that when MIME encoding > (quoted-printable,base64) has been applied it looks messy in raw format. > The other is that some mailers (outlook express...) can be configured to > send multipart/alternative with message in both HTML and plain text > versions. Looks even more messy in raw format. Well, if someone sent me (or to my lists) any HTML + embedded crap, I warn him/her for the first time... > I know you guys are working hard to get a stable release of 1.0 out on the > streets. But before that happens I highly recommend to have this > particular issue addressed somehow. My point is: making a stable release > of a email/web based software in the year of 1999 without basic support > for MIME is a big shame. Hopefully, I am plain wrong about the whole > issue. May be I have missed the obvious. Agreed. > Of course, it is my hope that someone already have a solution on the > problem, or working on one. I saw something in the core Python and it could be easy to write a MIME converter but I have to do my state exam next week thus I can't work on the problem right now. Regards: Balazs -- #!/bin/perl -sp0777i Message-ID: [Balazs Nagy] > On Wed, 20 Jan 1999, Tomas Fasth wrote: > > > Hi. > > > Are there anyone on this list currently working on a MIME fix for mailman > > pipermail archiving? It currently (1.0b8) lack even the simplest MIME > > support, as far as I understand. If you browse a pipermail archive any > > Not just the pipermail archiving lacks any mail support but admindb > too. I think that's a separate issue -- you're talking about quoting special HTML characters. Which, of course, should be done -- but it hasn't got anything to do with MIME. > > MIME composed messages appears right out ugly and sometimes unreadable (a > > matter of skill of course). I haven't tried this, but wouldn't simply squeezing the mail text through the .unmimify() method of the `mimify' standard Python module before formatting it into HTML work (for the QP/base64 MIME issue, multipart messages is a whole other can of worms)? Is there a problem with what headers are retained in the mbox-format version of the archive (i.e. are the headers needed for proper MIME decoding stripped from the archive)? -- Harald From tomas@euronetics.se Thu Jan 21 16:37:28 1999 From: tomas@euronetics.se (Tomas Fasth) Date: Thu, 21 Jan 1999 17:37:28 +0100 Subject: [Mailman-Developers] Mailman archive and MIME Message-ID: <019001be455c$5598d620$f6d52dc1@bishop.twinspot.net> From: Harald Meland Date: den 21 januari 1999 13:16 >I haven't tried this, but wouldn't simply squeezing the mail text >through the .unmimify() method of the `mimify' standard Python module >before formatting it into HTML work (for the QP/base64 MIME issue, >multipart messages is a whole other can of worms)? That's probably one way to go. A good thing trying to use existing code. I'm not sure what exactly .unmimify() does, though. The minimum requirements for messages written in western european languages would be for the archiver's email-to-html conversion to honor the MIME header encoding (RFC 2047) and the basics of MIME body format (RFC 2045). >Is there a problem with what headers are retained in the mbox-format >version of the archive (i.e. are the headers needed for proper MIME >decoding stripped from the archive)? Not as far as I can see. Both Content-* and MIME-Version headers seem to be retained. The problem occurs when the static html pages are generated. Tomas From Harald.Meland@usit.uio.no Thu Jan 21 23:55:17 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 22 Jan 1999 00:55:17 +0100 Subject: [Mailman-Developers] Mailman archive and MIME In-Reply-To: Tomas Fasth's message of "Thu, 21 Jan 1999 17:37:28 +0100" References: <019001be455c$5598d620$f6d52dc1@bishop.twinspot.net> Message-ID: [Tomas Fasth] > From: Harald Meland > > >I haven't tried this, but wouldn't simply squeezing the mail text > >through the .unmimify() method of the `mimify' standard Python module > >before formatting it into HTML work (for the QP/base64 MIME issue, > >multipart messages is a whole other can of worms)? In the general case it wouldn't, unless there also was some kind of 8bit-character-set -> HTML representation thingy, i.e. something to convert the ISO-8859-1 character "å" into the HTML element "å". Unless there is some standard Python module for doing this, I opt for leaving it all out until after 1.0 is out -- we might as well do this Right from the start. > That's probably one way to go. A good thing trying to use existing code. I'm > not sure what exactly .unmimify() does, though. It converts quoted-printable (and optionally base64) encoded parts to 8bit parts. I does not format it as HTML, though. It also does nothing with regard to "Content-Type:"-type things. > The minimum requirements for messages written in western european > languages would be for the archiver's email-to-html conversion to > honor the MIME header encoding (RFC 2047) and the basics of MIME > body format (RFC 2045). Do include all of RFC2045 when you say "the basics of MIME body format"? I really can't see the benefit of e.g. parsing multipart/alternative messages and such when formatting them as HTML. > >Is there a problem with what headers are retained in the mbox-format > >version of the archive (i.e. are the headers needed for proper MIME > >decoding stripped from the archive)? > > Not as far as I can see. Both Content-* and MIME-Version headers > seem to be retained. Duh, just me looking in the wrong place -- indeed, the listname.mbox/listname.mbox archive does include all headers. BTW, is there any way of configuring which headers (if any) should be removed when generating the static downloadable text files? -- Harald From tomas@euronetics.se Fri Jan 22 19:54:04 1999 From: tomas@euronetics.se (Tomas Fasth) Date: Fri, 22 Jan 1999 20:54:04 +0100 Subject: [Mailman-Developers] Mailman archive and MIME Message-ID: <002c01be4640$f6c1a650$f6d52dc1@bishop.twinspot.net> From: Harald Meland Date: den 22 januari 1999 01:02 Subject: Re: [Mailman-Developers] Mailman archive and MIME >Unless there is some standard Python module for doing this, I opt for >leaving it all out until after 1.0 is out -- we might as well do this >Right from the start. Have a look at http://www.oac.uci.edu/indiv/ehood/mhonarc.html It's written in Perl but even so a good piece of software when it comes to graceful handling of MIME messages. >Do include all of RFC2045 when you say "the basics of MIME body >format"? I really can't see the benefit of e.g. parsing >multipart/alternative messages and such when formatting them as HTML. Again, take a look at http://www.oac.uci.edu/indiv/ehood/mhamimeeg/complex.html for an example on how it could be handled gracefully. The example is way to it's extreme but still... Tomas From janne@avocado.pc.helsinki.fi Sat Jan 23 10:15:53 1999 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 23 Jan 1999 12:15:53 +0200 Subject: [Mailman-Developers] An upgrading experience Message-ID: I just upgraded from 1.0b4 to the latest b8 (CVS snapshot). It went mostly fine. Some problems though: - Python 1.5 doesn't have smtplib.py. Python 1.5.1 does. The documentation claims that 1.5 is good enough. - When I try to edit HTML through the WWW interface, I get an attribute error about Error.MMBadPassword (or some such). Is this a bug, or are my mailing list objects too old? - in update.log mailman says templates seem like pre-b4. Do I need to upgrade them manually, or does it just meant the templates were in wrong directories? - I had some archives, but after running 'make update' a few times, they are gone. Instead I have symlinks (list, list.mbox - yes both are symlinks) in the archives directory pointing to public_html/archives/*. But public_html/archives does not exist. Further, apparently new messages do not get archived now, at least I can't find them anywhere. Should the mailboxes reside in the $prefix/archives directory? Just out of curiosity, I tried to run the $prefix/cron/archive script manually (writing "python archive 1"). The current crontab does not seem to call it. It complains: Traceback (innermost last): File "archive", line 55, in ? if level <= list.archive_update_frequency: AttributeError: archive_update_frequency Does just loading and saving all the mailing lists help, or should I set archive_update_frequency manually? -- Janne From janne@avocado.pc.helsinki.fi Sat Jan 23 15:08:41 1999 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 23 Jan 1999 17:08:41 +0200 Subject: [Mailman-Developers] An upgrading experience In-Reply-To: Janne Sinkkonen's message of "23 Jan 1999 12:15:53 +0200" References: Message-ID: Some clarifications to my earlier blurb: > - I had some archives, but after running 'make update' a few times, > they are gone. Instead I have symlinks (list, list.mbox - yes both are > symlinks) in the archives directory pointing to > public_html/archives/*. But public_html/archives does not > exist. This was partly incorrect and I did find the archives from $prefix/archives/private. > Further, apparently new messages do not get archived now, at least I > can't find them anywhere. Should the mailboxes reside in the > $prefix/archives directory? Actually they do get archived, no problem here. It seems that I should have mailed to the mailman-users list first or checked things more carefully. Sorry... -- Janne From ken@digicool.com Sat Jan 23 17:59:12 1999 From: ken@digicool.com (Ken Manheimer) Date: Sat, 23 Jan 1999 12:59:12 -0500 (EST) Subject: [Mailman-Developers] commercial maillist system, lyris, looks rather similar Message-ID: I just heard mention of a commercial mailling list manager, lyris, that upon a tiny bit of investigation looks similar in some ways to mailman - eg, the admin interface layout: http://www.lyris.com/demo/list/listinfo.html (listinfo?), the orientation on web interfaces, "automatic error handling" (bounce handling), built-in archives, built-in mail engine (for "blinding speed"), etc. From poking around a little, it looks like they use perl at least as an extension language - i wonder how it's built. I'm pretty curious how long it's been around - they claim that: "Lyris was the first email list server to offer a web interface for list administrators and members." so i wonder if it predates the mailman betas. (I also noticed the phrase No more "get me off this list!" messages. on the lyris "about" page (http://www.lyris.com/about.html), , framed as "failsafe unsubscribing" - i think i saw this phrase in a recent mailman-users posting, i would not be surprised if the poster saw it there...) It has some nice stuff that mailman doesn't - one interesting idea seems to be to use a news server for the archives. That way, archive browsers can use a news interface, or use a web browser to a news/web gateway. (They probably do not do exactly this - the mail interface is a separate product, "multi view", so i'm probably missing something...) Wish i had more time to investigate, if anyone does, please report back... Ken Manheimer klm@digicool.com From tomas@euronetics.se Sun Jan 24 11:49:28 1999 From: tomas@euronetics.se (Tomas Fasth) Date: Sun, 24 Jan 1999 12:49:28 +0100 Subject: [Mailman-Developers] Archiving using news gateway References: Message-ID: <36AB08C8.93359F4@euronetics.se> In "Re: [Mailman-Developers] commercial maillist system, lyris, looks rather similar" Ken Manheimer wrote: > It has some nice stuff that mailman doesn't - one interesting idea seems > to be to use a news server for the archives. That way, archive browsers > can use a news interface, or use a web browser to a news/web gateway. Interesting approach. That is surely a possible workaround for the current lack of MIME support in pipermail archiving. As a matter of fact, I like the idea so much that I will give it a try. Why didn't I thought of that before ;-) Now, if I only could remember where I last saw that nice (MIME aware) web frontend for reading (mail and) news... On the other hand, most people today already have the necessary software (part from a browser) for reading both mail and news. So I guess the archive-through-news approach will work in most cases. Comments? Tomas From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sun Jan 24 19:40:34 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sun, 24 Jan 1999 14:40:34 -0500 (EST) Subject: [Mailman-Developers] Posting bug References: Message-ID: <13995.30514.407214.934422@anthem.cnri.reston.va.us> >>>>> "BN" == Balazs Nagy writes: BN> Three days ago I downloaded the latest CVS snapshot and I BN> applied my patches to it. Now my users reported that their BN> letters didn't posted to the list. BN> I found that there's an error in MailList.py (I think). These BN> fast fixes comes from experience and not from evidence :-> I just noticed this one myself today! Here's a better patch, IMO. -Barry -------------------- snip snip -------------------- Index: MailList.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/MailList.py,v retrieving revision 1.109 diff -c -r1.109 MailList.py *** MailList.py 1999/01/13 23:55:23 1.109 --- MailList.py 1999/01/24 19:30:29 *************** *** 1138,1146 **** ack_post = 1 # Deliver the mail. members = self.GetDeliveryMembers() if dont_send_to_sender: try: ! recipients.remove(members) # # sender not in list (case sensitive username problem?) # --- 1138,1150 ---- ack_post = 1 # Deliver the mail. members = self.GetDeliveryMembers() + recipients = [] + for m in members: + if not self.GetUserOption(m, mm_cfg.DisableDelivery): + recipients.append(m) if dont_send_to_sender: try: ! recipients.remove(sender) # # sender not in list (case sensitive username problem?) # *************** *** 1149,1158 **** "couldn't remove %s from recipient list: %s", sender, str(members)) - recipients = [] - for m in members: - if not self.GetUserOption(m, mm_cfg.DisableDelivery): - recipients.append(m) self.LogMsg("post", "post to %s from %s size=%d", self._internal_name, msg.GetSender(), len(msg.body)) --- 1153,1158 ---- From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sun Jan 24 20:06:35 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sun, 24 Jan 1999 15:06:35 -0500 (EST) Subject: [Mailman-Developers] Mailman archive and MIME References: <00a301be44a6$e70c3770$f6d52dc1@bishop.twinspot.net> Message-ID: <13995.32075.566466.108157@anthem.cnri.reston.va.us> Just a quick note on this thread. I'd love it if Pipermail could handle MIME, but I gather that Andrew isn't very interested in working on Pipermail anymore. Unfortunately I probably do not have the time to hack on this either. But if someone else wants to contribute some patches, I'd be very happy to install them. It would be a Good Thing if the bundled archiver could handle this. An alternative is to make sure that Mailman can work with external archivers like MHonArc. This might be an easier way to go, leverages off of someone else's maintained code, and since MHonArc is GPL'd we could use it with no problems. Still, I doubt we'll ever bundle such archivers with Mailman. Finally, yes there are places where non-quoted HTML special characters are leaking through, and these do need to be fixed. -Barry From tomas@euronetics.se Sun Jan 24 21:38:50 1999 From: tomas@euronetics.se (Tomas Fasth) Date: Sun, 24 Jan 1999 22:38:50 +0100 Subject: [Mailman-Developers] Mailman archive and MIME References: <00a301be44a6$e70c3770$f6d52dc1@bishop.twinspot.net> <13995.32075.566466.108157@anthem.cnri.reston.va.us> Message-ID: <36AB92EA.9182FABD@euronetics.se> "Barry A. Warsaw" wrote: > I'd love it if Pipermail could handle MIME, but I gather that Andrew > isn't very interested in working on Pipermail anymore. Unfortunately > I probably do not have the time to hack on this either. But if > someone else wants to contribute some patches, I'd be very happy to > install them. It would be a Good Thing if the bundled archiver could > handle this. We are about to drop pipermail for now at our site (situated in Sweden). We will use either MHonArc or news gating or both. That will satisfy our need of accessing archives with correct handling of national characters as well as attachments. > An alternative is to make sure that Mailman can work with external > archivers like MHonArc. This might be an easier way to go, leverages > off of someone else's maintained code, and since MHonArc is GPL'd we > could use it with no problems. Still, I doubt we'll ever bundle such > archivers with Mailman. Having an archiver written in Perl bundled with an otherwise superb software (mainly) written in Python seem kind of weird to me. Anyway, Pipermail will surely do for the MIME-allergic community for the time being. Tomas From bwarsaw@python.org Mon Jan 25 04:21:56 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Sun, 24 Jan 1999 23:21:56 -0500 (EST) Subject: [Mailman-Developers] Mailman archive and MIME References: <00a301be44a6$e70c3770$f6d52dc1@bishop.twinspot.net> <13995.32075.566466.108157@anthem.cnri.reston.va.us> <36AB92EA.9182FABD@euronetics.se> Message-ID: <13995.61796.29935.601693@anthem.cnri.reston.va.us> >>>>> "TF" == Tomas Fasth writes: TF> We are about to drop pipermail for now at our site (situated TF> in Sweden). We will use either MHonArc or news gating or TF> both. That will satisfy our need of accessing archives with TF> correct handling of national characters as well as TF> attachments. Please tell us how it goes, and send us any patches that are necessary to interface Mailman with either solution. TF> Having an archiver written in Perl bundled with an otherwise TF> superb software (mainly) written in Python seem kind of weird TF> to me. Indeed! -Barry From akuchlin@cnri.reston.va.us Mon Jan 25 14:56:38 1999 From: akuchlin@cnri.reston.va.us (Andrew M. Kuchling) Date: Mon, 25 Jan 1999 09:56:38 -0500 (EST) Subject: [Mailman-Developers] Mailman archive and MIME In-Reply-To: <13995.32075.566466.108157@anthem.cnri.reston.va.us> References: <00a301be44a6$e70c3770$f6d52dc1@bishop.twinspot.net> <13995.32075.566466.108157@anthem.cnri.reston.va.us> Message-ID: <13996.33269.321434.225937@amarok.cnri.reston.va.us> Barry A. Warsaw writes: >I'd love it if Pipermail could handle MIME, but I gather that Andrew >isn't very interested in working on Pipermail anymore. Unfortunately >I probably do not have the time to hack on this either. But if The original motivation for writing Pipermail was because Hypermail was unmaintained at the time; it hadn't been updated since 1995. Things have changed now; a group of people has taken over Hypermail maintenance (http://www.landfield.com/hypermail/), there are various other programs such as MHonArc around, and e-mail archives are getting much fancier (look at egroups.com for an example). The other archivers are advancing faster on features because I don't really have time to hack on Mailman; for example, I think the current Hypermail version handles MIME-encoded messages. In short, I think the way of the future is to keep the existing Pipermail archive for the 70% of users with relatively simple needs, and provide a way to hook into arbitrary archivers for those users who need something more powerful. -- A.M. Kuchling http://starship.skyport.net/crew/amk/ "I thought you could foretell the future?" "I don't need to know the future. When the future's over, then it's me..." -- Orpheus and Death, in SANDMAN: "The Song of Orpheus" From claw@under.engr.sgi.com Tue Jan 26 02:12:59 1999 From: claw@under.engr.sgi.com (J C Lawrence) Date: Mon, 25 Jan 1999 18:12:59 -0800 Subject: [Mailman-Developers] commercial maillist system, lyris, looks rather similar In-Reply-To: Message from Ken Manheimer of "Sat, 23 Jan 1999 12:59:12 EST." Message-ID: <199901260212.SAA33406@under.engr.sgi.com> On Sat, 23 Jan 1999 12:59:12 -0500 (EST) Ken Manheimer wrote: > I just heard mention of a commercial mailling list manager, lyris, > that upon a tiny bit of investigation looks similar in some ways > to mailman - eg, the admin interface layout: Aye, and a very brag happy set of PR staff that rather got my dander up. > (listinfo?), the orientation on web interfaces, "automatic error > handling" (bounce handling), built-in archives, built-in mail > engine (for "blinding speed"), etc. From poking around a little, > it looks like they use perl at least as an extension language - i > wonder how it's built. Monolithic on top of an DBC-accessable database (C++ strongly rumoured), runs its own SMTP server/MTA, all archive/message access is via dynamic database queries, etc. > I'm pretty curious how long it's been around - they claim that: At least 4 years, probably more. > "Lyris was the first email list server to offer a web > interface for list administrators and members." Utter codswhallop, but there's nobody with money to argue. > No more "get me off this list!" messages. > on the lyris "about" page (http://www.lyris.com/about.html), , > framed as "failsafe unsubscribing" - i think i saw this phrase in > a recent mailman-users posting, i would not be surprised if the > poster saw it there...) They do this by posting a per-user unsubscribe address on EVERY message (single message with optional unique MessageID per message) sent to each subscriber. Thus, for isntance, every message you get from a Lyris based list will have a trailer ala: To unsuscribe from this list send a message to listname-unsubscribe-817689161263@domain with the above text having a unique and different address (seemingly random string of digits hashed from your subscription ID) for everybody who receives the posting (yup, no RCPT TO bundling). As a member you then just email that address to unsubscribe. -- J C Lawrence Internet: claw@kanga.nu (Contractor) Internet: coder@kanga.nu ---------(*) Internet: claw@under.engr.sgi.com ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From claw@under.engr.sgi.com Tue Jan 26 02:16:49 1999 From: claw@under.engr.sgi.com (J C Lawrence) Date: Mon, 25 Jan 1999 18:16:49 -0800 Subject: [Mailman-Developers] commercial maillist system, lyris, looks rather similar In-Reply-To: Message from Ken Manheimer of "Sat, 23 Jan 1999 12:59:12 EST." Message-ID: <199901260216.SAA33238@under.engr.sgi.com> On Sat, 23 Jan 1999 12:59:12 -0500 (EST) Ken Manheimer wrote: > Wish i had more time to investigate, if anyone does, please report > back... One thing they do have that I really like: You can place members on moderator detention. There are two flavours: 1) Have the next XXX posts from that user require moderator approval. Once they get XXX approvals then they are able to post freely. 2) Ditto to #1, but bounded by time, not count. One thing I really dislike: By default they rewrite the MessageID's on all outbound messages to give a unique MessageID per subscriber. This of course breaks reference threading, dupe checking, etc. This can (finally, it took a very long time) be turned off, but it is on by default and admin interface text is phrased to discourage turning it off. -- J C Lawrence Internet: claw@kanga.nu (Contractor) Internet: coder@kanga.nu ---------(*) Internet: claw@under.engr.sgi.com ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From claw@under.engr.sgi.com Tue Jan 26 02:23:33 1999 From: claw@under.engr.sgi.com (J C Lawrence) Date: Mon, 25 Jan 1999 18:23:33 -0800 Subject: [Mailman-Developers] Archiving using news gateway In-Reply-To: Message from Tomas Fasth of "Sun, 24 Jan 1999 12:49:28 +0100." <36AB08C8.93359F4@euronetics.se> Message-ID: <199901260223.SAA33438@under.engr.sgi.com> On Sun, 24 Jan 1999 12:49:28 +0100 Tomas Fasth wrote: > In "Re: [Mailman-Developers] commercial maillist system, lyris, > looks rather similar" Ken Manheimer wrote: >> It has some nice stuff that mailman doesn't - one interesting >> idea seems to be to use a news server for the archives. That >> way, archive browsers can use a news interface, or use a web >> browser to a news/web gateway. > Interesting approach. That is surely a possible workaround for the > current lack of MIME support in pipermail archiving. As a matter > of fact, I like the idea so much that I will give it a try. It has a problem: lack of good search facilities. HTML or database based list archives allow useful/intelligent search engines to be used to process them. eg I have roughly 40,000 messages up and HTML-iesed via MHonArc and indexed via WebGlimpse. Its an utter bitch to find anything without WebGlimpse. > So I guess the archive-through-news approach will work in most > cases. > Comments? Its a good option. Mostly I just want an MH-style folder for each quarter's (I operate on quarter's worth of messages, not months). -- J C Lawrence Internet: claw@kanga.nu (Contractor) Internet: coder@kanga.nu ---------(*) Internet: claw@under.engr.sgi.com ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From david@topware.com.tw Wed Jan 27 14:48:21 1999 From: david@topware.com.tw (David Li) Date: Wed, 27 Jan 1999 22:48:21 +0800 Subject: [Mailman-Developers] Localization? Message-ID: <36AF2735.FC6B05B@topware.com.tw> Hi, I recently discover mailman and it has been a great tool. However, because of the user of my mailing lists are mainly Chinese, I need to localize all message. Is there build-in support for locatilization in mailman? If not, is there a plan to develop one? The lack of localization makes it painful to track the prograss of mailman. Thanks. David Li david@topware.com.tw From david@topware.com.tw Wed Jan 27 15:12:22 1999 From: david@topware.com.tw (David Li) Date: Wed, 27 Jan 1999 23:12:22 +0800 Subject: [Mailman-Developers] Localization, a proposal... Message-ID: <36AF2CD6.73ABC6ED@topware.com.tw> I have a couple suggestions for supporting localization. 1. Add locale setting for mailing list. 2. In the template library, add support for locale in terms of directory. Thus, the default files for locale C will be under templates/C and for locale zh_TW.Big5 will be under templates/zh_TW.Big5. 3. Add support for locale in the in the 'maketext' method of Mailman/Utils.py, add the search capacity so it search the file first in the lists/mailinglist, then templates/LOCALE and then templates/C. From Harald.Meland@usit.uio.no Thu Jan 28 14:07:00 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 28 Jan 1999 15:07:00 +0100 Subject: [Mailman-Developers] (Maybe) wrong permissions on archives/private/listname/database Message-ID: First of all: This problem could be occuring because I have messed things up by not being consistent in the way I upgrade Mailman. I have, from time to time, run "make install" and "make update" as root, mailman or myself. Yeah, I'm not the most organized person in the world, I know. :) Anyway: My Mailman is configured like this: ./configure --prefix=/local/Mailman --without-gcc \ --with-python=/local/bin/python --with-cgi-gid=nobody \ --with-mail-gid=mailman My MTA pipes all the mailman stuff into /local/Mailman/mail/wrapper, running as the user "mailman" (which has default group "mailman"). For some of my lists, I have this situation: $ ls -l archives/private/LISTNAME/ total 20 drwxrwsr-x 2 nobody mailman 512 Dec 1 16:51 1998-December -rw-rw-r-- 1 nobody mailman 939 Dec 1 16:51 1998-December.txt drwxrwsrwx 2 nobody mailman 512 Nov 13 18:26 1998-November -rw-rw-rw- 1 nobody mailman 2663 Nov 23 15:32 1998-November.txt drwxrwsrwx 2 nobody mailman 512 Oct 29 15:18 1998-October -rw-rw-rw- 1 nobody mailman 2898 Oct 29 15:18 1998-October.txt drwxrwsr-x 2 nobody mailman 512 Jan 19 14:03 1999-January -rw-rw-r-- 1 nobody mailman 2573 Jan 19 14:03 1999-January.txt drwx--S--- 2 nobody mailman 2048 Jan 19 14:03 database -rw-rw-rw- 1 nobody mailman 2246 Jan 19 14:03 index.html -rw-rw-rw- 1 nobody mailman 555 Jan 19 14:03 pipermail.pck Are the permissions/owner on the "database" directory good? Why are some of the files world writable? For some other lists, which seem to have set very similar archival options to the list above, the owner of the "database" directory are: drwx--S--- 2 mailman mailman 1536 Jan 26 14:41 database or drwxrws--- 2 nobody mailman 1536 Jan 20 00:07 database I suppose pipermail is running as user/group "mailman" when it does it's job, and that pipermail not getting access to the "database" directory is a bad thing, right? Whenever I run "make update" as non-root, I get some warnings of the type: /local/gnu/bin/install: /local/Mailman/Mailman/pythonlib/getpass.py: Permission denied Compiling /local/Mailman/Mailman/Archiver/Archiver.py ... Sorry: IOError: (13, 'Permission denied') (which I now have fixed by chowning the necessary files/directories), and then some like this: Listing /local/Mailman/archives/private/LISTNAME/database ... Can't list /local/Mailman/archives/private/LISTNAME/database (which I'm not sure how to, or even *if*I*should*, fix). So, should "make update" scream louder/suggest manual interaction when it discovers anomalies like this? Should there (somewhere) be a warning about not varying what user you run "make install" and "make update" as? And shouldn't "make update" (or something) revoke those scary world writable permission bits? -- Harald From benfati@zzp.com.br Thu Jan 28 18:59:28 1999 From: benfati@zzp.com.br (Jose Carlos Benfati) Date: Thu, 28 Jan 1999 16:59:28 -0200 (EDT) Subject: [Mailman-Developers] thousands of subscribers Message-ID: Hello, I'm considering installing mailman to serve some very big lists. The biggest has more than 25000 members. Is there any restriction in mailman (like hardcoded values) that could cause me problems? Do you recommend mailman for that? thanks a lot. Jose Carlos Benfati ZZP Consultoria http://zzp.com.br From julian7@kva.hu Fri Jan 29 08:57:22 1999 From: julian7@kva.hu (Balazs Nagy) Date: Fri, 29 Jan 1999 09:57:22 +0100 (CET) Subject: [Mailman-Developers] Big lists Message-ID: Hiyas, How can I (we) set up mailman to handle big (with 25k or more subscribers) lists? I mean it would be nice if Mailman sent some mail to a distribution server which sent the same letter to a subset of subscribers. It can lower heavily the outgoing traffic. Regards: Balazs -- #!/usr/bin/perl -export-a-crypto-system-sig -http://dcs.ex.ac.uk/~aba/rsa print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0 Message-ID: Jose Carlos Benfati writes: > Hello, > > I'm considering installing mailman to serve some very big lists. The > biggest has more than 25000 members. One thing is the subscriber list, visible for subscribers themselves. It is linear, everything on one page and doesn't work well for 25000 members. Another thing is the digest format which triggers a sendmail MIME bug. Be sure to have sendmail 8.9.1 or newer, otherwise you site will explode. :) Even if your sendmail works, you're going to get annoyed messages from administrators of other sites who have an older sendmail dumping core because of your digests. These are my experiences with a list of about 1000 members. Otherwise, things have been running quite well. Load of the mailing list administrator is still quite high, because we use a strict filter catching all MIME and HTML messages. -- Janne From bwarsaw@python.org Fri Jan 29 17:16:48 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Fri, 29 Jan 1999 12:16:48 -0500 (EST) Subject: [Mailman-Developers] Re: Please stop the cross posting References: <36B1E948.42CE8FE3@appliedbiometrics.com> Message-ID: <14001.60672.211755.185830@anthem.cnri.reston.va.us> >>>>> "CT" == Christian Tismer writes: CT> I will also propose to change Mailman to handle this CT> in a better way. My own patched version on Starship CT> never prepends the list name if it can be matched in the CT> "re" already. I thought Mailman already does this too. I'll double check. Chris, you might want to send your patches to mailman-developers@python.org -Barry From tismer@appliedbiometrics.com Fri Jan 29 17:29:28 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Fri, 29 Jan 1999 18:29:28 +0100 Subject: [Mailman-Developers] Re: Please stop the cross posting References: <36B1E948.42CE8FE3@appliedbiometrics.com> <14001.60672.211755.185830@anthem.cnri.reston.va.us> Message-ID: <36B1EFF8.FC755D60@appliedbiometrics.com> Barry A. Warsaw wrote: > > >>>>> "CT" == Christian Tismer writes: > > CT> I will also propose to change Mailman to handle this > CT> in a better way. My own patched version on Starship > CT> never prepends the list name if it can be matched in the > CT> "re" already. > > I thought Mailman already does this too. I'll double check. Chris, > you might want to send your patches to mailman-developers@python.org Well, these patches were for a very old Mailman. I don't know wether they still apply. But the idea is simple. Only prepend the prefix if you cannot string.find it. From maillist.py (V0.95): # Prepend the subject_prefix to the subject line. subj = msg.getheader('subject') prefix = self.subject_prefix if prefix: prefix = prefix + ' ' if not subj: msg.SetHeader('Subject', '%s(no subject)' % prefix) else: #CT begin #CT adding only if not already present if string.find(subj, prefix) < 0: msg.SetHeader('Subject', '%s%s' % (prefix, subj)) #CT end dont_send_to_sender = 0 ack_post = 0 -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.skyport.net 10553 Berlin : PGP key -> http://pgp.ai.mit.edu/ we're tired of banana software - shipped green, ripens at home From tismer@appliedbiometrics.com Fri Jan 29 17:36:13 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Fri, 29 Jan 1999 18:36:13 +0100 Subject: [Mailman-Developers] Re: Please stop the cross posting References: <36B1E948.42CE8FE3@appliedbiometrics.com> <14001.60672.211755.185830@anthem.cnri.reston.va.us> Message-ID: <36B1F18D.39BA7539@appliedbiometrics.com> Barry A. Warsaw wrote: > > >>>>> "CT" == Christian Tismer writes: > > CT> I will also propose to change Mailman to handle this > CT> in a better way. My own patched version on Starship > CT> never prepends the list name if it can be matched in the > CT> "re" already. > > I thought Mailman already does this too. I'll double check. Chris, > you might want to send your patches to mailman-developers@python.org Well, I had a look: New Mailman does this: prefix = self.subject_prefix if not subj: msg.SetHeader('Subject', '%s(no subject)' % prefix) elif not re.match("(re:? *)?" + re.escape(self.subject_prefix), subj, re.I): msg.SetHeader('Subject', '%s%s' % (prefix, subj)) if self.anonymous_list: This is insufficient for cross-posts which are replied to from a different list. I think my string.find approach is crude, simple, but exactly the right thing. Forget about seldom possible missing prefixes... ciao - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.skyport.net 10553 Berlin : PGP key -> http://pgp.ai.mit.edu/ we're tired of banana software - shipped green, ripens at home From petrilli@amber.org Fri Jan 29 17:40:42 1999 From: petrilli@amber.org (Christopher G. Petrilli) Date: Fri, 29 Jan 1999 12:40:42 -0500 Subject: [Mailman-Developers] Re: Please stop the cross posting In-Reply-To: <36B1EFF8.FC755D60@appliedbiometrics.com>; from Christian Tismer on Fri, Jan 29, 1999 at 06:29:28PM +0100 References: <36B1E948.42CE8FE3@appliedbiometrics.com> <14001.60672.211755.185830@anthem.cnri.reston.va.us> <36B1EFF8.FC755D60@appliedbiometrics.com> Message-ID: <19990129124042.14584@amber.org> On Fri, Jan 29, 1999 at 06:29:28PM +0100, Christian Tismer wrote: > Barry A. Warsaw wrote: > > > > >>>>> "CT" == Christian Tismer writes: > > > > CT> I will also propose to change Mailman to handle this > > CT> in a better way. My own patched version on Starship > > CT> never prepends the list name if it can be matched in the > > CT> "re" already. > > > > I thought Mailman already does this too. I'll double check. Chris, > > you might want to send your patches to mailman-developers@python.org > > Well, these patches were for a very old Mailman. I don't know > wether they still apply. But the idea is simple. Only prepend > the prefix if you cannot string.find it. > Hmm, would anyone else be interested in the option to "merge" x-posted mailings... what I guess I mean is that I'm on a bunch of python.org lists, and when things get crossposted, I get like 400 copies of each message... it'd be nice to figure out a way to only get ONE copy :-) Chris -- | Christopher Petrilli | petrilli@amber.org From ken@digicool.com Fri Jan 29 17:59:02 1999 From: ken@digicool.com (Ken Manheimer) Date: Fri, 29 Jan 1999 12:59:02 -0500 (EST) Subject: [Mailman-Developers] Re: Please stop the cross posting In-Reply-To: <36B1EFF8.FC755D60@appliedbiometrics.com> Message-ID: (Proper handling of the subject line prefix was one of the first things i did - i'm pretty sure it was before 1.0b3, maybe 1.0b1. If i recall correctly, i implemented a slightly more stringent strategy, only looking for the prefix early on in the subject line, after "re:"'s, but before other text. I know it takes care of the vast majority of cases, and i suspect it's preferable more of the time in offbeat cases than looking for the prefix anywhere in the subject line, but i may be wrong. I didn't see the original post - still sorting out environment and email - so i'm not sure about the specific case being discussed...) Ken On Fri, 29 Jan 1999, Christian Tismer wrote: > Barry A. Warsaw wrote: > > > > >>>>> "CT" == Christian Tismer writes: > > > > CT> I will also propose to change Mailman to handle this > > CT> in a better way. My own patched version on Starship > > CT> never prepends the list name if it can be matched in the > > CT> "re" already. > > > > I thought Mailman already does this too. I'll double check. Chris, > > you might want to send your patches to mailman-developers@python.org > > Well, these patches were for a very old Mailman. I don't know > wether they still apply. But the idea is simple. Only prepend > the prefix if you cannot string.find it. From ken@digicool.com Fri Jan 29 18:01:25 1999 From: ken@digicool.com (Ken Manheimer) Date: Fri, 29 Jan 1999 13:01:25 -0500 (EST) Subject: [Mailman-Developers] Re: Please stop the cross posting In-Reply-To: <36B1F18D.39BA7539@appliedbiometrics.com> Message-ID: > This is insufficient for cross-posts which are replied to > from a different list. > I think my string.find approach is crude, simple, but exactly > the right thing. Forget about seldom possible missing prefixes... You're probably right - the simpler approach would prevent alternation across lists from compounding the respective prefixes. (Though the idea of messages alternating from list to list gives me the willies, but that's besides the point...-) Ken From ken@digicool.com Fri Jan 29 18:05:33 1999 From: ken@digicool.com (Ken Manheimer) Date: Fri, 29 Jan 1999 13:05:33 -0500 (EST) Subject: [Mailman-Developers] Re: Please stop the cross posting In-Reply-To: <19990129124042.14584@amber.org> Message-ID: On Fri, 29 Jan 1999, Christopher G. Petrilli wrote: > Hmm, would anyone else be interested in the option to "merge" x-posted > mailings... what I guess I mean is that I'm on a bunch of python.org > lists, and when things get crossposted, I get like 400 copies of each > message... it'd be nice to figure out a way to only get ONE copy :-) This would be one reason to have an object database to keep track of what gets posted where. I think this sort of thing is likely in a new architecture for mailman, using and as components for a zope framework. (An issue here is whether zope's new relaxation of the attribution requirement, and Open Source certification, will satisfy stallman for gnu-yness - if so, it'd make it easy to integrate mailma and zope more closely, exploit bobopos/zopepos, etc.) Ken From tismer@appliedbiometrics.com Fri Jan 29 18:24:21 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Fri, 29 Jan 1999 19:24:21 +0100 Subject: [Mailman-Developers] Re: Please stop the cross posting References: Message-ID: <36B1FCD5.EDACFFAC@appliedbiometrics.com> Ken Manheimer wrote: > > > This is insufficient for cross-posts which are replied to > > from a different list. > > I think my string.find approach is crude, simple, but exactly > > the right thing. Forget about seldom possible missing prefixes... > > You're probably right - the simpler approach would prevent alternation > across lists from compounding the respective prefixes. (Though the idea > of messages alternating from list to list gives me the willies, but that's > besides the point...-) It basically appeared to me as bad manners to reply to cross-posted messages in a zig-zag. On the other hand, if somebody is really on one list and not on the other, this is the only way that works. That thread on XML/Zope sigs became really unreadable since prefixes piled up. It seems to be hard to tackle this in a more intelligent way. Ok, we can prevend prefixes from stacking. But the bigger problem which hurts at the same time (See Chris Petrilli's message) is that you get these crossposted things twice, also. I don't see an easy way to avoid this when cross posting is allowed. One way would be this: When Mailman receives a post, it can see all the recipients, especially it can see its own hostname, with different mailing lists. Unfortunately, the receiving process will duplicate the message and send it to the different aliases, one for each list. To capture this, sendmail must be intercepted by something like procmail (just as an example) which first makes sure that only one list gets that message. The one list which receives the message now reads the recipient list, and temporarily merges the user lists of the mentioned mailing lists into one. This could make sure that you don't get a duplicate message. How about that? - ciao - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.skyport.net 10553 Berlin : PGP key -> http://pgp.ai.mit.edu/ we're tired of banana software - shipped green, ripens at home From petrilli@amber.org Fri Jan 29 18:34:49 1999 From: petrilli@amber.org (Christopher G. Petrilli) Date: Fri, 29 Jan 1999 13:34:49 -0500 Subject: [Mailman-Developers] Re: Please stop the cross posting In-Reply-To: <36B1FCD5.EDACFFAC@appliedbiometrics.com>; from Christian Tismer on Fri, Jan 29, 1999 at 07:24:21PM +0100 References: <36B1FCD5.EDACFFAC@appliedbiometrics.com> Message-ID: <19990129133449.31890@amber.org> On Fri, Jan 29, 1999 at 07:24:21PM +0100, Christian Tismer wrote: > > You're probably right - the simpler approach would prevent alternation > > across lists from compounding the respective prefixes. (Though the idea > > of messages alternating from list to list gives me the willies, but that's > > besides the point...-) > > It basically appeared to me as bad manners to reply to > cross-posted messages in a zig-zag. On the other hand, if somebody > is really on one list and not on the other, this is the only > way that works. That thread on XML/Zope sigs became really > unreadable since prefixes piled up. I'm sure I was partially to blame for that one, unfortunately it's easy to get confused, plus sometimes I get them in different orders, and I usually respond to the first example :-) Oh well, the human brain works in mysterious and lousy ways. > It seems to be hard to tackle this in a more intelligent way. > Ok, we can prevend prefixes from stacking. > But the bigger problem which hurts at the same time (See > Chris Petrilli's message) is that you get these crossposted > things twice, also. Also, I think it should be possible to prevent xposts period... At least if the lists are hosted on the same machine... or maybe even an ability to define lists that aren't allowed to be xpoststed to... I dunno, this needs to be thought out more. I have some ideas about how to restructure the mailing list delivery stuff so that it will not send out multiple copies to the same person through different lists. > I don't see an easy way to avoid this when cross posting is allowed. > One way would be this: > > When Mailman receives a post, it can see all the recipients, > especially it can see its own hostname, with different > mailing lists. Unfortunately, the receiving process will > duplicate the message and send it to the different aliases, > one for each list. To capture this, sendmail must be intercepted > by something like procmail (just as an example) which first makes > sure that only one list gets that message. I don't think this belongs in the MTA, it belongs in the mailing list manager... but that's just me... Also, remember that a lot of us (myself for example) don't use Sendmail any more... > The one list which receives the message now reads the recipient > list, and temporarily merges the user lists of the mentioned > mailing lists into one. This could make sure that you don't > get a duplicate message. Hmm... I'll try and write down my ideas for a more hmm, "elegant" solution, at least in my mind... think garbage collection, it's a bizarre premise, but... Basically, you have a list of all recipients on all lists merged together, you then have a list of messages that need to be delivered to recipients with certain interests... you can then attach this message object to all the recipients (via whatever method), thereby determining whether or not the recipient will already be receiving the message. I've written (a long time ago) a Usenet server that worked on a similar principle... was quite quick, and very effecient. It was in C, but I can't imagine that it should be that hard in Python... this is NOT a Mailman 1.x exercise :-) Chris -- | Christopher Petrilli | petrilli@amber.org From ken@digicool.com Fri Jan 29 18:40:50 1999 From: ken@digicool.com (Ken Manheimer) Date: Fri, 29 Jan 1999 13:40:50 -0500 (EST) Subject: [Mailman-Developers] Re: Please stop the cross posting In-Reply-To: <36B1FCD5.EDACFFAC@appliedbiometrics.com> Message-ID: [... regarding compounding subject prefixes in cross-posted maillist messages, and more generally avoiding duplication of cross posts ...] On Fri, 29 Jan 1999, Christian Tismer wrote: > It seems to be hard to tackle this in a more intelligent way. > Ok, we can prevent prefixes from stacking. > But the bigger problem which hurts at the same time (See > Chris Petrilli's message) is that you get these crossposted > things twice, also. > > I don't see an easy way to avoid this when cross posting is allowed. > One way would be this: Offhand, there seem to me to be two key items here: - mailman can unequivocally identify the message id and the recipients of members of any lists which it is serving on the same host, so given a decent architecture (modularized message flow tracking db) it should be easy to provide users the option to inhibit receiving more than the first copy of a cross posted message - this issue does not seem critical enough to retrofit it to the existing architecture (which does virtually no flow tracking, certainly not across lists), at least not compared to the various rough edges that currently need to be polished off (eg, subscription delivery address changing without un/resubscribe, better implementation of admin pending items, lots of other stuff.) > When Mailman receives a post, it can see all the recipients, > especially it can see its own hostname, with different > mailing lists. Unfortunately, the receiving process will > duplicate the message and send it to the different aliases, > one for each list. To capture this, sendmail must be intercepted > by something like procmail (just as an example) which first makes > sure that only one list gets that message. Um, it doesn't make sense to go external when all the info is available internally to mailman as a whole! Instead, the internal infrastructure needs to be developed - something that should go on the list for modular mailman, or whatever it'll be... Ken From ken@digicool.com Fri Jan 29 18:47:21 1999 From: ken@digicool.com (Ken Manheimer) Date: Fri, 29 Jan 1999 13:47:21 -0500 (EST) Subject: [Mailman-Developers] Re: Please stop the cross posting In-Reply-To: <19990129133449.31890@amber.org> Message-ID: On Fri, 29 Jan 1999, Christopher G. Petrilli wrote: > Basically, you have a list of all recipients on all lists merged > together, you then have a list of messages that need to be delivered to > recipients with certain interests... you can then attach this message > object to all the recipients (via whatever method), thereby determining > whether or not the recipient will already be receiving the message. > > I've written (a long time ago) a Usenet server that worked on a similar > principle... was quite quick, and very effecient. It was in C, but I > can't imagine that it should be that hard in Python... this is NOT a > Mailman 1.x exercise :-) I don't think it's a hard problem, and i agree, i don't think it's high enough priority to retrofit to 1.x. If there's sufficient mandate (read, incentives for digital creations) for mailman and zope to exploit on eachother's capabilities, we may be able to spend some time tailoring them for eachother a bit, avoiding locking mailman to zope, but strengthing mailman where zope is available... Exciting prospects, and i actually think there will be the mandate. Got a lot to do before then, though, so don't hold your breath. (BTW, ironically, i've been tempted to post my messages in this to the zope list!-) Ken From rocon@pivot.net Fri Jan 29 18:45:11 1999 From: rocon@pivot.net (Robert OConnor) Date: Fri, 29 Jan 1999 13:45:11 -0500 Subject: [Mailman-Developers] Forward e-mail fix needed Message-ID: <004501be4bb8$0862a220$0201a8c0@hawkeye.bob.oc> Hi mailmen, I am subscribed to the zope.org list and when I subscribed, I could not use my forwarded email address from my domain bob@rocnet.com Instead, I had to use my ISP address rocon@pivot.net. When I used the forwarded address, I was subscribed and confirmed but never see my posts on the list come back as a post. Thank you. -bobo connor From petrilli@amber.org Fri Jan 29 18:57:17 1999 From: petrilli@amber.org (Christopher G. Petrilli) Date: Fri, 29 Jan 1999 13:57:17 -0500 Subject: [Mailman-Developers] Re: Please stop the cross posting In-Reply-To: ; from Ken Manheimer on Fri, Jan 29, 1999 at 01:47:21PM -0500 References: <19990129133449.31890@amber.org> Message-ID: <19990129135717.59463@amber.org> On Fri, Jan 29, 1999 at 01:47:21PM -0500, Ken Manheimer wrote: > On Fri, 29 Jan 1999, Christopher G. Petrilli wrote: > > > [I propose some half-baked thoughts about object relationships] > I don't think it's a hard problem, and i agree, i don't think it's high > enough priority to retrofit to 1.x. If there's sufficient mandate (read, > incentives for digital creations) for mailman and zope to exploit on > eachother's capabilities, we may be able to spend some time tailoring them > for eachother a bit, avoiding locking mailman to zope, but strengthing > mailman where zope is available... Exciting prospects, and i actually > think there will be the mandate. Got a lot to do before then, though, so > don't hold your breath. > Well, given all the licensing things not being resolved yet, these are just hypothetical ideas... well, real ideas with hypothetical probability! What I see is this... not Mailmain as part of Zope, but a parallel "application" on top of the Zbase... this of course depends on the new ideas proposed by Jim for BoboPOS3, ney Zbase 3? Zope could then be used to provide a management interface to the mailing-list "publisher" that works off the same database. I don't know... hmm... it's all so complex! :-) I'm going to sit down and think through the object-model that would be necessary for this, maybe whip out a few UML models to put it down on virtual paper... assuming I remember all my modeling theory! ;-) One idea, and I don't know how feasible it is at THIS point, is to use ZPublisher as the basis for a new management interface, and then wrap that up in such a way as to allow it to be Productized for Zope so someone could just plug the interface in anywhere they want :-) > (BTW, ironically, i've been tempted to post my messages in this to the > zope list!-) No no, not at this point anyway... I'm new to this whole thign anyway, so maybe I'm just wacko and thinking of things that have been hased out to death already. Chris -- | Christopher Petrilli | petrilli@amber.org From jeff@ollie.clive.ia.us Fri Jan 29 19:26:46 1999 From: jeff@ollie.clive.ia.us (Jeffrey C. Ollie) Date: Fri, 29 Jan 1999 13:26:46 -0600 Subject: [Mailman-Developers] Limiting copies of cross posts sent Message-ID: <36B20B76.9D9955B0@ollie.clive.ia.us> This is a cryptographically signed message in MIME format. --------------ms6F55531ACE1126FB6C6E561C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here's one idea for limiting the number of messages sent when a message is cross-posted to multiple lists. I haven't actually tried implementing this idea yet so it may be impractical. The nice thing that I like about this method is that it doesn't require that a database of message-ids be kept. Ok, here's the idea: SMTP allows for multiple recipients to be specified for any message sent. A typical conversation would look something like this (apologies if my mailer wraps the lines): 220 python.org ESMTP Sendmail 8.9.1a/8.9.1 (klm); Fri, 29 Jan 1999 14:15:14 -0500 (EST) HELO max.ollie.clive.ia.us 250 python.org Hello IDENT:jcollie@max.ollie.clive.ia.us [161.210.214.102], pleased to meet you MAIL From: 250 ... Sender ok RCPT To: 250 ... Recipient ok RCPT To: 250 ... Recipient ok DATA 354 Enter mail, end with "." on a line by itself . 250 OAA18072 Message accepted for delivery Now, if you can get the SMTP daemon to invoke MailMan once and pass all of the recipients, MailMan could use that information to send one copy of the message to the union of the set of subscribers for each list. Of course MailMan would need to be changed significantly to handle this, but you wouldn't need a database. Jeff --------------ms6F55531ACE1126FB6C6E561C Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIJ6AYJKoZIhvcNAQcCoIIJ2TCCCdUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B3QwggQ+MIIDp6ADAgECAhAH45KMD5ppjHBDd8plU0arMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk4MTAwMjAwMDAw MFoXDTk5MTAwMjIzNTk1OVowggEWMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxFjAUBgNVBAMUDUplZmZyZXkgT2xsaWUxJTAjBgkqhkiG 9w0BCQEWFmplZmZAb2xsaWUuY2xpdmUuaWEudXMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALznR/JfeMFeOL38y5n0N48TKu+pvfHuCa4mNMTl0/Im7S+rqGMc33+8SkjTUAik31nq iCNV2rSkcoegAkl3Ap0R5vEavmBA+v3PKKoDtl4jlhItCUlFxYqTMZ/sv43NbJ7O8EzJNs4s gcG4uqMqLcY4ASjpIdDk+Uy75j7kW+VHAgMBAAGjgdMwgdAwCQYDVR0TBAIwADCBrwYDVR0g BIGnMIAwgAYLYIZIAYb4RQEHAQEwgDAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNp Z24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlT aWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNp Z24AAAAAAAAwEQYJYIZIAYb4QgEBBAQDAgeAMA0GCSqGSIb3DQEBBAUAA4GBAEPk6HE6JHjs dKTRSz5YCSD5mj1zzeTo0MMWPB17NuUvssI6iCndVzzVxgwfsRGymWjTv6wijb0NlZ4HpkKW WY5v34W3775MLT+dO5N854iJJ6l5Ym2RVUPkkwGyCKElMoO6ds67fTIj/2u2ZjURZtzxoMwb ZFA+s6XT1rNEcZRsMIIDLjCCApegAwIBAgIRANJ2Lo0UDD19sqglXa/uDXUwDQYJKoZIhvcN AQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQL Ey5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4 MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNp Z24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgw RgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJz b25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV /QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC 8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+ 78nbN2rISsgJBuSZAgMBAAGjfDB6MBEGCWCGSAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwG C2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEA iLg3O93alDcAraqf4YEBcR6Sam0v9vGd08pkONwbmAwHhluFFWoPuUmFpJXxF31ntH8tLN2a Qp7DPrSOquULBt7yVir6M8e+GddTTMO9yOMXtaRJQmPswqYXD11YGkk8kFxVo2UgAP0YIOVf gqaxqJLFWGrBjQM868PNBaKQrm4xggI8MIICOAIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3 dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFRE KGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3Jp YmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQB+OSjA+aaYxwQ3fKZVNGqzAJBgUrDgMCGgUA oIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk5MDEyOTE5 MjY0N1owIwYJKoZIhvcNAQkEMRYEFFWP57GZ4isjuf45nfhh1dOCmpqvMFIGCSqGSIb3DQEJ DzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAtwP2TeO8JLOiXMCY3U5PU81V eYGun8xKS8vkYRTh2WC0xpXeRKxM0cv/TXz4VVTLRtRsWqjXpucjxcSHyNh+byqPIsGBv/Nv gAp6KvN6l55M1IKFFtOAS/kfoiWKOvsGvLtdKny+ElCkYPxVt+Fv2IYolyz2cdsbbbxbyeyE 5jE= --------------ms6F55531ACE1126FB6C6E561C-- From tismer@appliedbiometrics.com Fri Jan 29 19:25:19 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Fri, 29 Jan 1999 20:25:19 +0100 Subject: [Mailman-Developers] Re: Please stop the cross posting References: Message-ID: <36B20B1F.87887A7F@appliedbiometrics.com> (Ken) > Offhand, there seem to me to be two key items here: > > - mailman can unequivocally identify the message id and the recipients of > members of any lists which it is serving on the same host, so given a > decent architecture (modularized message flow tracking db) it should be > easy to provide users the option to inhibit receiving more than the > first copy of a cross posted message Well, I forgot about that. This makes it of course easy. > Um, it doesn't make sense to go external when all the info is available > internally to mailman as a whole! Instead, the internal infrastructure > needs to be developed - something that should go on the list for modular > mailman, or whatever it'll be... Of course! For me, identifying the message was the problem, but I should have known better. And instead of waiting for a new Mailman generation, I see that this problem has two sides: A message appears to have always an ID which is generated by the email program (not sure if that is guaranteed, but very likely). That means one could set up the sendmail (qmail, whatever) configuration in a way that it checks the incoming mail for duplicate IDs. This would also work for cross-postings to different Mailman sites. Having both would be perfect and would save bandwidth, but one suffices to yield the desired effect. Should I try to write a little filter which keeps track of message IDs for a short period, and drops those already seen? This would be a small Python tool for the email client side, not touching Mailman at all. Looks quite practical to me. ciao - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.skyport.net 10553 Berlin : PGP key -> http://pgp.ai.mit.edu/ we're tired of banana software - shipped green, ripens at home From petrilli@amber.org Fri Jan 29 19:35:09 1999 From: petrilli@amber.org (Christopher G. Petrilli) Date: Fri, 29 Jan 1999 14:35:09 -0500 Subject: [Mailman-Developers] Object ideas for duplicate supression Message-ID: <19990129143509.10781@amber.org> yeah yeah, I know ... it's me again... here's some ideas for Mailman2, and note these objects could be stored in a nice fancy object database :-) ---- ramblings begin Ok, here's the 5 minute concept... think of it as modeling-light. Two types of objects: * List object * Subscriber object There is a many-many relationship between Lists and Subscribers, meaning obviously that Lists can contain many subscribers, and Subscribers can contain many lists. This creates a concern for clean-up given circular references. Need to think through this.[1] Now, the best way to understand this is to deal with a message coming in, and how does it get exploded into the subscribers necessary: First, you know who the mailer sent it to (say listA), but then you parse through the To:/CC: headers looking for other lists, making a note of them. If there are no other lists (local lists, not remote lists) identified then proceed with the normal delivery, no reason here to compare Message-Id: with those stored. However, if another local list is discovered (listB) then duplicate-supression should be run. What this requires is exploding the message into all of its subscribers, and matching that with the subscribers of listB, if no overlap, short-circuit to normal delivery. But, if you do have overlap, then for each overlap, check the subscribers 'recent-ids' attribute for the current message's attribute, if it doesn't exist, append it, and send the message out. If it does exist, delete the recipient from the list passed to the MTA. Seems simple, though I'm sure I've glossed over a billion and one things. --- Footnotes [1] This can probable be fixed by making sure that you break the link manually rather than depending on garbage collection. Or maybe weak lists? When you delete a list, scan the subscribers, looking for reverse links, and break them, then you delete the list. Same thing for the deletion of a subscriber. -- | Christopher Petrilli | petrilli@amber.org From petrilli@amber.org Fri Jan 29 19:45:16 1999 From: petrilli@amber.org (Christopher G. Petrilli) Date: Fri, 29 Jan 1999 14:45:16 -0500 Subject: [Mailman-Developers] Limiting copies of cross posts sent In-Reply-To: <36B20B76.9D9955B0@ollie.clive.ia.us>; from Jeffrey C. Ollie on Fri, Jan 29, 1999 at 01:26:46PM -0600 References: <36B20B76.9D9955B0@ollie.clive.ia.us> Message-ID: <19990129144516.52367@amber.org> On Fri, Jan 29, 1999 at 01:26:46PM -0600, Jeffrey C. Ollie wrote: > > Now, if you can get the SMTP daemon to invoke MailMan once and pass all > of the recipients, MailMan could use that information to send one copy > of the message to the union of the set of subscribers for each list. > Having just spent gods know how much time hacking up sendmail, this is a problem... here's why.. * Sendmail only does this under SMTP, not under anything else So, that means that Mailman would have to accept its messages over SMTP, which sin't in itself a problem... the problem is that as far as I've been able to determine, sendmail can't be told to deliver SMTP mail to a different port than 25. Also, you'd end up with mailer re-write rules out the ying-yang :-) Trust me, you never ever ever ever want to do anything that requires someone to add anything bizarre to their sendmail installation. > Of course MailMan would need to be changed significantly to handle this, > but you wouldn't need a database. That's not nearly as ugly as the problems with doing it ... also it'd be different for every mailer, and quite different in many cases I think. -- | Christopher Petrilli | petrilli@amber.org From darren@jasper.somtel.com Fri Jan 29 20:30:51 1999 From: darren@jasper.somtel.com (Darren Henderson) Date: Fri, 29 Jan 1999 15:30:51 -0500 (EST) Subject: [Mailman-Developers] Re: Please stop the cross posting In-Reply-To: <36B20B1F.87887A7F@appliedbiometrics.com> Message-ID: On Fri, 29 Jan 1999, Christian Tismer wrote: > A message appears to have always an ID which is generated by > the email program (not sure if that is guaranteed, but very likely). > That means one could set up the sendmail (qmail, whatever) > configuration in a way that it checks the incoming mail for > duplicate IDs. This would also work for cross-postings to different imo this really isn't something that belongs in mailman, you start getting into all kinds of nasty hueristics ... if you belong to two groups and a message is cross posted which group do you favor and give the message too? It just gets worse as you add groups. Do you addresss that by taking the intersection and making it look like it only comes from one address? Do you let each user decide? It would seem better addressed as another list adminisitrator concern. You could help them I suppose, give them the ability to say, "list a and b will not accept crossposts from one another" but generally its probably enough that they gentley remind their users when it occurs excessively. On the user side procmail makes filtering via msgid quite fiesable. I think http://members.xoom.com/procmail/aks-lib/dupcheck.rc will do what you want. ______________________________________________________________________ Darren Henderson darren@jasper.somtel.com Help fight junk e-mail, visit http://www.cauce.org/ From jeff@ollie.clive.ia.us Fri Jan 29 20:46:59 1999 From: jeff@ollie.clive.ia.us (Jeffrey C. Ollie) Date: Fri, 29 Jan 1999 14:46:59 -0600 Subject: [Mailman-Developers] Limiting copies of cross posts sent References: <36B20B76.9D9955B0@ollie.clive.ia.us> <19990129144516.52367@amber.org> Message-ID: <36B21E43.C8DD3DF6@ollie.clive.ia.us> This is a cryptographically signed message in MIME format. --------------ms4965B7C00B6C64A64D8A6244 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Christopher G. Petrilli" wrote: > > On Fri, Jan 29, 1999 at 01:26:46PM -0600, Jeffrey C. Ollie wrote: > > > > Now, if you can get the SMTP daemon to invoke MailMan once and pass all > > of the recipients, MailMan could use that information to send one copy > > of the message to the union of the set of subscribers for each list. > > Having just spent gods know how much time hacking up sendmail, this is a > problem... here's why.. > > * Sendmail only does this under SMTP, not under anything else Not if you add the 'm' flag to the delivery agent. Then sendmail will invoke the delivery agent with multiple recipients specified on the command line. > So, that means that Mailman would have to accept its messages over SMTP, > which sin't in itself a problem... the problem is that as far as I've > been able to determine, sendmail can't be told to deliver SMTP mail to a > different port than 25. Actually you can, see p522 in the 2nd edition of _Sendmail_ (section 30.4.1.2). > Also, you'd end up with mailer re-write rules > out the ying-yang :-) Trust me, you never ever ever ever want to do > anything that requires someone to add anything bizarre to their sendmail > installation. Yeah, that's for sure. We'd want to keep it simple. > > Of course MailMan would need to be changed significantly to handle this, > > but you wouldn't need a database. > > That's not nearly as ugly as the problems with doing it ... also it'd be > different for every mailer, and quite different in many cases I think. Yes, existence of multiple SMTP daemons is a problem in that we'd have to provide documentation on how to modify the configuration for many different daemons. However doesn't this already happen? Aren't sendmail, exim, qmail, or whatever sufficiently different in their implementation that setup is already problematic? Another, more radical idea would be to completely replace the regular SMTP daemon with a SMTP daemon written in Python that integrates directly with MailMan. I've been considering doing that for another, more radical project that I have in mind. The only problem with this is that you have to dedicate a box to running MailMan and there would be some performace issues, but I guess that this would be offset by the ability to run MailMan on a Windows or Mac OS system. The idea of using a database to filter out multiple copies would be problematic for sites that have high volume lists with a large subscriber base. Just think of all of the storage that you'd need! Jeff --------------ms4965B7C00B6C64A64D8A6244 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIJ6AYJKoZIhvcNAQcCoIIJ2TCCCdUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B3QwggQ+MIIDp6ADAgECAhAH45KMD5ppjHBDd8plU0arMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk4MTAwMjAwMDAw MFoXDTk5MTAwMjIzNTk1OVowggEWMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxFjAUBgNVBAMUDUplZmZyZXkgT2xsaWUxJTAjBgkqhkiG 9w0BCQEWFmplZmZAb2xsaWUuY2xpdmUuaWEudXMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALznR/JfeMFeOL38y5n0N48TKu+pvfHuCa4mNMTl0/Im7S+rqGMc33+8SkjTUAik31nq iCNV2rSkcoegAkl3Ap0R5vEavmBA+v3PKKoDtl4jlhItCUlFxYqTMZ/sv43NbJ7O8EzJNs4s gcG4uqMqLcY4ASjpIdDk+Uy75j7kW+VHAgMBAAGjgdMwgdAwCQYDVR0TBAIwADCBrwYDVR0g BIGnMIAwgAYLYIZIAYb4RQEHAQEwgDAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNp Z24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlT aWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNp Z24AAAAAAAAwEQYJYIZIAYb4QgEBBAQDAgeAMA0GCSqGSIb3DQEBBAUAA4GBAEPk6HE6JHjs dKTRSz5YCSD5mj1zzeTo0MMWPB17NuUvssI6iCndVzzVxgwfsRGymWjTv6wijb0NlZ4HpkKW WY5v34W3775MLT+dO5N854iJJ6l5Ym2RVUPkkwGyCKElMoO6ds67fTIj/2u2ZjURZtzxoMwb ZFA+s6XT1rNEcZRsMIIDLjCCApegAwIBAgIRANJ2Lo0UDD19sqglXa/uDXUwDQYJKoZIhvcN AQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQL Ey5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4 MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNp Z24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgw RgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJz b25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV /QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC 8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+ 78nbN2rISsgJBuSZAgMBAAGjfDB6MBEGCWCGSAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwG C2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEA iLg3O93alDcAraqf4YEBcR6Sam0v9vGd08pkONwbmAwHhluFFWoPuUmFpJXxF31ntH8tLN2a Qp7DPrSOquULBt7yVir6M8e+GddTTMO9yOMXtaRJQmPswqYXD11YGkk8kFxVo2UgAP0YIOVf gqaxqJLFWGrBjQM868PNBaKQrm4xggI8MIICOAIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3 dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFRE KGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3Jp YmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQB+OSjA+aaYxwQ3fKZVNGqzAJBgUrDgMCGgUA oIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk5MDEyOTIw NDcwMVowIwYJKoZIhvcNAQkEMRYEFPB5ZKCJLhxQdTLTBAnKyi5b936YMFIGCSqGSIb3DQEJ DzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAMybxYvKJiN2atwifDL5aZ2rP rj5tax0trzRh1B4/Z96/HY4SL3cf9hFgtTHhE/NvDeFLmliPQK4ah/HEUK7nhAS3UL9OFTka 6BF27oNmdv6YXwfuBUBXKpBHubq2jeq9XD7qCRHjc1ZKDHqh5UxdN4wDQlb0UUFVmzHrUFFD IUU= --------------ms4965B7C00B6C64A64D8A6244-- From petrilli@amber.org Fri Jan 29 20:55:25 1999 From: petrilli@amber.org (Christopher G. Petrilli) Date: Fri, 29 Jan 1999 15:55:25 -0500 Subject: [Mailman-Developers] Duplicate supression idea [was: Re: Please stop the cross posting] In-Reply-To: ; from Darren Henderson on Fri, Jan 29, 1999 at 03:30:51PM -0500 References: <36B20B1F.87887A7F@appliedbiometrics.com> Message-ID: <19990129155525.56617@amber.org> On Fri, Jan 29, 1999 at 03:30:51PM -0500, Darren Henderson wrote: > On Fri, 29 Jan 1999, Christian Tismer wrote: > > > [I propose some nefarious plot to undermine all mail systems :-)] > > imo this really isn't something that belongs in mailman, you start getting > into all kinds of nasty hueristics ... if you belong to two groups and a > message is cross posted which group do you favor and give the message too? > It just gets worse as you add groups. Do you addresss that by taking the > intersection and making it look like it only comes from one address? Do > you let each user decide? Well, I figure this isn't THAT hugely common, which of course asks, why do it, but regardless... anyway, the user gets the copy that first shows up in th mailsystem... which basically would be whichever one is listed first in the recipients list from the MTA's perspective. THat's not relevent, underneith it's the same information. You don't munge anything in the headers, you just adjust the recipient list for the outgoing message (RCPT info), and you deal with it again when 2 copies come in again. I don't see any other way to fdo this. Yes you could decide on a per user basis (make duplicate-supression an option, turned on by default, I suppose). > It would seem better addressed as another list adminisitrator concern. You > could help them I suppose, give them the ability to say, "list a and b > will not accept crossposts from one another" but generally its probably > enough that they gentley remind their users when it occurs excessively. I think this is a seperate issue, though obviously related. Sometimes you do want x-posts... sometimes you don't, that should be an option. Just my handwaving Chris -- | Christopher Petrilli | petrilli@amber.org From petrilli@amber.org Fri Jan 29 21:02:54 1999 From: petrilli@amber.org (Christopher G. Petrilli) Date: Fri, 29 Jan 1999 16:02:54 -0500 Subject: [Mailman-Developers] Limiting copies of cross posts sent In-Reply-To: <36B21E43.C8DD3DF6@ollie.clive.ia.us>; from Jeffrey C. Ollie on Fri, Jan 29, 1999 at 02:46:59PM -0600 References: <36B20B76.9D9955B0@ollie.clive.ia.us> <19990129144516.52367@amber.org> <36B21E43.C8DD3DF6@ollie.clive.ia.us> Message-ID: <19990129160254.59981@amber.org> On Fri, Jan 29, 1999 at 02:46:59PM -0600, Jeffrey C. Ollie wrote: > > * Sendmail only does this under SMTP, not under anything else > > Not if you add the 'm' flag to the delivery agent. Then sendmail will > invoke the delivery agent with multiple recipients specified on the > command line. Interesting, I've never seen this used for mailing lists, so I don't know what to say... obviously this is a sendmail only thing that gets into the whole problem outlined below. > > So, that means that Mailman would have to accept its messages over SMTP, > > which sin't in itself a problem... the problem is that as far as I've > > been able to determine, sendmail can't be told to deliver SMTP mail to a > > different port than 25. > > Actually you can, see p522 in the 2nd edition of _Sendmail_ (section > 30.4.1.2). I stand corrected, although I will point out that this is burried quite late in the sendmail world, and 5 people I know who relaly know sendmail didn't know this :-) Hense, it's obscure at best... Regardless... > > That's not nearly as ugly as the problems with doing it ... also it'd be > > different for every mailer, and quite different in many cases I think. > > Yes, existence of multiple SMTP daemons is a problem in that we'd have > to provide documentation on how to modify the configuration for many > different daemons. However doesn't this already happen? Aren't > sendmail, exim, qmail, or whatever sufficiently different in their > implementation that setup is already problematic? Dunno, at least with sendmail/postfix, it's just trivial additions to the /etc/aliases file. I use the same ones for postfix as you would for sendmail, absolutely, no exceptions. I THINK EXIM behaves the same way, and I think qmail does as well. This is trivially simple, it's also how every other mailer plugs into the MTA world. (Ialso run full blown LISTSERV). > Another, more radical idea would be to completely replace the regular > SMTP daemon with a SMTP daemon written in Python that integrates > directly with MailMan. I've been considering doing that for another, > more radical project that I have in mind. The only problem with this is > that you have to dedicate a box to running MailMan and there would be > some performace issues, but I guess that this would be offset by the > ability to run MailMan on a Windows or Mac OS system. I'm not sure this is a plus, considering I want a REALLY reliable system :-) I don't have a problem with someone writing a Python MTA (I've thought about it many times) BUT... mailman can't use it, at least in my opinion. Period. The MTA has to deal with /etc/aliases files just like everyone else, it's a defacto-standard at this point. > The idea of using a database to filter out multiple copies would be > problematic for sites that have high volume lists with a large > subscriber base. Just think of all of the storage that you'd need! Actually, locality of reference fixes this is MOST cases... that is, it's "safe" to assume for handwaving purposes that email originating from userA will reach mailserverB in x time... that is the same for all the different lists on X. So it's reasonably safe to assume that Mailman will see multiple copies almost simultaneously (i.e. no more than 5 minutes?). What this means is that you only have eto CACHE the Message-Id information, not keep it forever. And you're only keeping it for cross-posted messages also, not everything. I think this is totally doable, with a decent caching mechanism. (probably in C code, added to the normal Python distribution). Chris -- | Christopher Petrilli | petrilli@amber.org From claw@under.engr.sgi.com Fri Jan 29 22:20:03 1999 From: claw@under.engr.sgi.com (J C Lawrence) Date: Fri, 29 Jan 1999 14:20:03 -0800 Subject: [Mailman-Developers] Big lists In-Reply-To: Message from Balazs Nagy of "Fri, 29 Jan 1999 09:57:22 +0100." Message-ID: <199901292220.OAA73122@under.engr.sgi.com> On Fri, 29 Jan 1999 09:57:22 +0100 (CET) Balazs Nagy wrote: > Hiyas, How can I (we) set up mailman to handle big (with 25k or > more subscribers) lists? I'll chime in here with a variation: I'm chartered to start hosting a mailing list with 200K subscribers (yes, that's a fifth of a million) in the next few weeks. I would *like* to do it under Mailman (my current list server doesn't scale *that* well). Traffic will be low, probably under 20 inbound posts per day. My current small scale tests look good so far. Poking about the source looks _fair_, so far. Are there any known concerns? -- J C Lawrence Internet: claw@kanga.nu (Contractor) Internet: coder@kanga.nu ---------(*) Internet: claw@under.engr.sgi.com ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From cklempay@acm.jhu.edu Fri Jan 29 22:20:04 1999 From: cklempay@acm.jhu.edu (Corbett J. Klempay) Date: Fri, 29 Jan 1999 17:20:04 -0500 (EST) Subject: [Mailman-Developers] Big lists In-Reply-To: <199901292220.OAA73122@under.engr.sgi.com> Message-ID: Wow...what MTA are you planning on pairing with whatever list manager you go with? ------------------------------------------------------------------------------ Corbett J. Klempay Quote of the Week: http://www2.acm.jhu.edu/~cklempay "You shall judge of a man by his foes as well as by his friends." ------------------------------------------------------------------------------ On Fri, 29 Jan 1999, J C Lawrence wrote: > On Fri, 29 Jan 1999 09:57:22 +0100 (CET) > Balazs Nagy wrote: > > > Hiyas, How can I (we) set up mailman to handle big (with 25k or > > more subscribers) lists? > > I'll chime in here with a variation: > > I'm chartered to start hosting a mailing list with 200K > subscribers (yes, that's a fifth of a million) in the next few > weeks. I would *like* to do it under Mailman (my current list > server doesn't scale *that* well). Traffic will be low, probably > under 20 inbound posts per day. > > My current small scale tests look good so far. Poking about the > source looks _fair_, so far. Are there any known concerns? > > -- > J C Lawrence Internet: claw@kanga.nu > (Contractor) Internet: coder@kanga.nu > ---------(*) Internet: claw@under.engr.sgi.com > ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers > From claw@under.engr.sgi.com Fri Jan 29 22:40:10 1999 From: claw@under.engr.sgi.com (J C Lawrence) Date: Fri, 29 Jan 1999 14:40:10 -0800 Subject: [Mailman-Developers] Re: Please stop the cross posting In-Reply-To: Message from Ken Manheimer of "Fri, 29 Jan 1999 12:59:02 EST." Message-ID: <199901292240.OAA70390@under.engr.sgi.com> On Fri, 29 Jan 1999 12:59:02 -0500 (EST) Ken Manheimer wrote: > (Proper handling of the subject line prefix was one of the first > things i did - i'm pretty sure it was before 1.0b3, maybe 1.0b1. > If i recall correctly, i implemented a slightly more stringent > strategy, only looking for the prefix early on in the subject > line, after "re:"'s, but before other text. I know it takes care > of the vast majority of cases, and i suspect it's preferable more > of the time in offbeat cases than looking for the prefix anywhere > in the subject line, but i may be wrong. There are three common caxes: 1) User thinks he's being helpful and prepends his own tag. 2) Tag comes at start of Subject: or after some Re: or Fwd variation. 3) Tag occurs one or more times in Subject body due to hand edited subject (eg: Subject: XXX (was [tag] YYY) #1 is ignorable. #2 is slightly painful in the variations. eg Notes uses a "Re: #ddd" where the ddd's are a digital count of the number of replies made from Notes. #3 needs to be checked for and the (potentially multiple) instances of the tag need to be stripped I spent a while writing C code to do all of this (except for the Notes thing -- that's on the bug list), and can provide code samples as needed. -- J C Lawrence Internet: claw@kanga.nu (Contractor) Internet: coder@kanga.nu ---------(*) Internet: claw@under.engr.sgi.com ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From claw@under.engr.sgi.com Fri Jan 29 22:45:02 1999 From: claw@under.engr.sgi.com (J C Lawrence) Date: Fri, 29 Jan 1999 14:45:02 -0800 Subject: [Mailman-Developers] Big lists In-Reply-To: Message from "Corbett J. Klempay" of "Fri, 29 Jan 1999 17:20:04 EST." Message-ID: <199901292245.OAA59453@under.engr.sgi.com> On Fri, 29 Jan 1999 17:20:04 -0500 (EST) Corbett J Klempay wrote: > Wow...what MTA are you planning on pairing with whatever list > manager you go with? Exim -- its what I use already for my other mailing lists (typically half a million deliveries per day). -- J C Lawrence Internet: claw@kanga.nu (Contractor) Internet: coder@kanga.nu ---------(*) Internet: claw@under.engr.sgi.com ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From markw@tabnet.com Sat Jan 30 00:12:41 1999 From: markw@tabnet.com (Mark Williamson) Date: Fri, 29 Jan 1999 16:12:41 -0800 Subject: [Mailman-Developers] removing entries from aliases References: <199901281700.MAA00373@python.org> Message-ID: <36B24E78.9565F6A7@tabnet.com> How difficult would it be to remove the entries from the /etc/aliases from when a list is removed via the rmlist command? Does anyone have code for this already? regards, Mark From petrilli@amber.org Sat Jan 30 02:32:42 1999 From: petrilli@amber.org (Christopher G. Petrilli) Date: Fri, 29 Jan 1999 21:32:42 -0500 Subject: [Mailman-Developers] removing entries from aliases In-Reply-To: <36B24E78.9565F6A7@tabnet.com>; from Mark Williamson on Fri, Jan 29, 1999 at 04:12:41PM -0800 References: <199901281700.MAA00373@python.org> <36B24E78.9565F6A7@tabnet.com> Message-ID: <19990129213242.08649@amber.org> On Fri, Jan 29, 1999 at 04:12:41PM -0800, Mark Williamson wrote: > How difficult would it be to remove the entries from the /etc/aliases from when a list is > removed via the rmlist command? Does anyone have code for this already? > Technically not that hard, assuming nobody touches the pieces that it inserts (if you copy them in manually)... BUT, it'd have to be really really really sure before I'd trust it. Honestly, I don't remove lists often enough for this to be a problem... but it's certainly something to think about... moreso just the overall add/delete Chris -- | Christopher Petrilli | petrilli@amber.org From gstein@lyra.org Sat Jan 30 02:59:54 1999 From: gstein@lyra.org (Greg Stein) Date: Fri, 29 Jan 1999 18:59:54 -0800 Subject: [Mailman-Developers] ZDNet mentions Mailman! Message-ID: <36B275AA.68472CBC@lyra.org> A little tidbit for your reading pleasure... http://www.zdnet.com/sr/stories/issue/0,4537,387506,00.html The mailman reference is about a third of the way down the article. -g -- Greg Stein, http://www.lyra.org/ From Harald.Meland@usit.uio.no Sun Jan 31 04:54:18 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 31 Jan 1999 05:54:18 +0100 Subject: [Mailman-Developers] Limiting copies of cross posts sent In-Reply-To: "Christopher G. Petrilli"'s message of "Fri, 29 Jan 1999 16:02:54 -0500" References: <36B20B76.9D9955B0@ollie.clive.ia.us> <19990129144516.52367@amber.org> <36B21E43.C8DD3DF6@ollie.clive.ia.us> <19990129160254.59981@amber.org> Message-ID: [Christopher G. Petrilli] > On Fri, Jan 29, 1999 at 02:46:59PM -0600, Jeffrey C. Ollie wrote: > > Yes, existence of multiple SMTP daemons is a problem in that we'd have > > to provide documentation on how to modify the configuration for many > > different daemons. However doesn't this already happen? Aren't > > sendmail, exim, qmail, or whatever sufficiently different in their > > implementation that setup is already problematic? > > Dunno, at least with sendmail/postfix, it's just trivial additions to > the /etc/aliases file. I use the same ones for postfix as you would for > sendmail, absolutely, no exceptions. I THINK EXIM behaves the same > way, Once you've got the basic director and transport set up (in order to pipe things into mailman under the right UID/GID), all you need to do is add to an "aliases" file. However: If we try to communicate envelope recipients to the mailman pipe-alias command, we will have to do so in an MTA-specific way -- i.e. for the Exim case, one might do it in any of these ways: * Mailman can find the envelope recipient from the environment variables LOCAL_PART and DOMAIN. * Exim can invoke the Mailman pipe as /mail/wrapper post test $pipe_addresses * Exim can add an Envelope-To: header to all locally delivered mail, which Mailman then could use. None of these "solutions" would of course work for neither Sendmail, Qmail nor Postfix. IOW, we don't want to do that. Besides, even if a message is delivered in a single SMTP dialog with multiple RCPT To:s, the MTA will split the local deliveries up into one pipe delivery per envelope recipient. Thus Mailman _will_ need to keep some state between deliveries. My current ideas on limiting duplicates are: * Consider message headers unreliable. They are OK for collecting "hints" as to what lists a message _probably_ has been crossposted to, but it really should be the envelope recipients that make the call. * Mailman needs some way (heuristics could probably make do for now) of determining whether some header address does correspond to a (local) mailman list or not. * Whenever a message subject to duplicate removal gets injected into Mailman, register that message for "probable pending delivery" to the header addresses corresponding to local Mailman lists. * As the MTA runs the mailman pipes for the different envelope recipients, Mailman updates the "probable pending delivery" status for that list to say "pending delivery". * Depending on how well we want to utilize the "multiple RCPT To:" SMTP performance gain, Mailman could do either of A. As soon as a list gets status "pending delivery", ship the message off to the members of that list _that hasn't already received it_. Add all new addresses to some message.have_been_sent_to status variable. B. Add all members of the list to some message.to_be_delivered_to status variable, and wait for some time (se below) before starting actual delivery. * When either all the "probably pending delivery" addresses have been converted to "pending delivery" (plus, maybe, some small additional timeout to cater for any Bcc:ed list addresses?), or after some (site-configurable) timeout is reached, do the remaining pending deliveries, and garbage-collect the message status info. The "I don't want to receive multiple copies" option should be an user option, as I, for one, *would* like to receive multiple copies. Some additional features, e.g. "Mailman shouldn't deliver list messages to addresses already in the header" (leading to pretty decent support for the "I want to send a message to this list _minus_ these addresses" case :) could be nice for those that want them. > > Another, more radical idea would be to completely replace the regular > > SMTP daemon with a SMTP daemon written in Python that integrates > > directly with MailMan. I've been considering doing that for another, > > more radical project that I have in mind. The only problem with this is > > that you have to dedicate a box to running MailMan and there would be > > some performace issues, but I guess that this would be offset by the > > ability to run MailMan on a Windows or Mac OS system. > > I'm not sure this is a plus, considering I want a REALLY reliable system > :-) I don't have a problem with someone writing a Python MTA (I've > thought about it many times) BUT... mailman can't use it, at least in my > opinion. Period. The MTA has to deal with /etc/aliases files just like > everyone else, it's a defacto-standard at this point. Huh? Are you saying that there's problems with having the "usual" MTA deal with /etc/aliases, while the "Mailman/Python" MTA keeps its "aliases" elsewhere? This is the modus operandi of at least one other pretty widespread MLM package, namely Lyris (). -- Harald From gorgo@caesar.elte.hu Sun Jan 31 10:45:20 1999 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Sun, 31 Jan 1999 11:45:20 +0100 (MET) Subject: [Mailman-Developers] thousands of subscribers In-Reply-To: Message-ID: On 29 Jan 1999, Janne Sinkkonen wrote: > One thing is the subscriber list, visible for subscribers > themselves. It is linear, everything on one page and doesn't work well > for 25000 members. Another thing is the digest format which triggers a > sendmail MIME bug. Be sure to have sendmail 8.9.1 or newer, otherwise > you site will explode. :) Even if your sendmail works, you're going to > get annoyed messages from administrators of other sites who have an > older sendmail dumping core because of your digests. The sendmail MIME bug triggers only when your sendmail wants to send a 8bitmime mail to a remote smtp server which does not support 8bitmime, so your sendmail has to transform it... And in most cases the other sites sendmail won't dump core because probably it won't need to send them to a third host... Greg, who was bitten by the MIME problem severly... -- 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 stu@ekins.net Sun Jan 31 12:32:04 1999 From: stu@ekins.net (Stu Ekins) Date: Sun, 31 Jan 1999 12:32:04 -0000 Subject: [Mailman-Developers] removing entries from aliases Message-ID: <014201be4d15$b6fdf060$0e45fea9@fred> >On Fri, Jan 29, 1999 at 04:12:41PM -0800, Mark Williamson wrote: >> How difficult would it be to remove the entries from the /etc/aliases from when a list is >> removed via the rmlist command? Does anyone have code for this already? >Technically not that hard, assuming nobody touches the pieces that it >inserts (if you copy them in manually)... BUT, it'd have to be really >really really sure before I'd trust it. Honestly, I don't remove lists >often enough for this to be a problem... but it's certainly something to >think about... moreso just the overall add/delete I agree. Wouldn't it be a better idea to have a second aliases file that only mailman can modify, then have an alternative version of newaliases that concatenates the standard /etc/aliases and the mailman aliases together, before processing. That way, if it all goes pear shaped, your main aliases file is unaffected, only your mailman aliases get screwed, and if you have a backup version, you can recover. I'm sure I read somewhere about being able to do includes in alias files anyway, but I can't find the reference anyway. Or am I missing the point here? Stu. -- http://mobiles.ekins.net - Special offers on Nokia 9000 cases and personal numbers... From bence@intercom.hu Sat Jan 2 14:47:20 1999 From: bence@intercom.hu (Hermann Benedek) Date: Sat, 2 Jan 1999 15:47:20 +0100 Subject: [Mailman-Developers] Send digest at a specific time Message-ID: I want the digest to be sent a specific time, eg. at midnight, but I can't set the sent-out-time. It would be great if I could set the max. digest size to 0, and set a "send-time" variable to the time when I want to send out the digests. Any idea? Udv Bence From w.knowles@niwa.cri.nz Tue Jan 5 02:56:25 1999 From: w.knowles@niwa.cri.nz (Wayne Knowles) Date: Tue, 5 Jan 1999 15:56:25 +1300 (NZDT) Subject: [Mailman-Developers] Upgrade from 1.0b4 -> 1.0b7 fails Message-ID: I have been running Mailman version 1.0b4 for a while, and decided it was about time to upgrade to the latest version. Everything went well until the point of running the "make update" script then got the following error: ***** ***** If you are installing over an old installation, please ***** run "make update". See the UPGRADING file for details. ***** katipo 130% make update Traceback (innermost last): File "bin/update", line 10, in ? from Mailman.MailList import MailList File "/home/mailman/Mailman/MailList.py", line 30, in ? import Utils File "/home/mailman/Mailman/Utils.py", line 509, in ? def chunkify(members, chunksize=mm_cfg.DEFAULT_ADMIN_MEMBER_CHUNKSIZE): AttributeError: DEFAULT_ADMIN_MEMBER_CHUNKSIZE DEFAULT_ADMIN_MEMBER_CHUNKSIZE was not defined in my old mm_cfg.py file, and the mm_cfg.py wasn't installed overtop, but as mm_cfg.py.dist Since the site config is standard I copied across mm_cfg.py.dist into mm_cfg.py and make update completed. The Python version isn't quite kosher, but I don't think it matters: Python 1.5.2a2 (#5, Dec 15 1998, 13:16:57) [GCC 2.7.2.1] on freebsd2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> Did I install 1.0b4 incorrectly, or does the update script need to be fixed to work around the problem? BTW - The known problem building under FreeBSD using BSD Make appears to be fixed (have tested on FreeSBD 2.2.5 and 3.0-current). I no longer need GNU Make or hack the Makefile by hand. Wayne -- _____ Wayne Knowles, Systems Manager / o \/ National Institute of Water & Atmospheric Research Ltd \/ v /\ P.O. Box 14-901 Kilbirnie, Wellington, NEW ZEALAND `---' Email: w.knowles@niwa.cri.nz From grin@tolna.net Tue Jan 5 03:34:25 1999 From: grin@tolna.net (Peter Gervai) Date: Tue, 5 Jan 1999 04:34:25 +0100 Subject: [Mailman-Developers] [ANNOUNCE] Mailman 1.0b7 In-Reply-To: <13964.177.459126.902326@anthem.cnri.reston.va.us>; from Barry A. Warsaw on Thu, Dec 31, 1998 at 05:54:41PM -0500 References: <13964.177.459126.902326@anthem.cnri.reston.va.us> Message-ID: <19990105043425.A23199@mail.tolna.net> Barry, On Thu, Dec 31, 1998 at 05:54:41PM -0500, Barry A. Warsaw wrote: > Below is an excerpt from the DONE file which gives some highlights for > this release. [...] Do you know the feeling when you read a release note and it contains nearly all the bugs you've come up with the last month fixed? ;-) Great work done, installed without a problem. Until now. :) So far only one comment: UPGRADING file should be upgraded. :) (as well as 'make upgrade' texts.) bye, grin From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Jan 6 03:47:45 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 5 Jan 1999 22:47:45 -0500 (EST) Subject: [Mailman-Developers] Send digest at a specific time References: Message-ID: <13970.56545.331951.476159@anthem.cnri.reston.va.us> >>>>> "HB" == Hermann Benedek writes: HB> I want the digest to be sent a specific time, eg. at midnight, HB> but I can't set the sent-out-time. HB> It would be great if I could set the max. digest size to 0, HB> and set a "send-time" variable to the time when I want to send HB> out the digests. HB> Any idea? The "send-time" is controlled by the crontab entry you installed: cron/crontab.in. Just change the time set to run the senddigests script. You don't need to set digest size to 0, leave it at the size you have so digests can be send more than once a day if your list has a lot of traffic. Just set digest_send_periodic to true and you'll get your daily digests even if the size threshhold hasn't been reached. Hit `yes' to the question: Should a digest be dispatched daily when the size threshold isn't reached? -Barry From boldi@budapest.hu Mon Jan 4 01:47:38 1999 From: boldi@budapest.hu (Bencsath Boldizsar) Date: Mon, 4 Jan 1999 02:47:38 +0100 (CET) Subject: [Mailman-Developers] small sec problem / or feuture (?) In-Reply-To: <13947.11732.567166.584256@anthem.cnri.reston.va.us> Message-ID: Hi! Another mailman problem, just for You: On one of my lists a strange mail occoured: it came from szecsei virag, who has NO email address at budapest.hu But the mail, that was distributed by the list contains a header: From: Szecsei@sas.fph.hu, =?iso-8859-1?Q?Vir=E1g?= I'm not sure, it might be a problem in sendmail or anything, i thing the original address was From: Szecsei, Vira'g (but the a' was an eastern european letter) And somewhere, somewhat tried to convert it to a "living" address by adding the hostname to the first word. thank You, boldizsar -------------------------------- Bencsath Boldizsar boldi@inf.bme.hu boldi@rulez.org greetings to MP5k DREC JCE Lacrosse http://www.inf.bme.hu/~boldi -------------------------------- From dragondm@delta.integral.org Wed Jan 6 16:08:58 1999 From: dragondm@delta.integral.org (The Dragon De Monsyne) Date: Wed, 6 Jan 1999 10:08:58 -0600 (CST) Subject: [Mailman-Developers] small sec problem / or feuture (?) In-Reply-To: Message-ID: On Mon, 4 Jan 1999, Bencsath Boldizsar wrote: > Hi! > > Another mailman problem, just for You: > On one of my lists a strange mail occoured: it came from szecsei virag, > who has NO email address at budapest.hu > But the mail, that was distributed by the list contains a header: > From: Szecsei@sas.fph.hu, =?iso-8859-1?Q?Vir=E1g?= > > > I'm not sure, it might be a problem in sendmail or anything, i thing the > original address was > From: Szecsei, Vira'g > (but the a' was an eastern european letter) > And somewhere, somewhat tried to convert it to a "living" address by > adding the hostname to the first word. Ok, I see what's happening here, but it isn't with Mailman. The =?iso...?= stuff is the MIME way of quoting non latin-1 charsets. Some MTA probly did that, and you email program dosen't support MIME RFC encoded headers. Second, as I see by your message ID you are using PINE on sas.fph.hu PINE is what is adding the hostname to that first part. It's thinking 'Szecsei' is a local emal address, & tacking the local hostname (sas.fph.hu) onto it for you. Third, that address is technically bogus. Commas are not allowed in address comments. -The Dragon De Monsyne From Harald.Meland@usit.uio.no Wed Jan 6 16:43:06 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 06 Jan 1999 17:43:06 +0100 Subject: [Mailman-Developers] small sec problem / or feuture (?) In-Reply-To: Bencsath Boldizsar's message of "Mon, 4 Jan 1999 02:47:38 +0100 (CET)" References: Message-ID: [Bencsath Boldizsar] > But the mail, that was distributed by the list contains a header: > From: Szecsei@sas.fph.hu, =?iso-8859-1?Q?Vir=E1g?= > > > I'm not sure, it might be a problem in sendmail or anything, i thing the > original address was > From: Szecsei, Vira'g This very much sounds like something that the MTA, and not Mailman, would do. RFC822 specifies that addresses in the From: header should not be unqualified, and thus many MTAs try "fixing" such broken headers by adding and "@" and some local domain. I think trying to implement something in Mailman to stop messages whose headers appear to have been subject to such (possibly incorrect) address qualification, would be: 1) Very nearly impossible to get anywhere close to correct 2) Uncalled for. This is simply not a job Mailman should take on Basically the problem in Szecsei's case is that he inserted a "," in the real name part of his From address, thereby really making it into _two_ separate addresses (one of them unqualified). The problems start with the insertion of that pesky extra ",", and that's where this should be fixed. -- Harald From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Jan 6 23:09:28 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 6 Jan 1999 18:09:28 -0500 (EST) Subject: [Mailman-Developers] Upgrade from 1.0b4 -> 1.0b7 fails References: Message-ID: <13971.60712.534766.306199@anthem.cnri.reston.va.us> >>>>> "WK" == Wayne Knowles writes: WK> Did I install 1.0b4 incorrectly, or does the update script WK> need to be fixed to work around the problem? You did everything correctly. It is a problem with the Mailman/Utils.py file. Attached is a patch that should fix the problem. WK> BTW - The known problem building under FreeBSD using BSD Make WK> appears to be fixed (have tested on FreeSBD 2.2.5 and WK> 3.0-current). I no longer need GNU Make or hack the Makefile WK> by hand. Cool! Thanks for the feedback -- I can only test with Solaris make and GNU make, so I'm glad my changes fixed the problem. -Barry Index: Utils.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/Utils.py,v retrieving revision 1.58 diff -c -r1.58 Utils.py *** Utils.py 1999/01/05 23:03:43 1.58 --- Utils.py 1999/01/06 23:05:03 *************** *** 506,515 **** return got ! def chunkify(members, chunksize=mm_cfg.DEFAULT_ADMIN_MEMBER_CHUNKSIZE): """ return a list of lists of members """ members.sort() res = [] while 1: --- 506,517 ---- return got ! def chunkify(members, chunksize=None): """ return a list of lists of members """ + if chunksize is None: + chunksize = mm_cfg.DEFAULT_ADMIN_MEMBER_CHUNKSIZE members.sort() res = [] while 1: From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Jan 6 23:11:33 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 6 Jan 1999 18:11:33 -0500 (EST) Subject: [Mailman-Developers] [ANNOUNCE] Mailman 1.0b7 References: <13964.177.459126.902326@anthem.cnri.reston.va.us> <19990105043425.A23199@mail.tolna.net> Message-ID: <13971.60837.546629.831837@anthem.cnri.reston.va.us> >>>>> "PG" == Peter Gervai writes: PG> Do you know the feeling when you read a release note and it PG> contains nearly all the bugs you've come up with the last PG> month fixed? ;-) Yay! PG> Great work done, installed without a problem. Until now. :) Cool... um... PG> So far only one comment: UPGRADING file should be upgraded. :) PG> (as well as 'make upgrade' texts.) Thanks, will do. -Barry From jerrya@fastrans.net Wed Jan 6 23:20:55 1999 From: jerrya@fastrans.net (Jerry Adlersfluegel) Date: Wed, 6 Jan 1999 17:20:55 -0600 (CST) Subject: [Mailman-Developers] fwd: Cron /usr/bin/python /home/mailman/cron/senddigests (fwd) Message-ID: I have upgraded mailman to the new release, 1.0b7, on my redhat 5 system. $ uname -a Linux jerrya 2.0.32 #4 Wed Jan 7 23:14:32 CST 1998 i486 unknown I still receive the following message every day when the digests go out. They are going out successfully, but this message still gets delivered. ---------- Forwarded message ---------- Date: Wed, 6 Jan 1999 12:00:04 -0600 From: Cron Daemon To: mailman@jerrya.fastrans.net Subject: Cron /usr/bin/python /home/mailman/cron/senddigests Traceback (innermost last): File "/home/mailman/cron/senddigests", line 37, in ? main() File "/home/mailman/cron/senddigests", line 34, in main list.SendDigestIfAny() File "/home/mailman/Mailman/Digester.py", line 194, in SendDigestIfAny self.SendDigestOnSize(0) File "/home/mailman/Mailman/Digester.py", line 206, in SendDigestOnSize self.SendDigest() File "/home/mailman/Mailman/Digester.py", line 290, in SendDigest self.DeliverToList(d.Present(mime=0), File "/home/mailman/Mailman/Deliverer.py", line 172, in DeliverToList status = cmdproc.close() IOError: (10, 'No child processes') Any ideas? Thanks. -- Jerry Adlersfluegel From julian7@kva.hu Thu Jan 7 19:07:06 1999 From: julian7@kva.hu (Balazs Nagy) Date: Thu, 7 Jan 1999 20:07:06 +0100 (CET) Subject: [Mailman-Developers] Little bug(?) in admindb Message-ID: Hiyas, I got four pendings to an email list, but when I wanted to submit my changes, it said that there's an error in line #196. This is a for loop with form.keys() as k, but it cannot interpret form[k].value. I have no time because I want to finish my cgi extension and MTU patches but for the short-time fix I got out ValueError from the next except line. -- Linux Supporting Center -- Red Hat Qmail packages -- http://lsc.kva.hu PGP 0x1DE3631D / A8 B4 92 EE 1F 55 27 C8 86 64 9C 42 41 A4 BD B8 Don't spell GLIB backwards! From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Jan 8 06:36:22 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 8 Jan 1999 01:36:22 -0500 (EST) Subject: [Mailman-Developers] fwd: Cron /usr/bin/python /home/mailman/cron/senddigests (fwd) References: Message-ID: <13973.42854.570987.255838@anthem.cnri.reston.va.us> >>>>> "JA" == Jerry Adlersfluegel writes: JA> I have upgraded mailman to the new release, 1.0b7, on my JA> redhat 5 system. JA> $ uname -a Linux jerrya 2.0.32 #4 Wed Jan 7 23:14:32 CST 1998 JA> i486 unknown JA> I still receive the following message every day when the JA> digests go out. They are going out successfully, but this JA> message still gets delivered. I've never seen this on Solaris, and I can't reproduce it. Since you're still getting deliveries, I think we'll suppress the error message. Here's a patch. Could you and other Linux folks please test? -Barry -------------------- snip snip -------------------- Index: Deliverer.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/Deliverer.py,v retrieving revision 1.48 diff -c -r1.48 Deliverer.py *** Deliverer.py 1998/12/23 00:09:59 1.48 --- Deliverer.py 1999/01/08 06:27:55 *************** *** 20,25 **** --- 20,26 ---- import string, os, sys import operator + import errno import mm_cfg import Errors import Utils *************** *** 169,175 **** if footer: cmdproc.write(footer) ! status = cmdproc.close() if status: self.LogMsg('deliverer', 'Non-zero exit status: %d\nCommand: %s', --- 170,191 ---- if footer: cmdproc.write(footer) ! # TBD: this potentially masks a real bug. We have been getting ! # several reports from Linux users that this line is raising the ! # following exception: ! # ! # IOError: (10, 'No child processes') ! # ! # I don't know how this can happen, I can't reproduce it on Solaris, ! # and it doesn't seem to affect anything. So I'm chalking it up to a ! # harmless Linux artifact that we can safely ignore. ! try: ! status = cmdproc.close() ! except IOError, (code, msg): ! if errcode <> errno.ECHILD: ! Utils.reraise() ! # otherwise just ignore it ! status = 0 if status: self.LogMsg('deliverer', 'Non-zero exit status: %d\nCommand: %s', From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Jan 8 06:46:16 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 8 Jan 1999 01:46:16 -0500 (EST) Subject: [Mailman-Developers] Little bug(?) in admindb References: Message-ID: <13973.43448.461046.183947@anthem.cnri.reston.va.us> >>>>> "BN" == Balazs Nagy writes: BN> I got four pendings to an email list, but when I wanted to BN> submit my changes, it said that there's an error in line #196. BN> This is a for loop with form.keys() as k, but it cannot BN> interpret form[k].value. Can you please send a traceback? I don't know what kind of error you're getting. Is it an AttributeError or something else? BN> I have no time because I want to finish my cgi extension and BN> MTU patches but for the short-time fix I got out ValueError BN> from the next except line. Sorry, I don't quite understand. Also, please submit patches against the CVS tree if possible, otherwise definitely against 1.0b7. And if you're looking to get these patches into 1.0, *please hurry*! ;-) -Barry From julian7@kva.hu Fri Jan 8 08:16:14 1999 From: julian7@kva.hu (Balazs Nagy) Date: Fri, 8 Jan 1999 09:16:14 +0100 (CET) Subject: [Mailman-Developers] Little bug(?) in admindb In-Reply-To: <13973.43448.461046.183947@anthem.cnri.reston.va.us> Message-ID: On Fri, 8 Jan 1999, Barry A. Warsaw wrote: > >>>>> "BN" == Balazs Nagy writes: > > BN> I got four pendings to an email list, but when I wanted to > BN> submit my changes, it said that there's an error in line #196. > BN> This is a for loop with form.keys() as k, but it cannot > BN> interpret form[k].value. > > Can you please send a traceback? I don't know what kind of error > you're getting. Is it an AttributeError or something else? I didn't have a mouse but a simple console screen with lynx. Here's my new test: With one pending: OK With two or more pendings: Traceback (innermost last): File "/home/mailman/scripts/driver", line 102, in run_main main() File "../Mailman/Cgi/admindb.py", line 124, in main HandleRequests(doc) File "../Mailman/Cgi/admindb.py", line 196, in HandleRequests v = int(form[k].value) AttributeError: value > BN> I have no time because I want to finish my cgi extension and > BN> MTU patches but for the short-time fix I got out ValueError > BN> from the next except line. Just now Iam rewriting my old patches, but my temp fix is --- admindb.py.orig Fri Jan 8 09:13:35 1999 +++ admindb.py Fri Jan 8 09:13:43 1999 @@ -195,7 +195,7 @@ try: v = int(form[k].value) request_id = int(k) - except ValueError: + except: continue try: request = list.GetRequest(request_id) > Also, please submit patches against the CVS tree if possible, > otherwise definitely against 1.0b7. And if you're looking to get > these patches into 1.0, *please hurry*! ;-) Of course ;) I'll send it today (until 1500CET). -- Linux Supporting Center -- Red Hat Qmail packages -- http://lsc.kva.hu PGP 0x1DE3631D / A8 B4 92 EE 1F 55 27 C8 86 64 9C 42 41 A4 BD B8 Don't spell GLIB backwards! From julian7@kva.hu Fri Jan 8 09:47:48 1999 From: julian7@kva.hu (Balazs Nagy) Date: Fri, 8 Jan 1999 10:47:48 +0100 (CET) Subject: [Mailman-Developers] My patches Message-ID: 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. ---456965764-233999344-915788868=:3512 Content-Type: TEXT/PLAIN; charset=US-ASCII Hiyas, Here are my patches. These do the following: 1-cmdhandler: simplification in `set' command 2-cgiext: adds CGI extension support (eg. admin -> admin.cgi) 3-mtu: replaces direct SMTP delivery with sendmail/qmail/smail etc software. -- Linux Supporting Center -- Red Hat Qmail packages -- http://lsc.kva.hu PGP 0x1DE3631D / A8 B4 92 EE 1F 55 27 C8 86 64 9C 42 41 A4 BD B8 Don't spell GLIB backwards! ---456965764-233999344-915788868=:3512 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="mailman-1-cmdhandler.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="mailman-1-cmdhandler.patch" ZGlmZiAtcnVOIG1haWxtYW4ub3JpZy9NYWlsbWFuL01haWxDb21tYW5kSGFu ZGxlci5weSBtYWlsbWFuL01haWxtYW4vTWFpbENvbW1hbmRIYW5kbGVyLnB5 DQotLS0gbWFpbG1hbi5vcmlnL01haWxtYW4vTWFpbENvbW1hbmRIYW5kbGVy LnB5CVNhdCBEZWMgMTIgMTk6MDM6NDMgMTk5OA0KKysrIG1haWxtYW4vTWFp bG1hbi9NYWlsQ29tbWFuZEhhbmRsZXIucHkJRnJpIEphbiAgOCAwOToyOTow OSAxOTk5DQpAQCAtMjQxLDEwICsyNDEsMTcgQEANCiAJZWxzZToNCiAJICAg IFNob3dTZXRVc2FnZSgpDQogCSAgICByZXR1cm4NCisJdHJ5Og0KKwkgICAg c2VuZGVyID0gc2VsZi5GaW5kVXNlcihtYWlsLkdldFNlbmRlcigpKQ0KKwkg ICAgc2VsZi5Db25maXJtVXNlclBhc3N3b3JkKHNlbmRlciwgYXJnc1syXSkN CisJZXhjZXB0IEVycm9ycy5NTU5vdEFNZW1iZXJFcnJvcjoNCisJICAgIHNl bGYuQWRkRXJyb3IoIiVzIGlzbid0IHN1YnNjcmliZWQgdG8gdGhpcyBsaXN0 LiINCisJCQkgICUgbWFpbC5HZXRTZW5kZXIoKSkNCisJICAgIHJldHVybg0K KwlleGNlcHQgRXJyb3JzLk1NQmFkUGFzc3dvcmRFcnJvcjoNCisJICAgIHNl bGYuQWRkRXJyb3IoIllvdSBnYXZlIHRoZSB3cm9uZyBwYXNzd29yZC4iKQ0K IAlpZiBhcmdzWzBdID09ICdkaWdlc3QnOg0KIAkgICAgdHJ5Og0KLQkJc2Vu ZGVyID0gc2VsZi5GaW5kVXNlcihtYWlsLkdldFNlbmRlcigpKQ0KLQkJc2Vs Zi5Db25maXJtVXNlclBhc3N3b3JkKHNlbmRlciwgYXJnc1syXSkNCiAJCXNl bGYuU2V0VXNlckRpZ2VzdChtYWlsLkdldFNlbmRlcigpLCB2YWx1ZSkNCiAJ CXNlbGYuQWRkVG9SZXNwb25zZSgiU3VjY2VlZGVkLiIpDQogCSAgICBleGNl cHQgRXJyb3JzLk1NQWxyZWFkeURpZ2VzdGVkOg0KQEAgLTI1OCwxNiArMjY1 LDExIEBADQogCQlzZWxmLkFkZEVycm9yKCJMaXN0IG9ubHkgYWNjZXB0cyBk aWdlc3QgbWVtYmVycy4iKQ0KIAkgICAgZXhjZXB0IEVycm9ycy5NTUNhbnRE aWdlc3RFcnJvcjoNCiAJCXNlbGYuQWRkRXJyb3IoIkxpc3QgZG9lc24ndCBh Y2NlcHQgZGlnZXN0IG1lbWJlcnMuIikNCi0JICAgIGV4Y2VwdCBFcnJvcnMu TU1Ob3RBTWVtYmVyRXJyb3I6DQotCQlzZWxmLkFkZEVycm9yKCIlcyBpc24n dCBzdWJzY3JpYmVkIHRvIHRoaXMgbGlzdC4iDQotICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgJSBtYWlsLkdldFNlbmRlcigpKQ0KIAkgICAgZXhj ZXB0IEVycm9ycy5NTUxpc3ROb3RSZWFkeToNCiAJCXNlbGYuQWRkRXJyb3Io Ikxpc3QgaXMgbm90IGZ1bmN0aW9uYWwuIikNCiAJICAgIGV4Y2VwdCBFcnJv cnMuTU1Ob1N1Y2hVc2VyRXJyb3I6DQogCQlzZWxmLkFkZEVycm9yKCIlcyBp cyBub3Qgc3Vic2NyaWJlZCB0byB0aGlzIGxpc3QuIg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICUgbWFpbC5HZXRTZW5kZXIoKSkNCi0JICAg IGV4Y2VwdCBFcnJvcnMuTU1CYWRQYXNzd29yZEVycm9yOg0KLQkJc2VsZi5B ZGRFcnJvcigiWW91IGdhdmUgdGhlIHdyb25nIHBhc3N3b3JkLiIpDQogCSAg ICBleGNlcHQgRXJyb3JzLk1NTmVlZEFwcHJvdmFsOg0KIAkJc2VsZi5BZGRB cHByb3ZhbE1zZyhjbWQpDQogCSAgICBleGNlcHQ6DQpAQCAtMjc4LDExICsy ODAsNiBAQA0KIAkJc2VsZi5BZGRFcnJvcigiJXMiICUgc3lzLmV4Y190eXBl KQ0KIAllbGlmIG9wdGlvbl9pbmZvLmhhc19rZXkoYXJnc1swXSk6DQogCSAg ICB0cnk6DQotCQlzZW5kZXIgPSBzZWxmLkZpbmRVc2VyKG1haWwuR2V0U2Vu ZGVyKCkpDQotCQlpZiBub3Qgc2VuZGVyOg0KLQkJICAgIHNlbGYuQWRkRXJy b3IoIllvdSBhcmVuJ3Qgc3Vic2NyaWJlZC4iKQ0KLQkJICAgIHJldHVybg0K LQkJc2VsZi5Db25maXJtVXNlclBhc3N3b3JkKHNlbmRlciwgYXJnc1syXSkN CiAJCXNlbGYuU2V0VXNlck9wdGlvbihzZW5kZXIsIG9wdGlvbl9pbmZvW2Fy Z3NbMF1dLCB2YWx1ZSkNCiAJCXNlbGYuQWRkVG9SZXNwb25zZSgiU3VjY2Vl ZGVkLiIpDQogCSAgICBleGNlcHQgRXJyb3JzLk1NQmFkUGFzc3dvcmRFcnJv cjoNCg== ---456965764-233999344-915788868=:3512 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="mailman-2-cgiext.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="mailman-2-cgiext.patch" ZGlmZiAtcnVOIG1haWxtYW4tMS1jbWRoYW5kbGVyL01haWxtYW4vQXJjaGl2 ZXIvSHlwZXJBcmNoLnB5IG1haWxtYW4vTWFpbG1hbi9BcmNoaXZlci9IeXBl ckFyY2gucHkNCi0tLSBtYWlsbWFuLTEtY21kaGFuZGxlci9NYWlsbWFuL0Fy Y2hpdmVyL0h5cGVyQXJjaC5weQlTYXQgRGVjIDEyIDE5OjA0OjAwIDE5OTgN CisrKyBtYWlsbWFuL01haWxtYW4vQXJjaGl2ZXIvSHlwZXJBcmNoLnB5CUZy aSBKYW4gIDggMDk6MzA6MjIgMTk5OQ0KQEAgLTQzMiw3ICs0MzIsNyBAQA0K ICAgICBkZWYgaHRtbF9mb290KHNlbGYpOg0KIAlkID0geyJsYXN0ZGF0ZSI6 IGh0bWxfcXVvdGUoc2VsZi5sYXN0ZGF0ZSksDQogCSAgICAgImFyY2hpdmVk YXRlIjogaHRtbF9xdW90ZShzZWxmLmFyY2hpdmVkYXRlKSwNCi0JICAgICAi bGlzdGluZm8iOiBzZWxmLm1haWxsaXN0LkdldEFic29sdXRlU2NyaXB0VVJM KCdsaXN0aW5mbycpLA0KKwkgICAgICJsaXN0aW5mbyI6IHNlbGYubWFpbGxp c3QuR2V0QWJzb2x1dGVTY3JpcHRVUkwobW1fY2ZnLmxpc3RpbmZvX2NnaSks DQogCSAgICAgInZlcnNpb24iOiBzZWxmLnZlcnNpb259DQogCWZvciB0IGlu ICgidGhyZWFkIiwgInN1YmplY3QiLCAiYXV0aG9yIiwgImRhdGUiKToNCiAJ ICAgIGNhcCA9IHN0cmluZy51cHBlcih0WzBdKSArIHRbMTpdDQpAQCAtNDQ4 LDcgKzQ0OCw3IEBADQogCWQgPSB7Imxpc3RuYW1lIjogaHRtbF9xdW90ZShz ZWxmLm1haWxsaXN0LnJlYWxfbmFtZSksDQogCSAgICAgImFyY2h0eXBlIjog c2VsZi50eXBlLA0KIAkgICAgICJhcmNoaXZlIjogc2VsZi5hcmNoaXZlLA0K LQkgICAgICJsaXN0aW5mbyI6IHNlbGYubWFpbGxpc3QuR2V0QWJzb2x1dGVT Y3JpcHRVUkwoJ2xpc3RpbmZvJyksDQorCSAgICAgImxpc3RpbmZvIjogc2Vs Zi5tYWlsbGlzdC5HZXRBYnNvbHV0ZVNjcmlwdFVSTChtbV9jZmcubGlzdGlu Zm9fY2dpKSwNCiAJICAgICAiZmlyc3RkYXRlIjogaHRtbF9xdW90ZShzZWxm LmZpcnN0ZGF0ZSksDQogCSAgICAgImxhc3RkYXRlIjogaHRtbF9xdW90ZShz ZWxmLmxhc3RkYXRlKSwNCiAJICAgICAic2l6ZSI6IHNlbGYuc2l6ZSwNCkBA IC00NjYsNyArNDY2LDcgQEANCiANCiAgICAgZGVmIGh0bWxfVE9DKHNlbGYp Og0KICAgICAgICAgZCA9IHsibGlzdG5hbWUiOiBzZWxmLm1haWxsaXN0LnJl YWxfbmFtZSwNCi0gICAgICAgICAgICAgImxpc3RpbmZvIjogc2VsZi5tYWls bGlzdC5HZXRBYnNvbHV0ZVNjcmlwdFVSTCgnbGlzdGluZm8nKSB9DQorICAg ICAgICAgICAgICJsaXN0aW5mbyI6IHNlbGYubWFpbGxpc3QuR2V0QWJzb2x1 dGVTY3JpcHRVUkwobW1fY2ZnLmxpc3RpbmZvX2NnaSkgfQ0KICAgICAgICAg bGlzdGluZyA9ICIiDQogICAgICAgICBpZiBub3Qgc2VsZi5hcmNoaXZlczoN CiAgICAgICAgICAgICBkWyJub2FyY2hpdmVfbXNnIl0gPSAnPFA+Q3VycmVu dGx5LCB0aGVyZSBhcmUgbm8gYXJjaGl2ZXMuIDwvUD4nDQpkaWZmIC1ydU4g bWFpbG1hbi0xLWNtZGhhbmRsZXIvTWFpbG1hbi9Cb3VuY2VyLnB5IG1haWxt YW4vTWFpbG1hbi9Cb3VuY2VyLnB5DQotLS0gbWFpbG1hbi0xLWNtZGhhbmRs ZXIvTWFpbG1hbi9Cb3VuY2VyLnB5CVNhdCBEZWMgMTIgMTk6MDM6MjggMTk5 OA0KKysrIG1haWxtYW4vTWFpbG1hbi9Cb3VuY2VyLnB5CUZyaSBKYW4gIDgg MDk6MzA6MjIgMTk5OQ0KQEAgLTIxNSw3ICsyMTUsNyBAQA0KICAgICAgICAg ICAgIGlmIGRpZCA9PSAnZGlzYWJsZWQnIGFuZCBzdWNjZWVkZWQgPT0gMToN CiAgICAgICAgICAgICAgICAgcmVlbmFibGUgPSBVdGlscy5tYWtldGV4dCgN CiAgICAgICAgICAgICAgICAgICAgICdyZWVuYWJsZS50eHQnLA0KLSAgICAg ICAgICAgICAgICAgICAgeydhZG1pbl91cmwnOiBzZWxmLkdldEFic29sdXRl U2NyaXB0VVJMKCdhZG1pbicpLA0KKyAgICAgICAgICAgICAgICAgICAgeydh ZG1pbl91cmwnOiBzZWxmLkdldEFic29sdXRlU2NyaXB0VVJMKG1tX2NmZy5h ZG1pbl9jZ2kpLA0KICAgICAgICAgICAgICAgICAgICAgIH0pDQogICAgICAg ICAgICAgZWxzZToNCiAgICAgICAgICAgICAgICAgcmVlbmFibGUgPSAnJw0K ZGlmZiAtcnVOIG1haWxtYW4tMS1jbWRoYW5kbGVyL01haWxtYW4vQ2dpL2Fk bWluLnB5IG1haWxtYW4vTWFpbG1hbi9DZ2kvYWRtaW4ucHkNCi0tLSBtYWls bWFuLTEtY21kaGFuZGxlci9NYWlsbWFuL0NnaS9hZG1pbi5weQlGcmkgSmFu ICA4IDA5OjE4OjI3IDE5OTkNCisrKyBtYWlsbWFuL01haWxtYW4vQ2dpL2Fk bWluLnB5CUZyaSBKYW4gIDggMDk6MzA6MjIgMTk5OQ0KQEAgLTEyNCw3ICsx MjQsNyBAQA0KICAgICAgICAgICAgICAgICAnYWRtbG9naW4udHh0JywNCiAg ICAgICAgICAgICAgICAgeyJsaXN0bmFtZSI6IGxpc3RfbmFtZSwNCiAgICAg ICAgICAgICAgICAgICJwYXRoIiAgICA6IG9zLmVudmlyb24uZ2V0KCJSRVFV RVNUX1VSSSIsDQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAnL21haWxtYW4vYWRtaW4vJyArIGxpc3RfbmFtZSksDQor ICAgICAgICAgICAgICAgICAgICAgICAgICAgICcvbWFpbG1hbi8nICsgbW1f Y2ZnLmFkbWluX2NnaSArICcvJyArIGxpc3RfbmFtZSksDQogICAgICAgICAg ICAgICAgICAibWVzc2FnZSIgOiBtZXNzYWdlLA0KICAgICAgICAgICAgICAg ICAgfSkNCiAgICAgICAgICAgICBwcmludCB0ZXh0DQpAQCAtMjE3LDcgKzIx Nyw4IEBADQogICAgICAgICAgICAgICAgICAgICAgICAlICgoZXJyb3IgYW5k ICJ0aGUgcmlnaHQgIikgb3IgIiIpKQ0KICAgICAgICAgICAgICAgICAgICAg ICArDQogICAgICAgICAgICAgICAgICAgICAgICIgR2VuZXJhbCBsaXN0IGlu Zm9ybWF0aW9uIGNhbiBiZSBmb3VuZCBhdCAiLA0KLSAgICAgICAgICAgICAg ICAgICAgICBMaW5rKCIlc2xpc3RpbmZvIiAlICgnLi4vJyAqIFV0aWxzLkdl dE5lc3RpbmdMZXZlbCgpKSwgDQorICAgICAgICAgICAgICAgICAgICAgIExp bmsoIiVzJXMiICUgKCcuLi8nICogVXRpbHMuR2V0TmVzdGluZ0xldmVsKCks DQorCQkgICAgICAgICAgbW1fY2ZnLmxpc3RpbmZvX2NnaSksIA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICJ0aGUgbWFpbGluZyBsaXN0IG92ZXJ2 aWV3IHBhZ2UiKSwNCiAgICAgICAgICAgICAgICAgICAgICAgIi4iDQogICAg ICAgICAgICAgICAgICAgICAgICI8cD4oU2VuZCBxdWVzdGlvbnMgYW5kIGNv bW1lbnRzIHRvICIsDQpAQCAtMjMzLDcgKzIzNCw3IEBADQogICAgIGlmIGFk dmVydGlzZWQ6DQogICAgICAgICB0YWJsZS5BZGRSb3coW0l0YWxpYygiTGlz dCIpLCBJdGFsaWMoIkRlc2NyaXB0aW9uIildKQ0KICAgICAgICAgZm9yIGwg aW4gYWR2ZXJ0aXNlZDoNCi0gICAgICAgICAgICB0YWJsZS5BZGRSb3coW0xp bmsobC5HZXRSZWxhdGl2ZVNjcmlwdFVSTCgnYWRtaW4nKSwgDQorICAgICAg ICAgICAgdGFibGUuQWRkUm93KFtMaW5rKGwuR2V0UmVsYXRpdmVTY3JpcHRV UkwobW1fY2ZnLmFkbWluX2NnaSksIA0KIAkgICAgICAgICAgICAgICAgICBC b2xkKGwucmVhbF9uYW1lKSksbC5kZXNjcmlwdGlvbl0pDQogDQogICAgIGRv Yy5BZGRJdGVtKHRhYmxlKQ0KQEAgLTI1NSwxMyArMjU2LDEzIEBADQogICAg IGxpbmtzX3RhYmxlLkFkZFJvdyhbQ2VudGVyKEJvbGQoIkNvbmZpZ3VyYXRp b24gQ2F0ZWdvcmllcyIpKSwNCiAgICAgICAgICAgICAgICAgICAgICAgICBD ZW50ZXIoQm9sZCgiT3RoZXIgQWRtaW5pc3RyYXRpdmUgQWN0aXZpdGllcyIp KV0pDQogICAgIG90aGVyX2xpbmtzID0gVW5vcmRlcmVkTGlzdCgpDQotICAg IGxpbmsgPSBMaW5rKGxzdC5HZXRSZWxhdGl2ZVNjcmlwdFVSTCgnYWRtaW5k YicpLCANCisgICAgbGluayA9IExpbmsobHN0LkdldFJlbGF0aXZlU2NyaXB0 VVJMKG1tX2NmZy5hZG1pbmRiX2NnaSksIA0KICAgICAgICAgICAgICAgICAn VGVuZCB0byBwZW5kaW5nIGFkbWluaXN0cmF0aXZlIHJlcXVlc3RzLicpDQog ICAgIG90aGVyX2xpbmtzLkFkZEl0ZW0obGluaykNCi0gICAgbGluayA9IExp bmsobHN0LkdldFJlbGF0aXZlU2NyaXB0VVJMKCdsaXN0aW5mbycpLA0KKyAg ICBsaW5rID0gTGluayhsc3QuR2V0UmVsYXRpdmVTY3JpcHRVUkwobW1fY2Zn Lmxpc3RpbmZvX2NnaSksDQogICAgICAgICAgICAgICAgICdHbyB0byB0aGUg Z2VuZXJhbCBsaXN0IGluZm9ybWF0aW9uIHBhZ2UuJykNCiAgICAgb3RoZXJf bGlua3MuQWRkSXRlbShsaW5rKQ0KLSAgICBsaW5rID0gTGluayhsc3QuR2V0 UmVsYXRpdmVTY3JpcHRVUkwoJ2VkaXRodG1sJyksDQorICAgIGxpbmsgPSBM aW5rKGxzdC5HZXRSZWxhdGl2ZVNjcmlwdFVSTChtbV9jZmcuZWRpdGh0bWxf Y2dpKSwNCiAgICAgICAgICAgICAgICAgJ0VkaXQgdGhlIEhUTUwgZm9yIHRo ZSBwdWJsaWMgbGlzdCBwYWdlcy4nKQ0KICAgICBvdGhlcl9saW5rcy5BZGRJ dGVtKGxpbmspDQogDQpAQCAtMjcxLDcgKzI3Miw3IEBADQogICAgICAgICAg ICAgdGhlc2VfbGlua3MuQWRkSXRlbSgiPGI+ID0mZ3Q7ICIgKyB2ICsgIiAm bHQ7PSA8L2I+IikNCiAgICAgICAgIGVsc2U6DQogICAgICAgICAgICAgdGhl c2VfbGlua3MuQWRkSXRlbShMaW5rKCIlcy8lcyIgJSANCi0JICAgICAgICAg ICAgICAgICAobHN0LkdldFJlbGF0aXZlU2NyaXB0VVJMKCdhZG1pbicpLGsp LHYpKQ0KKwkgICAgICAgICAgICAgICAgIChsc3QuR2V0UmVsYXRpdmVTY3Jp cHRVUkwobW1fY2ZnLmFkbWluX2NnaSksayksdikpDQogDQogICAgIGxpbmtz X3RhYmxlLkFkZFJvdyhbdGhlc2VfbGlua3MsIG90aGVyX2xpbmtzXSkNCiAg ICAgbGlua3NfdGFibGUuQWRkUm93SW5mbyhtYXgobGlua3NfdGFibGUuR2V0 Q3VycmVudFJvd0luZGV4KCksIDApLA0KQEAgLTI4MCwxMCArMjgxLDEwIEBA DQogICAgIGRvYy5BZGRJdGVtKGxpbmtzX3RhYmxlKQ0KICAgICBkb2MuQWRk SXRlbSgnPGhyPicpDQogICAgIGlmIGNhdGVnb3J5X3N1ZmZpeDoNCi0gICAg ICAgIGZvcm0gPSBGb3JtKCIlcy8lcyIgJSAobHN0LkdldFJlbGF0aXZlU2Ny aXB0VVJMKCdhZG1pbicpLA0KKyAgICAgICAgZm9ybSA9IEZvcm0oIiVzLyVz IiAlIChsc3QuR2V0UmVsYXRpdmVTY3JpcHRVUkwobW1fY2ZnLmFkbWluX2Nn aSksDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNhdGVn b3J5X3N1ZmZpeCkpDQogICAgIGVsc2U6DQotICAgICAgICBmb3JtID0gRm9y bShsc3QuR2V0UmVsYXRpdmVTY3JpcHRVUkwoJ2FkbWluJykpDQorICAgICAg ICBmb3JtID0gRm9ybShsc3QuR2V0UmVsYXRpdmVTY3JpcHRVUkwobW1fY2Zn LmFkbWluX2NnaSkpDQogICAgIGRvYy5BZGRJdGVtKGZvcm0pDQogDQogICAg IGZvcm0uQWRkSXRlbSgiTWFrZSB5b3VyIGNoYW5nZXMgYmVsb3csIGFuZCB0 aGVuIHN1Ym1pdCB0aGVtIHVzaW5nIHRoZSINCkBAIC00MDIsNyArNDAzLDcg QEANCiAgICAgZG9jLkFkZEl0ZW0oIjxiPiVzPC9iPiAoJXMpOiAlczxwPiIg JSAodmFybmFtZSwgY2F0ZWdvcnksIGl0ZW1bNF0pKQ0KICAgICBkb2MuQWRk SXRlbSgiJXM8cD4iICUgaXRlbVs1XSkNCiANCi0gICAgZm9ybSA9IEZvcm0o IiVzLyVzIiAlIChsc3QuR2V0UmVsYXRpdmVTY3JpcHRVUkwoJ2FkbWluJyks IGNhdGVnb3J5KSkNCisgICAgZm9ybSA9IEZvcm0oIiVzLyVzIiAlIChsc3Qu R2V0UmVsYXRpdmVTY3JpcHRVUkwobW1fY2ZnLmFkbWluX2NnaSksIGNhdGVn b3J5KSkNCiAgICAgdmFsdGFiID0gVGFibGUoY2VsbHNwYWNpbmc9MywgY2Vs bHBhZGRpbmc9NCkNCiAgICAgQWRkT3B0aW9uc1RhYmxlSXRlbSh2YWx0YWIs IGl0ZW0sIGNhdGVnb3J5LCBsc3QsIG5vZGV0YWlscz0xKQ0KICAgICBmb3Jt LkFkZEl0ZW0odmFsdGFiKQ0KQEAgLTUxMiw3ICs1MTMsNyBAQA0KICAgICAg ICAgYnV0dG9ucyA9IFtdDQogICAgICAgICBmb3IgY2kgaW4gY2h1bmtfaW5k aWNlczoNCiAgICAgICAgICAgICBzdGFydCwgZW5kID0gY2h1bmtzW2NpXVsw XSwgY2h1bmtzW2NpXVstMV0NCi0JICAgIHVybCA9IGxzdC5HZXRBYnNvbHV0 ZVNjcmlwdFVSTCgnYWRtaW4nKQ0KKwkgICAgdXJsID0gbHN0LkdldEFic29s dXRlU2NyaXB0VVJMKG1tX2NmZy5hZG1pbl9jZ2kpDQogICAgICAgICAgICAg YnV0dG9ucy5hcHBlbmQoIjxhIGhyZWY9JXMvbWVtYmVycz9jaHVuaz0lZD4g ZnJvbSAlcyB0byAlcyA8L2E+Ig0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICUgKCB1cmwsICBjaSwgc3RhcnQsIGVuZCkpDQogICAgICAgICBidXR0 b25zID0gYXBwbHkoVW5vcmRlcmVkTGlzdCwgdHVwbGUoYnV0dG9ucykpDQpk aWZmIC1ydU4gbWFpbG1hbi0xLWNtZGhhbmRsZXIvTWFpbG1hbi9DZ2kvYWRt aW5kYi5weSBtYWlsbWFuL01haWxtYW4vQ2dpL2FkbWluZGIucHkNCi0tLSBt YWlsbWFuLTEtY21kaGFuZGxlci9NYWlsbWFuL0NnaS9hZG1pbmRiLnB5CUZy aSBKYW4gIDggMDk6MTg6MjggMTk5OQ0KKysrIG1haWxtYW4vTWFpbG1hbi9D Z2kvYWRtaW5kYi5weQlGcmkgSmFuICA4IDA5OjMxOjQ4IDE5OTkNCkBAIC0x MTMsNyArMTEzLDcgQEANCiAgICAgICAgICAgICAgICAgJ2FkbWxvZ2luLnR4 dCcsDQogICAgICAgICAgICAgICAgIHsnbGlzdG5hbWUnOiBsaXN0X25hbWUs DQogICAgICAgICAgICAgICAgICAncGF0aCcgICAgOiBvcy5lbnZpcm9uLmdl dCgnUkVRVUVTVF9VUkknLA0KLSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgJy9tYWlsbWFuL2FkbWluLycgKyBsaXN0X25h bWUpLA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJy9tYWlsbWFu LycgKyBtbV9jZmcuYWRtaW5fY2dpICsgJy8nICsgbGlzdF9uYW1lKSwNCiAg ICAgICAgICAgICAgICAgICdtZXNzYWdlJyA6IG1lc3NhZ2UsDQogICAgICAg ICAgICAgICAgICB9KQ0KICAgICAgICAgICAgIHByaW50IHRleHQNCkBAIC0y NTAsNiArMjUwLDcgQEANCiANCiAMDQogZGVmIFByaW50UmVxdWVzdHMoZG9j KToNCisgICAgaW1wb3J0IG1tX2NmZw0KICAgICAjIFhYWDogWXVrLCBibGVj aCwgaWNrDQogICAgIGdsb2JhbCBsaXN0DQogICAgIGdsb2JhbCBmb3JtDQpA QCAtMjYyLDcgKzI2Myw3IEBADQogICAgIGRvYy5BZGRJdGVtKEhlYWRlcigy LCAiQWRtaW5pc3RyYXRpdmUgcmVxdWVzdHMgZm9yICclcycgbWFpbGluZyBs aXN0Ig0KICAgICAgICAgICAgICAgICAgICAgICAgJSBsaXN0LnJlYWxfbmFt ZSkpDQogICAgIGRvYy5BZGRJdGVtKEZvbnRTaXplKCIrMSIsDQotICAgICAg ICAgICAgICAgICAgICAgICAgIExpbmsobGlzdC5HZXRSZWxhdGl2ZVNjcmlw dFVSTCgnYWRtaW4nKSwNCisgICAgICAgICAgICAgICAgICAgICAgICAgTGlu ayhsaXN0LkdldFJlbGF0aXZlU2NyaXB0VVJMKG1tX2NmZy5hZG1pbl9jZ2kp LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEl0YWxpYygNCiAg ICAgICAgICdWaWV3IG9yIGVkaXQgdGhlIGxpc3QgY29uZmlndXJhdGlvbiBp bmZvcm1hdGlvbicpKSkpDQogICAgIGRvYy5BZGRJdGVtKCc8cD4nKQ0KQEAg LTI3MCw3ICsyNzEsNyBAQA0KIAlkb2MuQWRkSXRlbShIZWFkZXIoMywnVGhl cmUgYXJlIG5vIHBlbmRpbmcgcmVxdWVzdHMuJykpDQogCWRvYy5BZGRJdGVt KGxpc3QuR2V0TWFpbG1hbkZvb3RlcigpKQ0KIAlyZXR1cm4NCi0gICAgZm9y bSA9IEZvcm0obGlzdC5HZXRSZWxhdGl2ZVNjcmlwdFVSTCgnYWRtaW5kYicp KQ0KKyAgICBmb3JtID0gRm9ybShsaXN0LkdldFJlbGF0aXZlU2NyaXB0VVJM KG1tX2NmZy5hZG1pbmRiX2NnaSkpDQogICAgIGRvYy5BZGRJdGVtKGZvcm0p DQogIyMgICAgZm9ybS5BZGRJdGVtKCdBZG1pbiBwYXNzd29yZDogJykNCiAj IyAgICBmb3JtLkFkZEl0ZW0oUGFzc3dvcmRCb3goJ2FkbWlucHcnKSkNCmRp ZmYgLXJ1TiBtYWlsbWFuLTEtY21kaGFuZGxlci9NYWlsbWFuL0NnaS9lZGl0 aHRtbC5weSBtYWlsbWFuL01haWxtYW4vQ2dpL2VkaXRodG1sLnB5DQotLS0g bWFpbG1hbi0xLWNtZGhhbmRsZXIvTWFpbG1hbi9DZ2kvZWRpdGh0bWwucHkJ TW9uIE5vdiAxNiAwMjo0Njo0NyAxOTk4DQorKysgbWFpbG1hbi9NYWlsbWFu L0NnaS9lZGl0aHRtbC5weQlGcmkgSmFuICA4IDA5OjMwOjIyIDE5OTkNCkBA IC0yMyw3ICsyMyw3IEBADQogZnJvbSBNYWlsbWFuIGltcG9ydCBVdGlscywg TWFpbExpc3QNCiBmcm9tIE1haWxtYW4gaW1wb3J0IGh0bWxmb3JtYXQNCiBm cm9tIE1haWxtYW4uSFRNTEZvcm1hdHRlciBpbXBvcnQgSFRNTEZvcm1hdHRl cg0KLWZyb20gTWFpbG1hbiBpbXBvcnQgRXJyb3JzDQorZnJvbSBNYWlsbWFu IGltcG9ydCBFcnJvcnMsIG1tX2NmZw0KIA0KIA0KICNFZGl0YWJsZSB0ZW1w bGF0ZXMuICBXZSBzaG91bGQgYWxzbyBiZSBhYmxlIHRvIGVkaXQgdGhlIGFy Y2hpdmUgaW5kZXgsIHdoaWNoIA0KQEAgLTkyLDggKzkyLDggQEANCiAgICAg ICAgIGRvYy5BZGRJdGVtKGh0bWxmb3JtYXQuSGVhZGVyKDIsICdTZWxlY3Qg cGFnZSB0byBlZGl0OicpKQ0KICAgICAgICAgdGVtcGxhdGVfbGlzdCA9IGh0 bWxmb3JtYXQuVW5vcmRlcmVkTGlzdCgpDQogICAgICAgICBmb3IgKHRlbXBs YXRlLCBpbmZvKSBpbiB0ZW1wbGF0ZV9kYXRhOg0KLSAgICAgICAgICAgIGwg PSBodG1sZm9ybWF0LkxpbmsoIiVzLyVzIiAlIChsaXN0LkdldFJlbGF0aXZl U2NyaXB0VVJMKCdlZGl0aHRtbCcpLHRlbXBsYXRlKSwNCi0gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGluZm8pDQorICAgICAgICAgICAgbCA9 IGh0bWxmb3JtYXQuTGluaygiJXMvJXMiICUNCisJCShsaXN0LkdldFJlbGF0 aXZlU2NyaXB0VVJMKG1tX2NmZy5lZGl0aHRtbF9jZ2kpLHRlbXBsYXRlKSwg aW5mbykNCiAgICAgICAgICAgICB0ZW1wbGF0ZV9saXN0LkFkZEl0ZW0obCkN CiAgICAgICAgIGRvYy5BZGRJdGVtKGh0bWxmb3JtYXQuRm9udFNpemUoIisy IiwgdGVtcGxhdGVfbGlzdCkpDQogICAgICAgICBkb2MuQWRkSXRlbShsaXN0 LkdldE1haWxtYW5Gb290ZXIoKSkNCkBAIC0xNTAsMTQgKzE1MCwxNCBAQA0K IA0KICAgICBkb2MuQWRkSXRlbSgnPGhyPicpDQogDQotICAgIGxpbmsgPSBo dG1sZm9ybWF0LkxpbmsobGlzdC5HZXRSZWxhdGl2ZVNjcmlwdFVSTCgnYWRt aW4nKSwNCisgICAgbGluayA9IGh0bWxmb3JtYXQuTGluayhsaXN0LkdldFJl bGF0aXZlU2NyaXB0VVJMKG1tX2NmZy5hZG1pbl9jZ2kpLA0KIAkJCSAgICdW aWV3IG9yIGVkaXQgdGhlIGxpc3QgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlv bi4nKQ0KICAgICBkb2MuQWRkSXRlbShodG1sZm9ybWF0LkZvbnRTaXplKCIr MSIsIGxpbmspKQ0KICAgICBkb2MuQWRkSXRlbSgnPHA+JykNCiANCiAgICAg ZG9jLkFkZEl0ZW0oJzxocj4nKQ0KIA0KLSAgICBmb3JtID0gaHRtbGZvcm1h dC5Gb3JtKCIlcy8lcyIgJSAobGlzdC5HZXRSZWxhdGl2ZVNjcmlwdFVSTCgn ZWRpdGh0bWwnKSwNCisgICAgZm9ybSA9IGh0bWxmb3JtYXQuRm9ybSgiJXMv JXMiICUgKGxpc3QuR2V0UmVsYXRpdmVTY3JpcHRVUkwobW1fY2ZnLmVkaXRo dG1sX2NnaSksDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB0ZW1wbGF0ZV9uYW1lKSkNCiAgICAgZG9jLkFkZEl0ZW0oZm9ybSkN CiANCmRpZmYgLXJ1TiBtYWlsbWFuLTEtY21kaGFuZGxlci9NYWlsbWFuL0Nn aS9saXN0aW5mby5weSBtYWlsbWFuL01haWxtYW4vQ2dpL2xpc3RpbmZvLnB5 DQotLS0gbWFpbG1hbi0xLWNtZGhhbmRsZXIvTWFpbG1hbi9DZ2kvbGlzdGlu Zm8ucHkJRnJpIEphbiAgOCAwOToxODoyOSAxOTk5DQorKysgbWFpbG1hbi9N YWlsbWFuL0NnaS9saXN0aW5mby5weQlGcmkgSmFuICA4IDA5OjMwOjIyIDE5 OTkNCkBAIC0xMjcsNyArMTI3LDggQEANCiAgICAgICAgICAgICAgICAgICAg ICAgICUgKChlcnJvciBhbmQgInJpZ2h0ICIpIG9yICIiKSkNCiAgICAgICAg ICAgICAgICAgICAgICAgKw0KICAgICAgICAgICAgICAgICAgICAgICAnPHA+ IExpc3QgYWRtaW5pc3RyYXRvcnMsIHlvdSBjYW4gdmlzaXQgJywNCi0gICAg ICAgICAgICAgICAgICAgICAgTGluaygiJXNhZG1pbi8iICUgKCcuLi8nICog VXRpbHMuR2V0TmVzdGluZ0xldmVsKCkpLA0KKyAgICAgICAgICAgICAgICAg ICAgICBMaW5rKCIlcyVzLyIgJSAoJy4uLycgKiBVdGlscy5HZXROZXN0aW5n TGV2ZWwoKSwNCisJCSAgICAgICAgICBtbV9jZmcuYWRtaW5fY2dpKSwNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAidGhlIGxpc3QgYWRtaW4gb3Zl cnZpZXcgcGFnZSIpLA0KICAgICAgICAgICAgICAgICAgICAgICAiIHRvIGZp bmQgdGhlIG1hbmFnZW1lbnQgaW50ZXJmYWNlIGZvciB5b3VyIGxpc3QuIg0K ICAgICAgICAgICAgICAgICAgICAgICAiPHA+KFNlbmQgcXVlc3Rpb25zIG9y IGNvbW1lbnRzIHRvICIsDQpAQCAtMTQxLDcgKzE0Miw3IEBADQogICAgIGlm IGFkdmVydGlzZWQ6DQogICAgICAgICB0YWJsZS5BZGRSb3coW0l0YWxpYygi TGlzdCIpLCBJdGFsaWMoIkRlc2NyaXB0aW9uIildKQ0KICAgICBmb3IgbCBp biBhZHZlcnRpc2VkOg0KLSAgICAgICAgdGFibGUuQWRkUm93KFtMaW5rKGwu R2V0UmVsYXRpdmVTY3JpcHRVUkwoJ2xpc3RpbmZvJyksIA0KKyAgICAgICAg dGFibGUuQWRkUm93KFtMaW5rKGwuR2V0UmVsYXRpdmVTY3JpcHRVUkwobW1f Y2ZnLmxpc3RpbmZvX2NnaSksIA0KIAkgICAgICBCb2xkKGwucmVhbF9uYW1l KSksIGwuZGVzY3JpcHRpb25dKQ0KIA0KICAgICBkb2MuQWRkSXRlbSh0YWJs ZSkNCkBAIC0xNzAsOCArMTcxLDggQEANCiAgICAgcmVwbGFjZW1lbnRzWyc8 bW0tbmV3LXBhc3N3b3JkLWJveD4nXSA9IGxpc3QuRm9ybWF0U2VjdXJlQm94 KCdwdycpDQogICAgIHJlcGxhY2VtZW50c1snPG1tLWNvbmZpcm0tcGFzc3dv cmQ+J10gPSBsaXN0LkZvcm1hdFNlY3VyZUJveCgncHctY29uZicpDQogICAg IHJlcGxhY2VtZW50c1snPG1tLXN1YnNjcmliZS1mb3JtLXN0YXJ0PiddID0g XA0KLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBsaXN0LkZvcm1hdEZvcm1TdGFydCgnc3Vic2NyaWJlJykNCi0gICAg cmVwbGFjZW1lbnRzWyc8bW0tcm9zdGVyLWZvcm0tc3RhcnQ+J10gPSBsaXN0 LkZvcm1hdEZvcm1TdGFydCgncm9zdGVyJykNCisgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbGlzdC5Gb3JtYXRGb3Jt U3RhcnQobW1fY2ZnLnN1YnNjcmliZV9jZ2kpDQorICAgIHJlcGxhY2VtZW50 c1snPG1tLXJvc3Rlci1mb3JtLXN0YXJ0PiddID0gbGlzdC5Gb3JtYXRGb3Jt U3RhcnQobW1fY2ZnLnJvc3Rlcl9jZ2kpDQogICAgIHJlcGxhY2VtZW50c1sn PG1tLWVkaXRpbmctb3B0aW9ucz4nXSA9IGxpc3QuRm9ybWF0RWRpdGluZ09w dGlvbigpDQogICAgIHJlcGxhY2VtZW50c1snPG1tLWluZm8tYnV0dG9uPidd ID0gU3VibWl0QnV0dG9uKCdVc2VyT3B0aW9ucycsDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICdFZGl0 IE9wdGlvbnMnKS5Gb3JtYXQoKQ0KZGlmZiAtcnVOIG1haWxtYW4tMS1jbWRo YW5kbGVyL01haWxtYW4vQ2dpL29wdGlvbnMucHkgbWFpbG1hbi9NYWlsbWFu L0NnaS9vcHRpb25zLnB5DQotLS0gbWFpbG1hbi0xLWNtZGhhbmRsZXIvTWFp bG1hbi9DZ2kvb3B0aW9ucy5weQlUaHUgRGVjIDE3IDExOjAwOjE3IDE5OTgN CisrKyBtYWlsbWFuL01haWxtYW4vQ2dpL29wdGlvbnMucHkJRnJpIEphbiAg OCAwOTozMDoyMiAxOTk5DQpAQCAtMTIyLDcgKzEyMiw3IEBADQogICAgICAg ICAgICAgICAgICAgICAgICAgICAnTGlzdCBteSBvdGhlciBzdWJzY3JpcHRp b25zJykpDQogICAgIHJlcGxhY2VtZW50c1snPG1tLWNoYW5nZS1wYXNzLWJ1 dHRvbj4nXSA9ICgNCiAgICAgICAgIGxpc3QuRm9ybWF0QnV0dG9uKCdjaGFu Z2VwdycsICJDaGFuZ2UgTXkgUGFzc3dvcmQiKSkNCi0gICAgcmVwbGFjZW1l bnRzWyc8bW0tZm9ybS1zdGFydD4nXSA9IGxpc3QuRm9ybWF0Rm9ybVN0YXJ0 KCdoYW5kbGVfb3B0cycsIHVzZXIpDQorICAgIHJlcGxhY2VtZW50c1snPG1t LWZvcm0tc3RhcnQ+J10gPSBsaXN0LkZvcm1hdEZvcm1TdGFydChtbV9jZmcu aGFuZGxlX29wdHNfY2dpLCB1c2VyKQ0KICAgICByZXBsYWNlbWVudHNbJzxt bS11c2VyPiddID0gdXNlcg0KICAgICByZXBsYWNlbWVudHNbJzxtbS1wcmVz ZW50YWJsZS11c2VyPiddID0gcHJlc2VudGFibGVfdXNlcg0KICAgICByZXBs YWNlbWVudHNbJzxtbS1lbWFpbC1teS1wdz4nXSA9IGxpc3QuRm9ybWF0QnV0 dG9uKCdlbWFpbHB3JywNCmRpZmYgLXJ1TiBtYWlsbWFuLTEtY21kaGFuZGxl ci9NYWlsbWFuL0RlZmF1bHRzLnB5LmluIG1haWxtYW4vTWFpbG1hbi9EZWZh dWx0cy5weS5pbg0KLS0tIG1haWxtYW4tMS1jbWRoYW5kbGVyL01haWxtYW4v RGVmYXVsdHMucHkuaW4JRnJpIEphbiAgOCAwOToxODowNiAxOTk5DQorKysg bWFpbG1hbi9NYWlsbWFuL0RlZmF1bHRzLnB5LmluCUZyaSBKYW4gIDggMDk6 MzA6MjIgMTk5OQ0KQEAgLTI4MywxMyArMjgzLDE1IEBADQogIyBEYXRhIGZp bGUgdmVyc2lvbiBudW1iZXINCiBEQVRBX0ZJTEVfVkVSU0lPTiA9IDEzDQog DQorIyBDR0kgZmlsZXMNCiANCi0NCi0NCi0NCi0NCi0NCi0NCi0NCi0NCi0N CithZG1pbl9jZ2kJPSAiYWRtaW5AQ0dJRVhUQCINCithZG1pbmRiX2NnaQk9 ICJhZG1pbmRiQENHSUVYVEAiDQorYXJjaGl2ZV9jZ2kJPSAiYXJjaGl2ZUBD R0lFWFRAIg0KK2VkaXRodG1sX2NnaQk9ICJlZGl0aHRtbEBDR0lFWFRAIg0K K2hhbmRsZV9vcHRzX2NnaQk9ICJoYW5kbGVfb3B0c0BDR0lFWFRAIg0KK2xp c3RpbmZvX2NnaQk9ICJsaXN0aW5mb0BDR0lFWFRAIg0KK29wdGlvbnNfY2dp CT0gIm9wdGlvbnNAQ0dJRVhUQCINCityb3N0ZXJfY2dpCT0gInJvc3RlckBD R0lFWFRAIg0KK3N1YnNjcmliZV9jZ2kJPSAic3Vic2NyaWJlQENHSUVYVEAi DQorcHJpdmF0ZV9jZ2kJPSAicHJpdmF0ZUBDR0lFWFRAIg0KZGlmZiAtcnVO IG1haWxtYW4tMS1jbWRoYW5kbGVyL01haWxtYW4vRGVsaXZlcmVyLnB5IG1h aWxtYW4vTWFpbG1hbi9EZWxpdmVyZXIucHkNCi0tLSBtYWlsbWFuLTEtY21k aGFuZGxlci9NYWlsbWFuL0RlbGl2ZXJlci5weQlGcmkgSmFuICA4IDA5OjE4 OjA2IDE5OTkNCisrKyBtYWlsbWFuL01haWxtYW4vRGVsaXZlcmVyLnB5CUZy aSBKYW4gIDggMDk6MzA6MjIgMTk5OQ0KQEAgLTIwNiw3ICsyMDYsNyBAQA0K ICAgICAgICAgICAgICdwb3N0YWNrLnR4dCcsDQogICAgICAgICAgICAgeydz dWJqZWN0JyAgICAgOiBzdWJqZWN0LA0KICAgICAgICAgICAgICAnbGlzdG5h bWUnICAgIDogc2VsZi5yZWFsX25hbWUsDQotICAgICAgICAgICAgICdsaXN0 aW5mb191cmwnOiBzZWxmLkdldEFic29sdXRlU2NyaXB0VVJMKCdsaXN0aW5m bycpLA0KKyAgICAgICAgICAgICAnbGlzdGluZm9fdXJsJzogc2VsZi5HZXRB YnNvbHV0ZVNjcmlwdFVSTChtbV9jZmcubGlzdGluZm9fY2dpKSwNCiAgICAg ICAgICAgICAgfSkNCiAJc2VsZi5TZW5kVGV4dFRvVXNlcignJXMgcG9zdCBh Y2tub3dsZWdlbWVudCcgJSBzZWxmLnJlYWxfbmFtZSwNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgYm9keSwgc2VuZGVyKQ0KQEAgLTIzMyw3ICsy MzMsNyBAQA0KICAgICAgICAgICAgICAnd2VsY29tZScgICAgIDogd2VsY29t ZSwNCiAgICAgICAgICAgICAgJ3VtYnJlbGxhJyAgICA6IHVtYnJlbGxhLA0K ICAgICAgICAgICAgICAnZW1haWxhZGRyJyAgIDogc2VsZi5HZXRMaXN0RW1h aWwoKSwNCi0gICAgICAgICAgICAgJ2xpc3RpbmZvX3VybCc6IHNlbGYuR2V0 QWJzb2x1dGVTY3JpcHRVUkwoJ2xpc3RpbmZvJyksDQorICAgICAgICAgICAg ICdsaXN0aW5mb191cmwnOiBzZWxmLkdldEFic29sdXRlU2NyaXB0VVJMKG1t X2NmZy5saXN0aW5mb19jZ2kpLA0KICAgICAgICAgICAgICAnb3B0aW9uc3Vy bCcgIDogc2VsZi5HZXRBYnNvbHV0ZU9wdGlvbnNVUkwobmFtZSksDQogICAg ICAgICAgICAgICdwYXNzd29yZCcgICAgOiBwYXNzd29yZCwNCiAgICAgICAg ICAgICAgfSkNCmRpZmYgLXJ1TiBtYWlsbWFuLTEtY21kaGFuZGxlci9NYWls bWFuL0RpZ2VzdGVyLnB5IG1haWxtYW4vTWFpbG1hbi9EaWdlc3Rlci5weQ0K LS0tIG1haWxtYW4tMS1jbWRoYW5kbGVyL01haWxtYW4vRGlnZXN0ZXIucHkJ U2F0IERlYyAxMiAxOTowMzozNCAxOTk4DQorKysgbWFpbG1hbi9NYWlsbWFu L0RpZ2VzdGVyLnB5CUZyaSBKYW4gIDggMDk6MzA6MjIgMTk5OQ0KQEAgLTMz Miw3ICszMzIsNyBAQA0KICAgICAgICAgICAgIHN1YnN0cyA9IHt9DQogICAg ICAgICAgICAgc3Vic3RzLnVwZGF0ZShsc3QuX19kaWN0X18pDQogICAgICAg ICAgICAgc3Vic3RzLnVwZGF0ZSh7J2dvdF9saXN0aW5mb191cmwnOiANCi0g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbHN0Lkdl dEFic29sdXRlU2NyaXB0VVJMKCdsaXN0aW5mbycpLA0KKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsc3QuR2V0QWJzb2x1dGVT Y3JpcHRVUkwobW1fY2ZnLmxpc3RpbmZvX2NnaSksDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgJ2dvdF9yZXF1ZXN0X2VtYWlsJzogbHN0LkdldFJl cXVlc3RFbWFpbCgpLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICdn b3RfbGlzdF9lbWFpbCc6IGxzdC5HZXRMaXN0RW1haWwoKSwNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAnZ290X293bmVyX2VtYWlsJzogbHN0Lkdl dEFkbWluRW1haWwoKSwNCmRpZmYgLXJ1TiBtYWlsbWFuLTEtY21kaGFuZGxl ci9NYWlsbWFuL0hUTUxGb3JtYXR0ZXIucHkgbWFpbG1hbi9NYWlsbWFuL0hU TUxGb3JtYXR0ZXIucHkNCi0tLSBtYWlsbWFuLTEtY21kaGFuZGxlci9NYWls bWFuL0hUTUxGb3JtYXR0ZXIucHkJVGh1IERlYyAxNyAxMTowMDoxMyAxOTk4 DQorKysgbWFpbG1hbi9NYWlsbWFuL0hUTUxGb3JtYXR0ZXIucHkJRnJpIEph biAgOCAwOTozMDoyMiAxOTk5DQpAQCAtODgsNyArODgsNyBAQA0KICAJZWxz ZToNCiAgCSAgICBjb25jZWFsZWQgPSAiIg0KICAgICAgICAgT2JzY3VyZUVt YWlsID0gVXRpbHMuT2JzY3VyZUVtYWlsDQotICAgICAgICBvcHRpb25zX3Vy bCA9IHNlbGYuR2V0UmVsYXRpdmVTY3JpcHRVUkwoJ29wdGlvbnMnKQ0KKyAg ICAgICAgb3B0aW9uc191cmwgPSBzZWxmLkdldFJlbGF0aXZlU2NyaXB0VVJM KG1tX2NmZy5vcHRpb25zX2NnaSkNCiAgICAgICAgIGRpc2RlbCA9IG1tX2Nm Zy5EaXNhYmxlRGVsaXZlcnkNCiAgICAgICAgIGl0ZW1zID0gW10NCiAgICAg ICAgIGZvciBwZXJzb24gaW4gcGVvcGxlOg0KZGlmZiAtcnVOIG1haWxtYW4t MS1jbWRoYW5kbGVyL01haWxtYW4vTGlzdEFkbWluLnB5IG1haWxtYW4vTWFp bG1hbi9MaXN0QWRtaW4ucHkNCi0tLSBtYWlsbWFuLTEtY21kaGFuZGxlci9N YWlsbWFuL0xpc3RBZG1pbi5weQlTYXQgRGVjIDEyIDE5OjAzOjM5IDE5OTgN CisrKyBtYWlsbWFuL01haWxtYW4vTGlzdEFkbWluLnB5CUZyaSBKYW4gIDgg MDk6MzA6MjIgMTk5OQ0KQEAgLTI3LDcgKzI3LDcgQEANCiBpbXBvcnQgRXJy b3JzDQogaW1wb3J0IE1lc3NhZ2UNCiBpbXBvcnQgVXRpbHMNCi0NCitpbXBv cnQgbW1fY2ZnDQogDQogY2xhc3MgTGlzdEFkbWluOg0KICAgICBkZWYgSW5p dFZhcnMoc2VsZik6DQpAQCAtNTUsNyArNTUsNyBAQA0KICAgICAgICAgICAg ICAgICAgICAgeyd1c2VybmFtZScgICA6IHdobywNCiAgICAgICAgICAgICAg ICAgICAgICAnbGlzdG5hbWUnICAgOiBzZWxmLnJlYWxfbmFtZSwNCiAgICAg ICAgICAgICAgICAgICAgICAnaG9zdG5hbWUnICAgOiBzZWxmLmhvc3RfbmFt ZSwNCi0gICAgICAgICAgICAgICAgICAgICAnYWRtaW5kYl91cmwnOiBzZWxm LkdldEFic29sdXRlU2NyaXB0VVJMKCdhZG1pbmRiJyksDQorICAgICAgICAg ICAgICAgICAgICAgJ2FkbWluZGJfdXJsJzogc2VsZi5HZXRBYnNvbHV0ZVNj cmlwdFVSTChtbV9jZmcuYWRtaW5kYl9jZ2kpLA0KICAgICAgICAgICAgICAg ICAgICAgIH0pDQogCQlzZWxmLlNlbmRUZXh0VG9Vc2VyKHN1YmplY3QgPSBz dWJqLA0KIAkJCQkgICAgcmVjaXBpZW50ID0gc2VsZi5HZXRBZG1pbkVtYWls KCksDQpAQCAtNzgsNyArNzgsNyBAQA0KICAgICAgICAgICAgICAgICAgICAg ICdyZWFzb24nICAgICA6IHJlYXNvbiwNCiAgICAgICAgICAgICAgICAgICAg ICAnc2VuZGVyJyAgICAgOiBzZW5kZXIsDQogICAgICAgICAgICAgICAgICAg ICAgJ3N1YmplY3QnICAgIDogc3ViamVjdCwNCi0gICAgICAgICAgICAgICAg ICAgICAnYWRtaW5kYl91cmwnOiBzZWxmLkdldEFic29sdXRlU2NyaXB0VVJM KCdhZG1pbmRiJyksDQorICAgICAgICAgICAgICAgICAgICAgJ2FkbWluZGJf dXJsJzogc2VsZi5HZXRBYnNvbHV0ZVNjcmlwdFVSTChtbV9jZmcuYWRtaW5k Yl9jZ2kpLA0KICAgICAgICAgICAgICAgICAgICAgIH0pDQogCQlzZWxmLlNl bmRUZXh0VG9Vc2VyKHN1YmplY3QgPSBzdWJqLA0KIAkJCQkgICAgcmVjaXBp ZW50ID0gc2VsZi5HZXRBZG1pbkVtYWlsKCksDQpkaWZmIC1ydU4gbWFpbG1h bi0xLWNtZGhhbmRsZXIvTWFpbG1hbi9NYWlsQ29tbWFuZEhhbmRsZXIucHkg bWFpbG1hbi9NYWlsbWFuL01haWxDb21tYW5kSGFuZGxlci5weQ0KLS0tIG1h aWxtYW4tMS1jbWRoYW5kbGVyL01haWxtYW4vTWFpbENvbW1hbmRIYW5kbGVy LnB5CUZyaSBKYW4gIDggMDk6Mjk6MDkgMTk5OQ0KKysrIG1haWxtYW4vTWFp bG1hbi9NYWlsQ29tbWFuZEhhbmRsZXIucHkJRnJpIEphbiAgOCAwOTozMDoy MiAxOTk5DQpAQCAtMzM1LDcgKzMzNSw3IEBADQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgIiBiYWNrZ3JvdW5kIiAlIHNlbGYucmVhbF9uYW1lKQ0K ICAgICAgICAgc2VsZi5BZGRUb1Jlc3BvbnNlKCJhbmQgaW5zdHJ1Y3Rpb25z IGZvciBzdWJzY3JpYmluZyB0byBhbmQiDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgIiB1c2luZyBpdCwgdmlzaXQ6XG5cblx0JXNcbiINCi0gICAg ICAgICAgICAgICAgICAgICAgICAgICAlIHNlbGYuR2V0QWJzb2x1dGVTY3Jp cHRVUkwoJ2xpc3RpbmZvJykpDQorICAgICAgICAgICAgICAgICAgICAgICAg ICAgJSBzZWxmLkdldEFic29sdXRlU2NyaXB0VVJMKG1tX2NmZy5saXN0aW5m b19jZ2kpKQ0KIA0KIAlpZiBub3Qgc2VsZi5pbmZvOg0KIAkgICAgc2VsZi5B ZGRUb1Jlc3BvbnNlKCJObyBvdGhlciBkZXRhaWxzIGFib3V0ICVzIGFyZSBh dmFpbGFibGUuIiAlDQpAQCAtNTUzLDcgKzU1Myw3IEBADQogICAgICAgICAg ICAgJ2hlbHAudHh0JywNCiAgICAgICAgICAgICB7J2xpc3RuYW1lJyAgICA6 IHNlbGYucmVhbF9uYW1lLA0KICAgICAgICAgICAgICAndmVyc2lvbicgICAg IDogbW1fY2ZnLlZFUlNJT04sDQotICAgICAgICAgICAgICdsaXN0aW5mb191 cmwnOiBzZWxmLkdldEFic29sdXRlU2NyaXB0VVJMKCdsaXN0aW5mbycpLA0K KyAgICAgICAgICAgICAnbGlzdGluZm9fdXJsJzogc2VsZi5HZXRBYnNvbHV0 ZVNjcmlwdFVSTChtbV9jZmcubGlzdGluZm9fY2dpKSwNCiAgICAgICAgICAg ICAgJ3JlcXVlc3RhZGRyJyA6IHNlbGYuR2V0UmVxdWVzdEVtYWlsKCksDQog ICAgICAgICAgICAgICdhZG1pbmFkZHInICAgOiBzZWxmLkdldEFkbWluRW1h aWwoKSwNCiAgICAgICAgICAgICAgfSkNCmRpZmYgLXJ1TiBtYWlsbWFuLTEt Y21kaGFuZGxlci9NYWlsbWFuL01haWxMaXN0LnB5IG1haWxtYW4vTWFpbG1h bi9NYWlsTGlzdC5weQ0KLS0tIG1haWxtYW4tMS1jbWRoYW5kbGVyL01haWxt YW4vTWFpbExpc3QucHkJRnJpIEphbiAgOCAwOToxODoxNiAxOTk5DQorKysg bWFpbG1hbi9NYWlsbWFuL01haWxMaXN0LnB5CUZyaSBKYW4gIDggMDk6MzA6 MjIgMTk5OQ0KQEAgLTE1NCw3ICsxNTQsNyBAQA0KIA0KIA0KICAgICBkZWYg R2V0QWJzb2x1dGVPcHRpb25zVVJMKHNlbGYsIGFkZHIsIG9ic2N1cmVkPTAs KToNCi0Jb3B0aW9ucyA9IHNlbGYuR2V0QWJzb2x1dGVTY3JpcHRVUkwoJ29w dGlvbnMnKQ0KKwlvcHRpb25zID0gc2VsZi5HZXRBYnNvbHV0ZVNjcmlwdFVS TChtbV9jZmcub3B0aW9uc19jZ2kpDQogICAgICAgICBpZiBvYnNjdXJlZDoN CiAgICAgICAgICAgICB0cmVhdGVkID0gVXRpbHMuT2JzY3VyZUVtYWlsKGFk ZHIsIGZvcl90ZXh0PTApDQogICAgICAgICBlbHNlOg0KQEAgLTQ5Nyw3ICs0 OTcsNyBAQA0KICAgICAgICAgICAgICIgY292ZXJpbmcgbWVtYmVycyBhbmQg b3V0c2lkZXJzLiINCiAgICAgICAgICAgICAnICAoU2VlIGFsc28gdGhlIDxh IGhyZWY9IiVzL2FyY2hpdmUiPkFyY2hpdmFsIE9wdGlvbnMnDQogICAgICAg ICAgICAgJyBzZWN0aW9uPC9hPiBmb3Igc2VwYXJhdGUgYXJjaGl2ZS1wcml2 YWN5IHNldHRpbmdzLiknDQotICAgICAgICAgICAgJSAoc2VsZi5HZXRSZWxh dGl2ZVNjcmlwdFVSTCgnYWRtaW4nKSksDQorICAgICAgICAgICAgJSAoc2Vs Zi5HZXRSZWxhdGl2ZVNjcmlwdFVSTChtbV9jZmcuYWRtaW5fY2dpKSksDQog DQogCSAgICAiU3Vic2NyaWJpbmciLA0KIA0KZGlmZiAtcnVOIG1haWxtYW4t MS1jbWRoYW5kbGVyL01haWxtYW4vbW1fY2ZnLnB5LmRpc3QuaW4gbWFpbG1h bi9NYWlsbWFuL21tX2NmZy5weS5kaXN0LmluDQotLS0gbWFpbG1hbi0xLWNt ZGhhbmRsZXIvTWFpbG1hbi9tbV9jZmcucHkuZGlzdC5pbglGcmkgSnVuIDE5 IDIyOjExOjMyIDE5OTgNCisrKyBtYWlsbWFuL01haWxtYW4vbW1fY2ZnLnB5 LmRpc3QuaW4JRnJpIEphbiAgOCAwOTozMDoyMiAxOTk5DQpAQCAtNTIsOCAr NTIsOCBAQA0KIA0KIE1BSUxNQU5fT1dORVIgICAgID0gJ21haWxtYW4tb3du ZXJAJXMnICUgREVGQVVMVF9IT1NUX05BTUUNCiANCi1QVUJMSUNfQVJDSElW RV9VUkwgPSAnL3BpcGVybWFpbCcNCi1QUklWQVRFX0FSQ0hJVkVfVVJMID0g Jy9tYWlsbWFuL3ByaXZhdGUnDQorUFVCTElDX0FSQ0hJVkVfVVJMID0gJy9w aXBlcm1haWxAQ0dJRVhUQCcNCitQUklWQVRFX0FSQ0hJVkVfVVJMID0gJy9t YWlsbWFuL3ByaXZhdGVAQ0dJRVhUQCcNCiANCiAjIE5vdGUgLSBpZiB5b3Un cmUgbG9va2luZyBmb3Igc29tZXRoaW5nIHRoYXQgaXMgaW1wb3J0ZWQgZnJv bSBtbV9jZmcsIGJ1dCB5b3UNCiAjIGRpZG4ndCBmaW5kIGl0IGFib3ZlLCBp dCdzIHByb2JhYmx5IGluIERlZmF1bHRzLnB5Lg0KZGlmZiAtcnVOIG1haWxt YW4tMS1jbWRoYW5kbGVyL2Jpbi9hZGRfbWVtYmVycyBtYWlsbWFuL2Jpbi9h ZGRfbWVtYmVycw0KLS0tIG1haWxtYW4tMS1jbWRoYW5kbGVyL2Jpbi9hZGRf bWVtYmVycwlUaHUgRGVjIDE3IDExOjAwOjE3IDE5OTgNCisrKyBtYWlsbWFu L2Jpbi9hZGRfbWVtYmVycwlGcmkgSmFuICA4IDA5OjMwOjIyIDE5OTkNCkBA IC05Myw3ICs5Myw3IEBADQogICAgIGRpY3QgPSB7J2xpc3RuYW1lJyAgICA6 IG1sLnJlYWxfbmFtZSwNCiAgICAgICAgICAgICAnbGlzdGhvc3QnICAgIDog bWwuaG9zdF9uYW1lLA0KICAgICAgICAgICAgICdsaXN0YWRkcicgICAgOiBt bC5HZXRMaXN0RW1haWwoKSwNCi0gICAgICAgICAgICAnbGlzdGluZm9fdXJs JzogbWwuR2V0QWJzb2x1dGVTY3JpcHRVUkwoJ2xpc3RpbmZvJyksDQorICAg ICAgICAgICAgJ2xpc3RpbmZvX3VybCc6IG1sLkdldEFic29sdXRlU2NyaXB0 VVJMKG1tX2NmZy5saXN0aW5mb19jZ2kpLA0KICAgICAgICAgICAgICdyZXF1 ZXN0YWRkcicgOiBtbC5HZXRSZXF1ZXN0RW1haWwoKSwNCiAgICAgICAgICAg ICAnYWRtaW5hZGRyJyAgIDogbWwuR2V0QWRtaW5FbWFpbCgpLA0KICAgICAg ICAgICAgICd2ZXJzaW9uJyAgICAgOiBNYWlsbWFuLm1tX2NmZy5WRVJTSU9O LA0KZGlmZiAtcnVOIG1haWxtYW4tMS1jbWRoYW5kbGVyL2Jpbi9uZXdsaXN0 IG1haWxtYW4vYmluL25ld2xpc3QNCi0tLSBtYWlsbWFuLTEtY21kaGFuZGxl ci9iaW4vbmV3bGlzdAlUaHUgT2N0IDIyIDA5OjI5OjI3IDE5OTgNCisrKyBt YWlsbWFuL2Jpbi9uZXdsaXN0CUZyaSBKYW4gIDggMDk6MzA6MjIgMTk5OQ0K QEAgLTEyMCw4ICsxMjAsOCBAQA0KICAgICAgICAgJ25ld2xpc3QudHh0JywN CiAgICAgICAgIHsnbGlzdG5hbWUnICAgIDogbGlzdF9uYW1lLA0KICAgICAg ICAgICdwYXNzd29yZCcgICAgOiBsaXN0X3B3LCANCi0gICAgICAgICAnYWRt aW5fdXJsJyAgIDogbmV3bGlzdC5HZXRBYnNvbHV0ZVNjcmlwdFVSTCgnYWRt aW4nKSwgDQotICAgICAgICAgJ2xpc3RpbmZvX3VybCc6IG5ld2xpc3QuR2V0 QWJzb2x1dGVTY3JpcHRVUkwoJ2xpc3RpbmZvJyksDQorICAgICAgICAgJ2Fk bWluX3VybCcgICA6IG5ld2xpc3QuR2V0QWJzb2x1dGVTY3JpcHRVUkwobW1f Y2ZnLmFkbWluX2NnaSksIA0KKyAgICAgICAgICdsaXN0aW5mb191cmwnOiBu ZXdsaXN0LkdldEFic29sdXRlU2NyaXB0VVJMKG1tX2NmZy5saXN0aW5mb19j Z2kpLA0KICAgICAgICAgICdyZXF1ZXN0YWRkcicgOiAiJXMtcmVxdWVzdEAl cyIgJSAobGlzdF9uYW1lLCBuZXdsaXN0Lmhvc3RfbmFtZSksDQogICAgICAg ICAgJ2hvc3RuYW1lJyAgICA6IG5ld2xpc3QuaG9zdF9uYW1lLA0KICAgICAg ICAgIH0pDQpkaWZmIC1ydU4gbWFpbG1hbi0xLWNtZGhhbmRsZXIvY29uZmln dXJlIG1haWxtYW4vY29uZmlndXJlDQotLS0gbWFpbG1hbi0xLWNtZGhhbmRs ZXIvY29uZmlndXJlCUZyaSBKYW4gIDggMDk6MzA6MTUgMTk5OQ0KKysrIG1h aWxtYW4vY29uZmlndXJlCUZyaSBKYW4gIDggMDk6MzI6MjkgMTk5OQ0KQEAg LTI1LDYgKzI1LDkgQEANCiBhY19oZWxwPSIkYWNfaGVscA0KIA0KIAktLXdp dGgtY2dpLWdpZCAgCXNwZWNpZnkgR0lEIENHSSBwcm9ncmFtcyBydW4gYXMi DQorYWNfaGVscD0iJGFjX2hlbHANCisNCisgICAgICAgLS13aXRoLWNnaS1l eHQgICAgICAgIHNwZWNpZnkgZXh0ZW5zaW9ucyBvZiBDR0kgcHJvZ3JhbXMi DQogDQogIyBJbml0aWFsaXplIHNvbWUgdmFyaWFibGVzIHNldCBieSBvcHRp b25zLg0KICMgVGhlIHZhcmlhYmxlcyBoYXZlIHRoZSBzYW1lIG5hbWVzIGFz IHRoZSBvcHRpb25zLCB3aXRoDQpAQCAtNTQ1LDcgKzU0OCw3IEBADQogDQog IyBDaGVjayBmb3IgUHl0aG9uISAgQmV0dGVyIGJlIGZvdW5kIG9uICRQQVRI DQogZWNobyAkYWNfbiAiY2hlY2tpbmcgZm9yIC0td2l0aC1weXRob24iIi4u LiAkYWNfYyIgMT4mNg0KLWVjaG8gImNvbmZpZ3VyZTo1NDk6IGNoZWNraW5n IGZvciAtLXdpdGgtcHl0aG9uIiA+JjUNCitlY2hvICJjb25maWd1cmU6NTUy OiBjaGVja2luZyBmb3IgLS13aXRoLXB5dGhvbiIgPiY1DQogIyBDaGVjayB3 aGV0aGVyIC0td2l0aC1weXRob24gb3IgLS13aXRob3V0LXB5dGhvbiB3YXMg Z2l2ZW4uDQogaWYgdGVzdCAiJHt3aXRoX3B5dGhvbitzZXR9IiA9IHNldDsg dGhlbg0KICAgd2l0aHZhbD0iJHdpdGhfcHl0aG9uIg0KQEAgLTU1OSw3ICs1 NjIsNyBAQA0KIAkjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgInB5dGhv biIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuDQog c2V0IGR1bW15IHB5dGhvbjsgYWNfd29yZD0kMg0KIGVjaG8gJGFjX24gImNo ZWNraW5nIGZvciAkYWNfd29yZCIiLi4uICRhY19jIiAxPiY2DQotZWNobyAi Y29uZmlndXJlOjU2MzogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUNCitl Y2hvICJjb25maWd1cmU6NTY2OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4m NQ0KIGlmIGV2YWwgInRlc3QgXCJgZWNobyAnJCcneydhY19jdl9wYXRoX3dp dGhfcHl0aG9uJytzZXR9J2BcIiA9IHNldCI7IHRoZW4NCiAgIGVjaG8gJGFj X24gIihjYWNoZWQpICRhY19jIiAxPiY2DQogZWxzZQ0KQEAgLTU5MSw3ICs1 OTQsNyBAQA0KIGZpDQogDQogZWNobyAkYWNfbiAiY2hlY2tpbmcgUHl0aG9u IGludGVycHJldGVyIiIuLi4gJGFjX2MiIDE+JjYNCi1lY2hvICJjb25maWd1 cmU6NTk1OiBjaGVja2luZyBQeXRob24gaW50ZXJwcmV0ZXIiID4mNQ0KK2Vj aG8gImNvbmZpZ3VyZTo1OTg6IGNoZWNraW5nIFB5dGhvbiBpbnRlcnByZXRl ciIgPiY1DQogaWYgdGVzdCAhIC14ICR3aXRoX3B5dGhvbg0KIHRoZW4NCiAg ICAgeyBlY2hvICJjb25maWd1cmU6IGVycm9yOiANCkBAIC02MzUsNyArNjM4 LDcgQEANCiAjIFNWUjQgL3Vzci91Y2IvaW5zdGFsbCwgd2hpY2ggdHJpZXMg dG8gdXNlIHRoZSBub25leGlzdGVudCBncm91cCAic3RhZmYiDQogIyAuL2lu c3RhbGwsIHdoaWNoIGNhbiBiZSBlcnJvbmVvdXNseSBjcmVhdGVkIGJ5IG1h a2UgZnJvbSAuL2luc3RhbGwuc2guDQogZWNobyAkYWNfbiAiY2hlY2tpbmcg Zm9yIGEgQlNEIGNvbXBhdGlibGUgaW5zdGFsbCIiLi4uICRhY19jIiAxPiY2 DQotZWNobyAiY29uZmlndXJlOjYzOTogY2hlY2tpbmcgZm9yIGEgQlNEIGNv bXBhdGlibGUgaW5zdGFsbCIgPiY1DQorZWNobyAiY29uZmlndXJlOjY0Mjog Y2hlY2tpbmcgZm9yIGEgQlNEIGNvbXBhdGlibGUgaW5zdGFsbCIgPiY1DQog aWYgdGVzdCAteiAiJElOU1RBTEwiOyB0aGVuDQogaWYgZXZhbCAidGVzdCBc ImBlY2hvICckJyd7J2FjX2N2X3BhdGhfaW5zdGFsbCcrc2V0fSdgXCIgPSBz ZXQiOyB0aGVuDQogICBlY2hvICRhY19uICIoY2FjaGVkKSAkYWNfYyIgMT4m Ng0KQEAgLTY4NSw3ICs2ODgsNyBAQA0KIHRlc3QgLXogIiRJTlNUQUxMX0RB VEEiICYmIElOU1RBTExfREFUQT0nJHtJTlNUQUxMfSAtbSA2NDQnDQogDQog ZWNobyAkYWNfbiAiY2hlY2tpbmcgd2hldGhlciAke01BS0UtbWFrZX0gc2V0 cyBcJHtNQUtFfSIiLi4uICRhY19jIiAxPiY2DQotZWNobyAiY29uZmlndXJl OjY4OTogY2hlY2tpbmcgd2hldGhlciAke01BS0UtbWFrZX0gc2V0cyBcJHtN QUtFfSIgPiY1DQorZWNobyAiY29uZmlndXJlOjY5MjogY2hlY2tpbmcgd2hl dGhlciAke01BS0UtbWFrZX0gc2V0cyBcJHtNQUtFfSIgPiY1DQogc2V0IGR1 bW15ICR7TUFLRS1tYWtlfTsgYWNfbWFrZT1gZWNobyAiJDIiIHwgc2VkICd5 JS4vKy0lX19wXyUnYA0KIGlmIGV2YWwgInRlc3QgXCJgZWNobyAnJCcneydh Y19jdl9wcm9nX21ha2VfJHthY19tYWtlfV9zZXQnK3NldH0nYFwiID0gc2V0 IjsgdGhlbg0KICAgZWNobyAkYWNfbiAiKGNhY2hlZCkgJGFjX2MiIDE+JjYN CkBAIC03MTQsNyArNzE3LDcgQEANCiANCiAjIEZpbmQgY29tcGlsZXIsIGFs bG93IGFsdGVybmF0aXZlcyB0byBnY2MNCiBlY2hvICRhY19uICJjaGVja2lu ZyBmb3IgLS13aXRob3V0LWdjYyIiLi4uICRhY19jIiAxPiY2DQotZWNobyAi Y29uZmlndXJlOjcxODogY2hlY2tpbmcgZm9yIC0td2l0aG91dC1nY2MiID4m NQ0KK2VjaG8gImNvbmZpZ3VyZTo3MjE6IGNoZWNraW5nIGZvciAtLXdpdGhv dXQtZ2NjIiA+JjUNCiAjIENoZWNrIHdoZXRoZXIgLS13aXRoLWdjYyBvciAt LXdpdGhvdXQtZ2NjIHdhcyBnaXZlbi4NCiBpZiB0ZXN0ICIke3dpdGhfZ2Nj K3NldH0iID0gc2V0OyB0aGVuDQogICB3aXRodmFsPSIkd2l0aF9nY2MiDQpA QCAtNzQzLDcgKzc0Niw3IEBADQogIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3Jk IG9mICJnY2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBh cmdzLg0KIHNldCBkdW1teSBnY2M7IGFjX3dvcmQ9JDINCiBlY2hvICRhY19u ICJjaGVja2luZyBmb3IgJGFjX3dvcmQiIi4uLiAkYWNfYyIgMT4mNg0KLWVj aG8gImNvbmZpZ3VyZTo3NDc6IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1 DQorZWNobyAiY29uZmlndXJlOjc1MDogY2hlY2tpbmcgZm9yICRhY193b3Jk IiA+JjUNCiBpZiBldmFsICJ0ZXN0IFwiYGVjaG8gJyQnJ3snYWNfY3ZfcHJv Z19DQycrc2V0fSdgXCIgPSBzZXQiOyB0aGVuDQogICBlY2hvICRhY19uICIo Y2FjaGVkKSAkYWNfYyIgMT4mNg0KIGVsc2UNCkBAIC03NzIsNyArNzc1LDcg QEANCiAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiY2MiLCBzbyBp dCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLg0KIHNldCBkdW1t eSBjYzsgYWNfd29yZD0kMg0KIGVjaG8gJGFjX24gImNoZWNraW5nIGZvciAk YWNfd29yZCIiLi4uICRhY19jIiAxPiY2DQotZWNobyAiY29uZmlndXJlOjc3 NjogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUNCitlY2hvICJjb25maWd1 cmU6Nzc5OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQ0KIGlmIGV2YWwg InRlc3QgXCJgZWNobyAnJCcneydhY19jdl9wcm9nX0NDJytzZXR9J2BcIiA9 IHNldCI7IHRoZW4NCiAgIGVjaG8gJGFjX24gIihjYWNoZWQpICRhY19jIiAx PiY2DQogZWxzZQ0KQEAgLTgyMCw3ICs4MjMsNyBAQA0KIGZpDQogDQogZWNo byAkYWNfbiAiY2hlY2tpbmcgd2hldGhlciB0aGUgQyBjb21waWxlciAoJEND ICRDRkxBR1MgJExERkxBR1MpIHdvcmtzIiIuLi4gJGFjX2MiIDE+JjYNCi1l Y2hvICJjb25maWd1cmU6ODI0OiBjaGVja2luZyB3aGV0aGVyIHRoZSBDIGNv bXBpbGVyICgkQ0MgJENGTEFHUyAkTERGTEFHUykgd29ya3MiID4mNQ0KK2Vj aG8gImNvbmZpZ3VyZTo4Mjc6IGNoZWNraW5nIHdoZXRoZXIgdGhlIEMgY29t cGlsZXIgKCRDQyAkQ0ZMQUdTICRMREZMQUdTKSB3b3JrcyIgPiY1DQogDQog YWNfZXh0PWMNCiAjIENGTEFHUyBpcyBub3QgaW4gYWNfY3BwIGJlY2F1c2Ug LWcsIC1PLCBldGMuIGFyZSBub3QgdmFsaWQgY3BwIG9wdGlvbnMuDQpAQCAt ODMwLDExICs4MzMsMTEgQEANCiBjcm9zc19jb21waWxpbmc9JGFjX2N2X3By b2dfY2NfY3Jvc3MNCiANCiBjYXQgPiBjb25mdGVzdC4kYWNfZXh0IDw8RU9G DQotI2xpbmUgODM0ICJjb25maWd1cmUiDQorI2xpbmUgODM3ICJjb25maWd1 cmUiDQogI2luY2x1ZGUgImNvbmZkZWZzLmgiDQogbWFpbigpe3JldHVybigw KTt9DQogRU9GDQotaWYgeyAoZXZhbCBlY2hvIGNvbmZpZ3VyZTo4Mzg6IFwi JGFjX2xpbmtcIikgMT4mNTsgKGV2YWwgJGFjX2xpbmspIDI+JjU7IH0gJiYg dGVzdCAtcyBjb25mdGVzdDsgdGhlbg0KK2lmIHsgKGV2YWwgZWNobyBjb25m aWd1cmU6ODQxOiBcIiRhY19saW5rXCIpIDE+JjU7IChldmFsICRhY19saW5r KSAyPiY1OyB9ICYmIHRlc3QgLXMgY29uZnRlc3Q7IHRoZW4NCiAgIGFjX2N2 X3Byb2dfY2Nfd29ya3M9eWVzDQogICAjIElmIHdlIGNhbid0IHJ1biBhIHRy aXZpYWwgcHJvZ3JhbSwgd2UgYXJlIHByb2JhYmx5IHVzaW5nIGEgY3Jvc3Mg Y29tcGlsZXIuDQogICBpZiAoLi9jb25mdGVzdDsgZXhpdCkgMj4vZGV2L251 bGw7IHRoZW4NCkBAIC04NTQsMTIgKzg1NywxMiBAQA0KICAgeyBlY2hvICJj b25maWd1cmU6IGVycm9yOiBpbnN0YWxsYXRpb24gb3IgY29uZmlndXJhdGlv biBwcm9ibGVtOiBDIGNvbXBpbGVyIGNhbm5vdCBjcmVhdGUgZXhlY3V0YWJs ZXMuIiAxPiYyOyBleGl0IDE7IH0NCiBmaQ0KIGVjaG8gJGFjX24gImNoZWNr aW5nIHdoZXRoZXIgdGhlIEMgY29tcGlsZXIgKCRDQyAkQ0ZMQUdTICRMREZM QUdTKSBpcyBhIGNyb3NzLWNvbXBpbGVyIiIuLi4gJGFjX2MiIDE+JjYNCi1l Y2hvICJjb25maWd1cmU6ODU4OiBjaGVja2luZyB3aGV0aGVyIHRoZSBDIGNv bXBpbGVyICgkQ0MgJENGTEFHUyAkTERGTEFHUykgaXMgYSBjcm9zcy1jb21w aWxlciIgPiY1DQorZWNobyAiY29uZmlndXJlOjg2MTogY2hlY2tpbmcgd2hl dGhlciB0aGUgQyBjb21waWxlciAoJENDICRDRkxBR1MgJExERkxBR1MpIGlz IGEgY3Jvc3MtY29tcGlsZXIiID4mNQ0KIGVjaG8gIiRhY190IiIkYWNfY3Zf cHJvZ19jY19jcm9zcyIgMT4mNg0KIGNyb3NzX2NvbXBpbGluZz0kYWNfY3Zf cHJvZ19jY19jcm9zcw0KIA0KIGVjaG8gJGFjX24gImNoZWNraW5nIHdoZXRo ZXIgd2UgYXJlIHVzaW5nIEdOVSBDIiIuLi4gJGFjX2MiIDE+JjYNCi1lY2hv ICJjb25maWd1cmU6ODYzOiBjaGVja2luZyB3aGV0aGVyIHdlIGFyZSB1c2lu ZyBHTlUgQyIgPiY1DQorZWNobyAiY29uZmlndXJlOjg2NjogY2hlY2tpbmcg d2hldGhlciB3ZSBhcmUgdXNpbmcgR05VIEMiID4mNQ0KIGlmIGV2YWwgInRl c3QgXCJgZWNobyAnJCcneydhY19jdl9wcm9nX2djYycrc2V0fSdgXCIgPSBz ZXQiOyB0aGVuDQogICBlY2hvICRhY19uICIoY2FjaGVkKSAkYWNfYyIgMT4m Ng0KIGVsc2UNCkBAIC04NjgsNyArODcxLDcgQEANCiAgIHllczsNCiAjZW5k aWYNCiBFT0YNCi1pZiB7IGFjX3RyeT0nJHtDQy1jY30gLUUgY29uZnRlc3Qu Yyc7IHsgKGV2YWwgZWNobyBjb25maWd1cmU6ODcyOiBcIiRhY190cnlcIikg MT4mNTsgKGV2YWwgJGFjX3RyeSkgMj4mNTsgfTsgfSB8IGVncmVwIHllcyA+ L2Rldi9udWxsIDI+JjE7IHRoZW4NCitpZiB7IGFjX3RyeT0nJHtDQy1jY30g LUUgY29uZnRlc3QuYyc7IHsgKGV2YWwgZWNobyBjb25maWd1cmU6ODc1OiBc IiRhY190cnlcIikgMT4mNTsgKGV2YWwgJGFjX3RyeSkgMj4mNTsgfTsgfSB8 IGVncmVwIHllcyA+L2Rldi9udWxsIDI+JjE7IHRoZW4NCiAgIGFjX2N2X3By b2dfZ2NjPXllcw0KIGVsc2UNCiAgIGFjX2N2X3Byb2dfZ2NjPW5vDQpAQCAt ODgzLDcgKzg4Niw3IEBADQogICBhY19zYXZlX0NGTEFHUz0iJENGTEFHUyIN CiAgIENGTEFHUz0NCiAgIGVjaG8gJGFjX24gImNoZWNraW5nIHdoZXRoZXIg JHtDQy1jY30gYWNjZXB0cyAtZyIiLi4uICRhY19jIiAxPiY2DQotZWNobyAi Y29uZmlndXJlOjg4NzogY2hlY2tpbmcgd2hldGhlciAke0NDLWNjfSBhY2Nl cHRzIC1nIiA+JjUNCitlY2hvICJjb25maWd1cmU6ODkwOiBjaGVja2luZyB3 aGV0aGVyICR7Q0MtY2N9IGFjY2VwdHMgLWciID4mNQ0KIGlmIGV2YWwgInRl c3QgXCJgZWNobyAnJCcneydhY19jdl9wcm9nX2NjX2cnK3NldH0nYFwiID0g c2V0IjsgdGhlbg0KICAgZWNobyAkYWNfbiAiKGNhY2hlZCkgJGFjX2MiIDE+ JjYNCiBlbHNlDQpAQCAtOTMxLDcgKzkzNCw3IEBADQogIyBQdWxsIHRoZSBo YXNoIG1hcmsgb3V0IG9mIHRoZSBtYWNybyBjYWxsIHRvIGF2b2lkIG00IHBy b2JsZW1zLg0KIGFjX21zZz0id2hldGhlciAjISB3b3JrcyBpbiBzaGVsbCBz Y3JpcHRzIg0KIGVjaG8gJGFjX24gImNoZWNraW5nICRhY19tc2ciIi4uLiAk YWNfYyIgMT4mNg0KLWVjaG8gImNvbmZpZ3VyZTo5MzU6IGNoZWNraW5nICRh Y19tc2ciID4mNQ0KK2VjaG8gImNvbmZpZ3VyZTo5Mzg6IGNoZWNraW5nICRh Y19tc2ciID4mNQ0KIGlmIGV2YWwgInRlc3QgXCJgZWNobyAnJCcneydhY19j dl9zeXNfaW50ZXJwcmV0ZXInK3NldH0nYFwiID0gc2V0IjsgdGhlbg0KICAg ZWNobyAkYWNfbiAiKGNhY2hlZCkgJGFjX2MiIDE+JjYNCiBlbHNlDQpAQCAt OTY4LDcgKzk3MSw3IEBADQogDQogIyBVc2VyIGBtYWlsbWFuJyBtdXN0IGV4 aXN0DQogZWNobyAkYWNfbiAiY2hlY2tpbmcgZm9yIG1haWxtYW4gVUlEIiIu Li4gJGFjX2MiIDE+JjYNCi1lY2hvICJjb25maWd1cmU6OTcyOiBjaGVja2lu ZyBmb3IgbWFpbG1hbiBVSUQiID4mNQ0KK2VjaG8gImNvbmZpZ3VyZTo5NzU6 IGNoZWNraW5nIGZvciBtYWlsbWFuIFVJRCIgPiY1DQogDQogIyBNQUlMTUFO X1VJRCA9PSB2YXJpYWJsZSBuYW1lDQogIyBtYWlsbWFuID09IHVzZXIgaWQg dG8gY2hlY2sgZm9yDQpAQCAtMTAxMSw3ICsxMDE0LDcgQEANCiANCiAjIEdy b3VwIGBtYWlsbWFuJyBtdXN0IGV4aXN0DQogZWNobyAkYWNfbiAiY2hlY2tp bmcgZm9yIG1haWxtYW4gR0lEIiIuLi4gJGFjX2MiIDE+JjYNCi1lY2hvICJj b25maWd1cmU6MTAxNTogY2hlY2tpbmcgZm9yIG1haWxtYW4gR0lEIiA+JjUN CitlY2hvICJjb25maWd1cmU6MTAxODogY2hlY2tpbmcgZm9yIG1haWxtYW4g R0lEIiA+JjUNCiANCiAjIE1BSUxNQU5fR0lEID09IHZhcmlhYmxlIG5hbWUN CiAjIG1haWxtYW4gPT0gdXNlciBpZCB0byBjaGVjayBmb3INCkBAIC0xMDYz LDcgKzEwNjYsNyBAQA0KIGZpDQogDQogZWNobyAkYWNfbiAiY2hlY2tpbmcg cGVybWlzc2lvbnMgb24gJHByZWZpeGNoZWNrIiIuLi4gJGFjX2MiIDE+JjYN Ci1lY2hvICJjb25maWd1cmU6MTA2NzogY2hlY2tpbmcgcGVybWlzc2lvbnMg b24gJHByZWZpeGNoZWNrIiA+JjUNCitlY2hvICJjb25maWd1cmU6MTA3MDog Y2hlY2tpbmcgcGVybWlzc2lvbnMgb24gJHByZWZpeGNoZWNrIiA+JjUNCiAN CiBjYXQgPiBjb25mdGVzdC5weSA8PEVPRg0KIGltcG9ydCBvcywgZ3JwLCBz dHJpbmcNCkBAIC0xMTA5LDcgKzExMTIsNyBAQA0KICMgTm93IGZpbmQgdGhl IFVJRHMgYW5kIEdJRHMNCiAjIFN1cHBvcnQgLS13aXRoLW1haWwtZ2lkIGFu ZCAtLXdpdGgtY2dpLWdpZA0KIGVjaG8gJGFjX24gImNoZWNraW5nIGZvciBt YWlsIHdyYXBwZXIgR0lEIiIuLi4gJGFjX2MiIDE+JjYNCi1lY2hvICJjb25m aWd1cmU6MTExMzogY2hlY2tpbmcgZm9yIG1haWwgd3JhcHBlciBHSUQiID4m NQ0KK2VjaG8gImNvbmZpZ3VyZToxMTE2OiBjaGVja2luZyBmb3IgbWFpbCB3 cmFwcGVyIEdJRCIgPiY1DQogIyBDaGVjayB3aGV0aGVyIC0td2l0aC1tYWls LWdpZCBvciAtLXdpdGhvdXQtbWFpbC1naWQgd2FzIGdpdmVuLg0KIGlmIHRl c3QgIiR7d2l0aF9tYWlsX2dpZCtzZXR9IiA9IHNldDsgdGhlbg0KICAgd2l0 aHZhbD0iJHdpdGhfbWFpbF9naWQiDQpAQCAtMTE3MCw3ICsxMTczLDcgQEAN CiANCiANCiBlY2hvICRhY19uICJjaGVja2luZyBmb3IgQ0dJIHdyYXBwZXIg R0lEIiIuLi4gJGFjX2MiIDE+JjYNCi1lY2hvICJjb25maWd1cmU6MTE3NDog Y2hlY2tpbmcgZm9yIENHSSB3cmFwcGVyIEdJRCIgPiY1DQorZWNobyAiY29u ZmlndXJlOjExNzc6IGNoZWNraW5nIGZvciBDR0kgd3JhcHBlciBHSUQiID4m NQ0KICMgQ2hlY2sgd2hldGhlciAtLXdpdGgtY2dpLWdpZCBvciAtLXdpdGhv dXQtY2dpLWdpZCB3YXMgZ2l2ZW4uDQogaWYgdGVzdCAiJHt3aXRoX2NnaV9n aWQrc2V0fSIgPSBzZXQ7IHRoZW4NCiAgIHdpdGh2YWw9IiR3aXRoX2NnaV9n aWQiDQpAQCAtMTIzMCw2ICsxMjMzLDI1IEBADQogZmkNCiANCiANCisjIENH SSBleHRlbnNpb24gY2hlY2tpbmcNCisNCitlY2hvICRhY19uICJjaGVja2lu ZyBmb3IgQ0dJIGV4dGVuc2lvbiIiLi4uICRhY19jIiAxPiY2DQorZWNobyAi Y29uZmlndXJlOjEyNDA6IGNoZWNraW5nIGZvciBDR0kgZXh0ZW5zaW9uIiA+ JjUNCisjIENoZWNrIHdoZXRoZXIgLS13aXRoLWNnaS1leHQgb3IgLS13aXRo b3V0LWNnaS1leHQgd2FzIGdpdmVuLg0KK2lmIHRlc3QgIiR7d2l0aF9jZ2lf ZXh0K3NldH0iID0gc2V0OyB0aGVuDQorICB3aXRodmFsPSIkd2l0aF9jZ2lf ZXh0Ig0KKyAgOg0KK2ZpDQorDQoraWYgdGVzdCAteiAiJHdpdGhfY2dpX2V4 dCINCit0aGVuDQorICAgIENHSUVYVD0nJw0KKyAgICB3aXRoX2NnaV9leHQ9 J25vJw0KK2Vsc2UNCisgICAgQ0dJRVhUPSR3aXRoX2NnaV9leHQNCitmaQ0K K2VjaG8gIiRhY190IiIkd2l0aF9jZ2lfZXh0IiAxPiY2DQorDQogI01NX0ZJ TkRfVVNFUl9JRChBTElBU19VSUQsIG1haWxtYW4sIGFsaWFzX3dyYXBwZXIp DQogI01NX0ZJTkRfR1JPVVBfSUQoQUxJQVNfR0lELCBtYWlsLCBhbGlhc193 cmFwcGVyKQ0KIA0KQEAgLTEyNjUsMTQgKzEyODcsMTQgQEANCiAkUFlUSE9O IGNvbmZ0ZXN0LnB5DQogDQogZWNobyAkYWNfbiAiY2hlY2tpbmcgZm9yIGRl ZmF1bHQgZnVsbHkgcXVhbGlmaWVkIGhvc3QgbmFtZSIiLi4uICRhY19jIiAx PiY2DQotZWNobyAiY29uZmlndXJlOjEyNjk6IGNoZWNraW5nIGZvciBkZWZh dWx0IGZ1bGx5IHF1YWxpZmllZCBob3N0IG5hbWUiID4mNQ0KK2VjaG8gImNv bmZpZ3VyZToxMjkxOiBjaGVja2luZyBmb3IgZGVmYXVsdCBmdWxseSBxdWFs aWZpZWQgaG9zdCBuYW1lIiA+JjUNCiBpZiB0ZXN0IC16ICIkRlFETiINCiB0 aGVuDQogICAgIEZRRE49YGhlYWQgLTEgY29uZnRlc3Qub3V0YA0KIGZpDQog ZWNobyAiJGFjX3QiIiRGUUROIiAxPiY2DQogZWNobyAkYWNfbiAiY2hlY2tp bmcgZm9yIGRlZmF1bHQgVVJMIGhvc3QgY29tcG9uZW50IiIuLi4gJGFjX2Mi IDE+JjYNCi1lY2hvICJjb25maWd1cmU6MTI3NjogY2hlY2tpbmcgZm9yIGRl ZmF1bHQgVVJMIGhvc3QgY29tcG9uZW50IiA+JjUNCitlY2hvICJjb25maWd1 cmU6MTI5ODogY2hlY2tpbmcgZm9yIGRlZmF1bHQgVVJMIGhvc3QgY29tcG9u ZW50IiA+JjUNCiBpZiB0ZXN0IC16ICIkVVJMIg0KIHRoZW4NCiAgICAgVVJM PWB0YWlsIC0xIGNvbmZ0ZXN0Lm91dGANCkBAIC0xMjg0LDEyICsxMzA2LDEy IEBADQogZm9yIGFjX2Z1bmMgaW4gc3RyZXJyb3INCiBkbw0KIGVjaG8gJGFj X24gImNoZWNraW5nIGZvciAkYWNfZnVuYyIiLi4uICRhY19jIiAxPiY2DQot ZWNobyAiY29uZmlndXJlOjEyODg6IGNoZWNraW5nIGZvciAkYWNfZnVuYyIg PiY1DQorZWNobyAiY29uZmlndXJlOjEzMTA6IGNoZWNraW5nIGZvciAkYWNf ZnVuYyIgPiY1DQogaWYgZXZhbCAidGVzdCBcImBlY2hvICckJyd7J2FjX2N2 X2Z1bmNfJGFjX2Z1bmMnK3NldH0nYFwiID0gc2V0IjsgdGhlbg0KICAgZWNo byAkYWNfbiAiKGNhY2hlZCkgJGFjX2MiIDE+JjYNCiBlbHNlDQogICBjYXQg PiBjb25mdGVzdC4kYWNfZXh0IDw8RU9GDQotI2xpbmUgMTI5MyAiY29uZmln dXJlIg0KKyNsaW5lIDEzMTUgImNvbmZpZ3VyZSINCiAjaW5jbHVkZSAiY29u ZmRlZnMuaCINCiAvKiBTeXN0ZW0gaGVhZGVyIHRvIGRlZmluZSBfX3N0dWIg bWFjcm9zIGFuZCBob3BlZnVsbHkgZmV3IHByb3RvdHlwZXMsDQogICAgIHdo aWNoIGNhbiBjb25mbGljdCB3aXRoIGNoYXIgJGFjX2Z1bmMoKTsgYmVsb3cu ICAqLw0KQEAgLTEzMTIsNyArMTMzNCw3IEBADQogDQogOyByZXR1cm4gMDsg fQ0KIEVPRg0KLWlmIHsgKGV2YWwgZWNobyBjb25maWd1cmU6MTMxNjogXCIk YWNfbGlua1wiKSAxPiY1OyAoZXZhbCAkYWNfbGluaykgMj4mNTsgfSAmJiB0 ZXN0IC1zIGNvbmZ0ZXN0OyB0aGVuDQoraWYgeyAoZXZhbCBlY2hvIGNvbmZp Z3VyZToxMzM4OiBcIiRhY19saW5rXCIpIDE+JjU7IChldmFsICRhY19saW5r KSAyPiY1OyB9ICYmIHRlc3QgLXMgY29uZnRlc3Q7IHRoZW4NCiAgIHJtIC1y ZiBjb25mdGVzdCoNCiAgIGV2YWwgImFjX2N2X2Z1bmNfJGFjX2Z1bmM9eWVz Ig0KIGVsc2UNCkBAIC0xMzM5LDcgKzEzNjEsNyBAQA0KIA0KICMgQ2hlY2tz IGZvciBoZWFkZXIgZmlsZXMuDQogZWNobyAkYWNfbiAiY2hlY2tpbmcgaG93 IHRvIHJ1biB0aGUgQyBwcmVwcm9jZXNzb3IiIi4uLiAkYWNfYyIgMT4mNg0K LWVjaG8gImNvbmZpZ3VyZToxMzQzOiBjaGVja2luZyBob3cgdG8gcnVuIHRo ZSBDIHByZXByb2Nlc3NvciIgPiY1DQorZWNobyAiY29uZmlndXJlOjEzNjU6 IGNoZWNraW5nIGhvdyB0byBydW4gdGhlIEMgcHJlcHJvY2Vzc29yIiA+JjUN CiAjIE9uIFN1bnMsIHNvbWV0aW1lcyAkQ1BQIG5hbWVzIGEgZGlyZWN0b3J5 Lg0KIGlmIHRlc3QgLW4gIiRDUFAiICYmIHRlc3QgLWQgIiRDUFAiOyB0aGVu DQogICBDUFA9DQpAQCAtMTM1NCwxMyArMTM3NiwxMyBAQA0KICAgIyBPbiB0 aGUgTmVYVCwgY2MgLUUgcnVucyB0aGUgY29kZSB0aHJvdWdoIHRoZSBjb21w aWxlcidzIHBhcnNlciwNCiAgICMgbm90IGp1c3QgdGhyb3VnaCBjcHAuDQog ICBjYXQgPiBjb25mdGVzdC4kYWNfZXh0IDw8RU9GDQotI2xpbmUgMTM1OCAi Y29uZmlndXJlIg0KKyNsaW5lIDEzODAgImNvbmZpZ3VyZSINCiAjaW5jbHVk ZSAiY29uZmRlZnMuaCINCiAjaW5jbHVkZSA8YXNzZXJ0Lmg+DQogU3ludGF4 IEVycm9yDQogRU9GDQogYWNfdHJ5PSIkYWNfY3BwIGNvbmZ0ZXN0LiRhY19l eHQgPi9kZXYvbnVsbCAyPmNvbmZ0ZXN0Lm91dCINCi17IChldmFsIGVjaG8g Y29uZmlndXJlOjEzNjQ6IFwiJGFjX3RyeVwiKSAxPiY1OyAoZXZhbCAkYWNf dHJ5KSAyPiY1OyB9DQoreyAoZXZhbCBlY2hvIGNvbmZpZ3VyZToxMzg2OiBc IiRhY190cnlcIikgMT4mNTsgKGV2YWwgJGFjX3RyeSkgMj4mNTsgfQ0KIGFj X2Vycj1gZ3JlcCAtdiAnXiAqKycgY29uZnRlc3Qub3V0YA0KIGlmIHRlc3Qg LXogIiRhY19lcnIiOyB0aGVuDQogICA6DQpAQCAtMTM3MSwxMyArMTM5Mywx MyBAQA0KICAgcm0gLXJmIGNvbmZ0ZXN0Kg0KICAgQ1BQPSIke0NDLWNjfSAt RSAtdHJhZGl0aW9uYWwtY3BwIg0KICAgY2F0ID4gY29uZnRlc3QuJGFjX2V4 dCA8PEVPRg0KLSNsaW5lIDEzNzUgImNvbmZpZ3VyZSINCisjbGluZSAxMzk3 ICJjb25maWd1cmUiDQogI2luY2x1ZGUgImNvbmZkZWZzLmgiDQogI2luY2x1 ZGUgPGFzc2VydC5oPg0KIFN5bnRheCBFcnJvcg0KIEVPRg0KIGFjX3RyeT0i JGFjX2NwcCBjb25mdGVzdC4kYWNfZXh0ID4vZGV2L251bGwgMj5jb25mdGVz dC5vdXQiDQoteyAoZXZhbCBlY2hvIGNvbmZpZ3VyZToxMzgxOiBcIiRhY190 cnlcIikgMT4mNTsgKGV2YWwgJGFjX3RyeSkgMj4mNTsgfQ0KK3sgKGV2YWwg ZWNobyBjb25maWd1cmU6MTQwMzogXCIkYWNfdHJ5XCIpIDE+JjU7IChldmFs ICRhY190cnkpIDI+JjU7IH0NCiBhY19lcnI9YGdyZXAgLXYgJ14gKisnIGNv bmZ0ZXN0Lm91dGANCiBpZiB0ZXN0IC16ICIkYWNfZXJyIjsgdGhlbg0KICAg Og0KQEAgLTE0MDAsMTIgKzE0MjIsMTIgQEANCiBlY2hvICIkYWNfdCIiJENQ UCIgMT4mNg0KIA0KIGVjaG8gJGFjX24gImNoZWNraW5nIGZvciBBTlNJIEMg aGVhZGVyIGZpbGVzIiIuLi4gJGFjX2MiIDE+JjYNCi1lY2hvICJjb25maWd1 cmU6MTQwNDogY2hlY2tpbmcgZm9yIEFOU0kgQyBoZWFkZXIgZmlsZXMiID4m NQ0KK2VjaG8gImNvbmZpZ3VyZToxNDI2OiBjaGVja2luZyBmb3IgQU5TSSBD IGhlYWRlciBmaWxlcyIgPiY1DQogaWYgZXZhbCAidGVzdCBcImBlY2hvICck Jyd7J2FjX2N2X2hlYWRlcl9zdGRjJytzZXR9J2BcIiA9IHNldCI7IHRoZW4N CiAgIGVjaG8gJGFjX24gIihjYWNoZWQpICRhY19jIiAxPiY2DQogZWxzZQ0K ICAgY2F0ID4gY29uZnRlc3QuJGFjX2V4dCA8PEVPRg0KLSNsaW5lIDE0MDkg ImNvbmZpZ3VyZSINCisjbGluZSAxNDMxICJjb25maWd1cmUiDQogI2luY2x1 ZGUgImNvbmZkZWZzLmgiDQogI2luY2x1ZGUgPHN0ZGxpYi5oPg0KICNpbmNs dWRlIDxzdGRhcmcuaD4NCkBAIC0xNDEzLDcgKzE0MzUsNyBAQA0KICNpbmNs dWRlIDxmbG9hdC5oPg0KIEVPRg0KIGFjX3RyeT0iJGFjX2NwcCBjb25mdGVz dC4kYWNfZXh0ID4vZGV2L251bGwgMj5jb25mdGVzdC5vdXQiDQoteyAoZXZh bCBlY2hvIGNvbmZpZ3VyZToxNDE3OiBcIiRhY190cnlcIikgMT4mNTsgKGV2 YWwgJGFjX3RyeSkgMj4mNTsgfQ0KK3sgKGV2YWwgZWNobyBjb25maWd1cmU6 MTQzOTogXCIkYWNfdHJ5XCIpIDE+JjU7IChldmFsICRhY190cnkpIDI+JjU7 IH0NCiBhY19lcnI9YGdyZXAgLXYgJ14gKisnIGNvbmZ0ZXN0Lm91dGANCiBp ZiB0ZXN0IC16ICIkYWNfZXJyIjsgdGhlbg0KICAgcm0gLXJmIGNvbmZ0ZXN0 Kg0KQEAgLTE0MzAsNyArMTQ1Miw3IEBADQogaWYgdGVzdCAkYWNfY3ZfaGVh ZGVyX3N0ZGMgPSB5ZXM7IHRoZW4NCiAgICMgU3VuT1MgNC54IHN0cmluZy5o IGRvZXMgbm90IGRlY2xhcmUgbWVtKiwgY29udHJhcnkgdG8gQU5TSS4NCiBj YXQgPiBjb25mdGVzdC4kYWNfZXh0IDw8RU9GDQotI2xpbmUgMTQzNCAiY29u ZmlndXJlIg0KKyNsaW5lIDE0NTYgImNvbmZpZ3VyZSINCiAjaW5jbHVkZSAi Y29uZmRlZnMuaCINCiAjaW5jbHVkZSA8c3RyaW5nLmg+DQogRU9GDQpAQCAt MTQ0OCw3ICsxNDcwLDcgQEANCiBpZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3Rk YyA9IHllczsgdGhlbg0KICAgIyBJU0MgMi4wLjIgc3RkbGliLmggZG9lcyBu b3QgZGVjbGFyZSBmcmVlLCBjb250cmFyeSB0byBBTlNJLg0KIGNhdCA+IGNv bmZ0ZXN0LiRhY19leHQgPDxFT0YNCi0jbGluZSAxNDUyICJjb25maWd1cmUi DQorI2xpbmUgMTQ3NCAiY29uZmlndXJlIg0KICNpbmNsdWRlICJjb25mZGVm cy5oIg0KICNpbmNsdWRlIDxzdGRsaWIuaD4NCiBFT0YNCkBAIC0xNDY5LDcg KzE0OTEsNyBAQA0KICAgOg0KIGVsc2UNCiAgIGNhdCA+IGNvbmZ0ZXN0LiRh Y19leHQgPDxFT0YNCi0jbGluZSAxNDczICJjb25maWd1cmUiDQorI2xpbmUg MTQ5NSAiY29uZmlndXJlIg0KICNpbmNsdWRlICJjb25mZGVmcy5oIg0KICNp bmNsdWRlIDxjdHlwZS5oPg0KICNkZWZpbmUgSVNMT1dFUihjKSAoJ2EnIDw9 IChjKSAmJiAoYykgPD0gJ3onKQ0KQEAgLTE0ODAsNyArMTUwMiw3IEBADQog ZXhpdCAoMCk7IH0NCiANCiBFT0YNCi1pZiB7IChldmFsIGVjaG8gY29uZmln dXJlOjE0ODQ6IFwiJGFjX2xpbmtcIikgMT4mNTsgKGV2YWwgJGFjX2xpbmsp IDI+JjU7IH0gJiYgdGVzdCAtcyBjb25mdGVzdCAmJiAoLi9jb25mdGVzdDsg ZXhpdCkgMj4vZGV2L251bGwNCitpZiB7IChldmFsIGVjaG8gY29uZmlndXJl OjE1MDY6IFwiJGFjX2xpbmtcIikgMT4mNTsgKGV2YWwgJGFjX2xpbmspIDI+ JjU7IH0gJiYgdGVzdCAtcyBjb25mdGVzdCAmJiAoLi9jb25mdGVzdDsgZXhp dCkgMj4vZGV2L251bGwNCiB0aGVuDQogICA6DQogZWxzZQ0KQEAgLTE1MDcs MTcgKzE1MjksMTcgQEANCiBkbw0KIGFjX3NhZmU9YGVjaG8gIiRhY19oZHIi IHwgc2VkICd5JS4vKy0lX19wXyUnYA0KIGVjaG8gJGFjX24gImNoZWNraW5n IGZvciAkYWNfaGRyIiIuLi4gJGFjX2MiIDE+JjYNCi1lY2hvICJjb25maWd1 cmU6MTUxMTogY2hlY2tpbmcgZm9yICRhY19oZHIiID4mNQ0KK2VjaG8gImNv bmZpZ3VyZToxNTMzOiBjaGVja2luZyBmb3IgJGFjX2hkciIgPiY1DQogaWYg ZXZhbCAidGVzdCBcImBlY2hvICckJyd7J2FjX2N2X2hlYWRlcl8kYWNfc2Fm ZScrc2V0fSdgXCIgPSBzZXQiOyB0aGVuDQogICBlY2hvICRhY19uICIoY2Fj aGVkKSAkYWNfYyIgMT4mNg0KIGVsc2UNCiAgIGNhdCA+IGNvbmZ0ZXN0LiRh Y19leHQgPDxFT0YNCi0jbGluZSAxNTE2ICJjb25maWd1cmUiDQorI2xpbmUg MTUzOCAiY29uZmlndXJlIg0KICNpbmNsdWRlICJjb25mZGVmcy5oIg0KICNp bmNsdWRlIDwkYWNfaGRyPg0KIEVPRg0KIGFjX3RyeT0iJGFjX2NwcCBjb25m dGVzdC4kYWNfZXh0ID4vZGV2L251bGwgMj5jb25mdGVzdC5vdXQiDQoteyAo ZXZhbCBlY2hvIGNvbmZpZ3VyZToxNTIxOiBcIiRhY190cnlcIikgMT4mNTsg KGV2YWwgJGFjX3RyeSkgMj4mNTsgfQ0KK3sgKGV2YWwgZWNobyBjb25maWd1 cmU6MTU0MzogXCIkYWNfdHJ5XCIpIDE+JjU7IChldmFsICRhY190cnkpIDI+ JjU7IH0NCiBhY19lcnI9YGdyZXAgLXYgJ14gKisnIGNvbmZ0ZXN0Lm91dGAN CiBpZiB0ZXN0IC16ICIkYWNfZXJyIjsgdGhlbg0KICAgcm0gLXJmIGNvbmZ0 ZXN0Kg0KQEAgLTE1NDYsMTIgKzE1NjgsMTIgQEANCiANCiAjIENoZWNrcyBm b3IgdHlwZWRlZnMsIHN0cnVjdHVyZXMsIGFuZCBjb21waWxlciBjaGFyYWN0 ZXJpc3RpY3MuDQogZWNobyAkYWNfbiAiY2hlY2tpbmcgZm9yIHVpZF90IGlu IHN5cy90eXBlcy5oIiIuLi4gJGFjX2MiIDE+JjYNCi1lY2hvICJjb25maWd1 cmU6MTU1MDogY2hlY2tpbmcgZm9yIHVpZF90IGluIHN5cy90eXBlcy5oIiA+ JjUNCitlY2hvICJjb25maWd1cmU6MTU3MjogY2hlY2tpbmcgZm9yIHVpZF90 IGluIHN5cy90eXBlcy5oIiA+JjUNCiBpZiBldmFsICJ0ZXN0IFwiYGVjaG8g JyQnJ3snYWNfY3ZfdHlwZV91aWRfdCcrc2V0fSdgXCIgPSBzZXQiOyB0aGVu DQogICBlY2hvICRhY19uICIoY2FjaGVkKSAkYWNfYyIgMT4mNg0KIGVsc2UN CiAgIGNhdCA+IGNvbmZ0ZXN0LiRhY19leHQgPDxFT0YNCi0jbGluZSAxNTU1 ICJjb25maWd1cmUiDQorI2xpbmUgMTU3NyAiY29uZmlndXJlIg0KICNpbmNs dWRlICJjb25mZGVmcy5oIg0KICNpbmNsdWRlIDxzeXMvdHlwZXMuaD4NCiBF T0YNCkBAIC0xNTgwLDcgKzE2MDIsNyBAQA0KIGZpDQogDQogZWNobyAkYWNf biAiY2hlY2tpbmcgdHlwZSBvZiBhcnJheSBhcmd1bWVudCB0byBnZXRncm91 cHMiIi4uLiAkYWNfYyIgMT4mNg0KLWVjaG8gImNvbmZpZ3VyZToxNTg0OiBj aGVja2luZyB0eXBlIG9mIGFycmF5IGFyZ3VtZW50IHRvIGdldGdyb3VwcyIg PiY1DQorZWNobyAiY29uZmlndXJlOjE2MDY6IGNoZWNraW5nIHR5cGUgb2Yg YXJyYXkgYXJndW1lbnQgdG8gZ2V0Z3JvdXBzIiA+JjUNCiBpZiBldmFsICJ0 ZXN0IFwiYGVjaG8gJyQnJ3snYWNfY3ZfdHlwZV9nZXRncm91cHMnK3NldH0n YFwiID0gc2V0IjsgdGhlbg0KICAgZWNobyAkYWNfbiAiKGNhY2hlZCkgJGFj X2MiIDE+JjYNCiBlbHNlDQpAQCAtMTU4OCw3ICsxNjEwLDcgQEANCiAgIGFj X2N2X3R5cGVfZ2V0Z3JvdXBzPWNyb3NzDQogZWxzZQ0KICAgY2F0ID4gY29u ZnRlc3QuJGFjX2V4dCA8PEVPRg0KLSNsaW5lIDE1OTIgImNvbmZpZ3VyZSIN CisjbGluZSAxNjE0ICJjb25maWd1cmUiDQogI2luY2x1ZGUgImNvbmZkZWZz LmgiDQogDQogLyogVGhhbmtzIHRvIE1pa2UgUmVuZGVsbCBmb3IgdGhpcyB0 ZXN0LiAgKi8NCkBAIC0xNjEzLDcgKzE2MzUsNyBAQA0KIH0NCiANCiBFT0YN Ci1pZiB7IChldmFsIGVjaG8gY29uZmlndXJlOjE2MTc6IFwiJGFjX2xpbmtc IikgMT4mNTsgKGV2YWwgJGFjX2xpbmspIDI+JjU7IH0gJiYgdGVzdCAtcyBj b25mdGVzdCAmJiAoLi9jb25mdGVzdDsgZXhpdCkgMj4vZGV2L251bGwNCitp ZiB7IChldmFsIGVjaG8gY29uZmlndXJlOjE2Mzk6IFwiJGFjX2xpbmtcIikg MT4mNTsgKGV2YWwgJGFjX2xpbmspIDI+JjU7IH0gJiYgdGVzdCAtcyBjb25m dGVzdCAmJiAoLi9jb25mdGVzdDsgZXhpdCkgMj4vZGV2L251bGwNCiB0aGVu DQogICAgIGFjX2N2X3R5cGVfZ2V0Z3JvdXBzPWdpZF90DQogZWxzZQ0KQEAg LTE2MjcsNyArMTY0OSw3IEBADQogDQogaWYgdGVzdCAkYWNfY3ZfdHlwZV9n ZXRncm91cHMgPSBjcm9zczsgdGhlbg0KICAgICAgICAgY2F0ID4gY29uZnRl c3QuJGFjX2V4dCA8PEVPRg0KLSNsaW5lIDE2MzEgImNvbmZpZ3VyZSINCisj bGluZSAxNjUzICJjb25maWd1cmUiDQogI2luY2x1ZGUgImNvbmZkZWZzLmgi DQogI2luY2x1ZGUgPHVuaXN0ZC5oPg0KIEVPRg0KQEAgLTE2NTMsMTIgKzE2 NzUsMTIgQEANCiANCiAjIENoZWNrcyBmb3IgbGlicmFyeSBmdW5jdGlvbnMu DQogZWNobyAkYWNfbiAiY2hlY2tpbmcgZm9yIHZwcmludGYiIi4uLiAkYWNf YyIgMT4mNg0KLWVjaG8gImNvbmZpZ3VyZToxNjU3OiBjaGVja2luZyBmb3Ig dnByaW50ZiIgPiY1DQorZWNobyAiY29uZmlndXJlOjE2Nzk6IGNoZWNraW5n IGZvciB2cHJpbnRmIiA+JjUNCiBpZiBldmFsICJ0ZXN0IFwiYGVjaG8gJyQn J3snYWNfY3ZfZnVuY192cHJpbnRmJytzZXR9J2BcIiA9IHNldCI7IHRoZW4N CiAgIGVjaG8gJGFjX24gIihjYWNoZWQpICRhY19jIiAxPiY2DQogZWxzZQ0K ICAgY2F0ID4gY29uZnRlc3QuJGFjX2V4dCA8PEVPRg0KLSNsaW5lIDE2NjIg ImNvbmZpZ3VyZSINCisjbGluZSAxNjg0ICJjb25maWd1cmUiDQogI2luY2x1 ZGUgImNvbmZkZWZzLmgiDQogLyogU3lzdGVtIGhlYWRlciB0byBkZWZpbmUg X19zdHViIG1hY3JvcyBhbmQgaG9wZWZ1bGx5IGZldyBwcm90b3R5cGVzLA0K ICAgICB3aGljaCBjYW4gY29uZmxpY3Qgd2l0aCBjaGFyIHZwcmludGYoKTsg YmVsb3cuICAqLw0KQEAgLTE2ODEsNyArMTcwMyw3IEBADQogDQogOyByZXR1 cm4gMDsgfQ0KIEVPRg0KLWlmIHsgKGV2YWwgZWNobyBjb25maWd1cmU6MTY4 NTogXCIkYWNfbGlua1wiKSAxPiY1OyAoZXZhbCAkYWNfbGluaykgMj4mNTsg fSAmJiB0ZXN0IC1zIGNvbmZ0ZXN0OyB0aGVuDQoraWYgeyAoZXZhbCBlY2hv IGNvbmZpZ3VyZToxNzA3OiBcIiRhY19saW5rXCIpIDE+JjU7IChldmFsICRh Y19saW5rKSAyPiY1OyB9ICYmIHRlc3QgLXMgY29uZnRlc3Q7IHRoZW4NCiAg IHJtIC1yZiBjb25mdGVzdCoNCiAgIGV2YWwgImFjX2N2X2Z1bmNfdnByaW50 Zj15ZXMiDQogZWxzZQ0KQEAgLTE3MDUsMTIgKzE3MjcsMTIgQEANCiANCiBp ZiB0ZXN0ICIkYWNfY3ZfZnVuY192cHJpbnRmIiAhPSB5ZXM7IHRoZW4NCiBl Y2hvICRhY19uICJjaGVja2luZyBmb3IgX2RvcHJudCIiLi4uICRhY19jIiAx PiY2DQotZWNobyAiY29uZmlndXJlOjE3MDk6IGNoZWNraW5nIGZvciBfZG9w cm50IiA+JjUNCitlY2hvICJjb25maWd1cmU6MTczMTogY2hlY2tpbmcgZm9y IF9kb3BybnQiID4mNQ0KIGlmIGV2YWwgInRlc3QgXCJgZWNobyAnJCcneydh Y19jdl9mdW5jX19kb3BybnQnK3NldH0nYFwiID0gc2V0IjsgdGhlbg0KICAg ZWNobyAkYWNfbiAiKGNhY2hlZCkgJGFjX2MiIDE+JjYNCiBlbHNlDQogICBj YXQgPiBjb25mdGVzdC4kYWNfZXh0IDw8RU9GDQotI2xpbmUgMTcxNCAiY29u ZmlndXJlIg0KKyNsaW5lIDE3MzYgImNvbmZpZ3VyZSINCiAjaW5jbHVkZSAi Y29uZmRlZnMuaCINCiAvKiBTeXN0ZW0gaGVhZGVyIHRvIGRlZmluZSBfX3N0 dWIgbWFjcm9zIGFuZCBob3BlZnVsbHkgZmV3IHByb3RvdHlwZXMsDQogICAg IHdoaWNoIGNhbiBjb25mbGljdCB3aXRoIGNoYXIgX2RvcHJudCgpOyBiZWxv dy4gICovDQpAQCAtMTczMyw3ICsxNzU1LDcgQEANCiANCiA7IHJldHVybiAw OyB9DQogRU9GDQotaWYgeyAoZXZhbCBlY2hvIGNvbmZpZ3VyZToxNzM3OiBc IiRhY19saW5rXCIpIDE+JjU7IChldmFsICRhY19saW5rKSAyPiY1OyB9ICYm IHRlc3QgLXMgY29uZnRlc3Q7IHRoZW4NCitpZiB7IChldmFsIGVjaG8gY29u ZmlndXJlOjE3NTk6IFwiJGFjX2xpbmtcIikgMT4mNTsgKGV2YWwgJGFjX2xp bmspIDI+JjU7IH0gJiYgdGVzdCAtcyBjb25mdGVzdDsgdGhlbg0KICAgcm0g LXJmIGNvbmZ0ZXN0Kg0KICAgZXZhbCAiYWNfY3ZfZnVuY19fZG9wcm50PXll cyINCiBlbHNlDQpAQCAtMTkxOSw2ICsxOTQxLDcgQEANCiBzJUBNQUlMTUFO X0dJREAlJE1BSUxNQU5fR0lEJWcNCiBzJUBNQUlMX0dJREAlJE1BSUxfR0lE JWcNCiBzJUBDR0lfR0lEQCUkQ0dJX0dJRCVnDQorcyVAQ0dJRVhUQCUkQ0dJ RVhUJWcNCiBzJUBGUUROQCUkRlFETiVnDQogcyVAVVJMQCUkVVJMJWcNCiBz JUBDUFBAJSRDUFAlZw0KZGlmZiAtcnVOIG1haWxtYW4tMS1jbWRoYW5kbGVy L2NvbmZpZ3VyZS5pbiBtYWlsbWFuL2NvbmZpZ3VyZS5pbg0KLS0tIG1haWxt YW4tMS1jbWRoYW5kbGVyL2NvbmZpZ3VyZS5pbglGcmkgSmFuICA4IDA5OjE4 OjAzIDE5OTkNCisrKyBtYWlsbWFuL2NvbmZpZ3VyZS5pbglGcmkgSmFuICA4 IDA5OjMwOjIyIDE5OTkNCkBAIC0yOTgsNiArMjk4LDIwIEBADQogZmkNCiAN CiANCisjIENHSSBleHRlbnNpb24gY2hlY2tpbmcNCitBQ19TVUJTVChDR0lF WFQpDQorQUNfTVNHX0NIRUNLSU5HKGZvciBDR0kgZXh0ZW5zaW9uKQ0KK0FD X0FSR19XSVRIKGNnaS1leHQsIFsNCisgICAgICAgLS13aXRoLWNnaS1leHQg ICAgICAgIHNwZWNpZnkgZXh0ZW5zaW9ucyBvZiBDR0kgcHJvZ3JhbXNdKQ0K K2lmIHRlc3QgLXogIiR3aXRoX2NnaV9leHQiDQordGhlbg0KKyAgICBDR0lF WFQ9JycNCisgICAgd2l0aF9jZ2lfZXh0PSdubycNCitlbHNlDQorICAgIENH SUVYVD0kd2l0aF9jZ2lfZXh0DQorZmkNCitBQ19NU0dfUkVTVUxUKCR3aXRo X2NnaV9leHQpDQorDQogI01NX0ZJTkRfVVNFUl9JRChBTElBU19VSUQsIG1h aWxtYW4sIGFsaWFzX3dyYXBwZXIpDQogI01NX0ZJTkRfR1JPVVBfSUQoQUxJ QVNfR0lELCBtYWlsLCBhbGlhc193cmFwcGVyKQ0KIA0KZGlmZiAtcnVOIG1h aWxtYW4tMS1jbWRoYW5kbGVyL2Nyb24vY2hlY2tkYnMgbWFpbG1hbi9jcm9u L2NoZWNrZGJzDQotLS0gbWFpbG1hbi0xLWNtZGhhbmRsZXIvY3Jvbi9jaGVj a2RicwlGcmkgQXVnIDE0IDIzOjU2OjA2IDE5OTgNCisrKyBtYWlsbWFuL2Ny b24vY2hlY2tkYnMJRnJpIEphbiAgOCAwOTozMDoyMiAxOTk5DQpAQCAtMzYs NyArMzYsNyBAQA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB7J2NvdW50JzogY291bnQsDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAnaG9zdF9uYW1lJzogbGlzdC5ob3N0X25hbWUsDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAnYWRtaW5EQic6DQot ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsaXN0LkdldEFi c29sdXRlU2NyaXB0VVJMKCdhZG1pbmRiJyksDQorICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBsaXN0LkdldEFic29sdXRlU2NyaXB0VVJM KG1tX2NmZy5hZG1pbmRiX2NnaSksDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAncmVhbF9uYW1lJzogbGlzdC5yZWFsX25hbWUsDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB9KQ0KIAkgICAg bGlzdC5TZW5kVGV4dFRvVXNlcihzdWJqZWN0ID0gJyVkICVzIGFkbWluIHJl cXVlc3Qocykgd2FpdGluZycgJSANCmRpZmYgLXJ1TiBtYWlsbWFuLTEtY21k aGFuZGxlci9zY3JpcHRzL01ha2VmaWxlLmluIG1haWxtYW4vc2NyaXB0cy9N YWtlZmlsZS5pbg0KLS0tIG1haWxtYW4tMS1jbWRoYW5kbGVyL3NjcmlwdHMv TWFrZWZpbGUuaW4JVGh1IE9jdCAyMiAwOToyOToyNyAxOTk4DQorKysgbWFp bG1hbi9zY3JpcHRzL01ha2VmaWxlLmluCUZyaSBKYW4gIDggMDk6MzA6MjIg MTk5OQ0KQEAgLTMxLDcgKzMxLDcgQEANCiBDQz0JCUBDQ0ANCiBDSE1PRD0g IAlAQ0hNT0RADQogSU5TVEFMTD0JQElOU1RBTExADQotDQorQ0dJRVhUPQkJ QENHSUVYVEANCiBERUZTPSAgIAlAREVGU0ANCiANCiAjIEN1c3RvbWl6YWJs ZSBidXQgbm90IHNldCBieSBjb25maWd1cmUNCmRpZmYgLXJ1TiBtYWlsbWFu LTEtY21kaGFuZGxlci9zcmMvTWFrZWZpbGUuaW4gbWFpbG1hbi9zcmMvTWFr ZWZpbGUuaW4NCi0tLSBtYWlsbWFuLTEtY21kaGFuZGxlci9zcmMvTWFrZWZp bGUuaW4JRnJpIEphbiAgOCAwOToyMzo0MiAxOTk5DQorKysgbWFpbG1hbi9z cmMvTWFrZWZpbGUuaW4JRnJpIEphbiAgOCAwOTozMDoyMiAxOTk5DQpAQCAt NDYsNyArNDYsNyBAQA0KIE9QVD0JCUBPUFRADQogQ0ZMQUdTPQkJJChPUFQp ICQoREVGUykNCiBDR0lESVI9IAkkKGV4ZWNfcHJlZml4KS9jZ2ktYmluDQot Q0dJRVhUPQkJDQorQ0dJRVhUPQkJQENHSUVYVEANCiBNQUlMRElSPQkkKGV4 ZWNfcHJlZml4KS9tYWlsDQogDQogU0hFTEw9CQkvYmluL3NoDQo= ---456965764-233999344-915788868=:3512 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="mailman-3-mtu.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="mailman-3-mtu.patch" ZGlmZiAtcnVOIG1haWxtYW4tMi1jZ2lleHQvTWFpbG1hbi9PdXRnb2luZ1F1 ZXVlLnB5IG1haWxtYW4vTWFpbG1hbi9PdXRnb2luZ1F1ZXVlLnB5DQotLS0g bWFpbG1hbi0yLWNnaWV4dC9NYWlsbWFuL091dGdvaW5nUXVldWUucHkJRnJp IEphbiAgOCAwOToxODoxNyAxOTk5DQorKysgbWFpbG1hbi9NYWlsbWFuL091 dGdvaW5nUXVldWUucHkJRnJpIEphbiAgOCAwOTozMzoxNSAxOTk5DQpAQCAt NzcsNiArNzcsOSBAQA0KICMgICAgYW4gYWN0aXZlIHN0YXRlIGZvciB0b28g bG9uZyBhbmQgYXR0ZW1wdCBhIGRlbGl2ZXJ5DQogIw0KIGRlZiBwcm9jZXNz UXVldWUoKToNCisgICAgaW1wb3J0IG1tX2NmZw0KKyAgICBpZiBtbV9jZmcu TUFJTEVSX0NNRDoNCisJcmV0dXJuDQogICAgIGltcG9ydCBmbG9jaw0KICAg ICBpbXBvcnQgdGltZQ0KICAgICBpbXBvcnQgVXRpbHMNCkBAIC0xNzYsNCAr MTc5LDcgQEANCiAjIHJlbW92ZSBpdCBmcm9tIHRoZSBxdWV1ZSANCiAjDQog ZGVmIGRlcXVldWVNZXNzYWdlKHFfZW50cnkpOg0KLSAgICBvcy51bmxpbmso cV9lbnRyeSkNCisgICAgdHJ5Og0KKwlvcy51bmxpbmsocV9lbnRyeSkNCisg ICAgZXhjZXB0Og0KKwlwYXNzDQpkaWZmIC1ydU4gbWFpbG1hbi0yLWNnaWV4 dC9NYWlsbWFuL1V0aWxzLnB5IG1haWxtYW4vTWFpbG1hbi9VdGlscy5weQ0K LS0tIG1haWxtYW4tMi1jZ2lleHQvTWFpbG1hbi9VdGlscy5weQlGcmkgSmFu ICA4IDA5OjE4OjIwIDE5OTkNCisrKyBtYWlsbWFuL01haWxtYW4vVXRpbHMu cHkJRnJpIEphbiAgOCAwOTozNDozNiAxOTk5DQpAQCAtMTY4LDYgKzE2OCwy OSBAQA0KIA0KIA0KIGRlZiBUcnlTTVRQRGVsaXZlcnkocmVjaXBpZW50LCBz ZW5kZXIsIHRleHQsIHF1ZXVlX2VudHJ5KToNCisgICAgaW1wb3J0IHR5cGVz DQorDQorICAgIGlmIHR5cGUobW1fY2ZnLk1BSUxFUl9DTUQpID09IHR5cGVz LlN0cmluZ1R5cGUgYW5kIGxlbihtbV9jZmcuTUFJTEVSX0NNRCk6DQorIAly ZWNpcCA9IFtdDQorIAlpZiB0eXBlKHJlY2lwaWVudCkgPT0gdHlwZXMuU3Ry aW5nVHlwZToNCisgCSAgICByZWNpcCA9IFtyZWNpcGllbnRdDQorIAllbGlm IHR5cGUocmVjaXBpZW50KSA9PSB0eXBlcy5MaXN0VHlwZToNCisgCSAgICBy ZWNpcCA9IHJlY2lwaWVudA0KKyAJZWxzZToNCisgCSAgICByZXR1cm4NCisg CSAgICAjIFdoYXQgZWxzZSB3ZSBjYW4gZG8/IExvZz8NCisgCXRyeToNCisg CSAgICBwcGUgPSBvcy5wb3BlbihtbV9jZmcuTUFJTEVSX0NNRCAlIHsNCisg CQkgICAgJzxtbV9zZW5kZXI+Jzogc2VuZGVyLA0KKyAJCSAgICAnPG1tX3Jl Y2lwaWVudHM+Jzogc3RyaW5nLmpvaW4oJyAnLCByZWNpcCksDQorIAkJfSwg J3cnKQ0KKyAJICAgIHBwZS53cml0ZSh0ZXh0KQ0KKyAJICAgIHBwZS5jbG9z ZSgpDQorIAkgICAgcmV0dXJuDQorIAlleGNlcHQ6DQorIAkgICAgcGFzcw0K KyAJICAgICMgVHJ5IHRvIGRlbGl2ZXIgdmlhIFNNVFAgcG9ydCBpbnN0ZWFk DQorIA0KICAgICBpbXBvcnQgc29ja2V0DQogICAgIGltcG9ydCBPdXRnb2lu Z1F1ZXVlDQogDQpkaWZmIC1ydU4gbWFpbG1hbi0yLWNnaWV4dC9NYWlsbWFu L21tX2NmZy5weS5kaXN0LmluIG1haWxtYW4vTWFpbG1hbi9tbV9jZmcucHku ZGlzdC5pbg0KLS0tIG1haWxtYW4tMi1jZ2lleHQvTWFpbG1hbi9tbV9jZmcu cHkuZGlzdC5pbglGcmkgSmFuICA4IDA5OjMwOjIyIDE5OTkNCisrKyBtYWls bWFuL01haWxtYW4vbW1fY2ZnLnB5LmRpc3QuaW4JRnJpIEphbiAgOCAwOToz MzoxNSAxOTk5DQpAQCAtNTUsNSArNTUsNyBAQA0KIFBVQkxJQ19BUkNISVZF X1VSTCA9ICcvcGlwZXJtYWlsQENHSUVYVEAnDQogUFJJVkFURV9BUkNISVZF X1VSTCA9ICcvbWFpbG1hbi9wcml2YXRlQENHSUVYVEAnDQogDQorTUFJTEVS X0NNRAkgID0gJ0BTRU5ETUFJTEAnDQorDQogIyBOb3RlIC0gaWYgeW91J3Jl IGxvb2tpbmcgZm9yIHNvbWV0aGluZyB0aGF0IGlzIGltcG9ydGVkIGZyb20g bW1fY2ZnLCBidXQgeW91DQogIyBkaWRuJ3QgZmluZCBpdCBhYm92ZSwgaXQn cyBwcm9iYWJseSBpbiBEZWZhdWx0cy5weS4NCmRpZmYgLXJ1TiBtYWlsbWFu LTItY2dpZXh0L2NvbmZpZ3VyZSBtYWlsbWFuL2NvbmZpZ3VyZQ0KLS0tIG1h aWxtYW4tMi1jZ2lleHQvY29uZmlndXJlCUZyaSBKYW4gIDggMDk6MzI6Mjkg MTk5OQ0KKysrIG1haWxtYW4vY29uZmlndXJlCUZyaSBKYW4gIDggMDk6NDg6 MDYgMTk5OQ0KQEAgLTI3LDcgKzI3LDEwIEBADQogCS0td2l0aC1jZ2ktZ2lk ICAJc3BlY2lmeSBHSUQgQ0dJIHByb2dyYW1zIHJ1biBhcyINCiBhY19oZWxw PSIkYWNfaGVscA0KIA0KLSAgICAgICAtLXdpdGgtY2dpLWV4dCAgICAgICAg c3BlY2lmeSBleHRlbnNpb25zIG9mIENHSSBwcm9ncmFtcyINCisJLS13aXRo LWNnaS1leHQgICAgICAgIHNwZWNpZnkgZXh0ZW5zaW9ucyBvZiBDR0kgcHJv Z3JhbXMiDQorYWNfaGVscD0iJGFjX2hlbHANCisNCisJLS13aXRoLXNlbmRt YWlsICAgICAgZG8gZGVsaXZlcmllcyB3aXRoIHRoaXMgcHJvZ3JhbSINCiAN CiAjIEluaXRpYWxpemUgc29tZSB2YXJpYWJsZXMgc2V0IGJ5IG9wdGlvbnMu DQogIyBUaGUgdmFyaWFibGVzIGhhdmUgdGhlIHNhbWUgbmFtZXMgYXMgdGhl IG9wdGlvbnMsIHdpdGgNCkBAIC01NDgsNyArNTUxLDcgQEANCiANCiAjIENo ZWNrIGZvciBQeXRob24hICBCZXR0ZXIgYmUgZm91bmQgb24gJFBBVEgNCiBl Y2hvICRhY19uICJjaGVja2luZyBmb3IgLS13aXRoLXB5dGhvbiIiLi4uICRh Y19jIiAxPiY2DQotZWNobyAiY29uZmlndXJlOjU1MjogY2hlY2tpbmcgZm9y IC0td2l0aC1weXRob24iID4mNQ0KK2VjaG8gImNvbmZpZ3VyZTo1NTU6IGNo ZWNraW5nIGZvciAtLXdpdGgtcHl0aG9uIiA+JjUNCiAjIENoZWNrIHdoZXRo ZXIgLS13aXRoLXB5dGhvbiBvciAtLXdpdGhvdXQtcHl0aG9uIHdhcyBnaXZl bi4NCiBpZiB0ZXN0ICIke3dpdGhfcHl0aG9uK3NldH0iID0gc2V0OyB0aGVu DQogICB3aXRodmFsPSIkd2l0aF9weXRob24iDQpAQCAtNTYyLDcgKzU2NSw3 IEBADQogCSMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAicHl0aG9uIiwg c28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4NCiBzZXQg ZHVtbXkgcHl0aG9uOyBhY193b3JkPSQyDQogZWNobyAkYWNfbiAiY2hlY2tp bmcgZm9yICRhY193b3JkIiIuLi4gJGFjX2MiIDE+JjYNCi1lY2hvICJjb25m aWd1cmU6NTY2OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQ0KK2VjaG8g ImNvbmZpZ3VyZTo1Njk6IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1DQog aWYgZXZhbCAidGVzdCBcImBlY2hvICckJyd7J2FjX2N2X3BhdGhfd2l0aF9w eXRob24nK3NldH0nYFwiID0gc2V0IjsgdGhlbg0KICAgZWNobyAkYWNfbiAi KGNhY2hlZCkgJGFjX2MiIDE+JjYNCiBlbHNlDQpAQCAtNTk0LDcgKzU5Nyw3 IEBADQogZmkNCiANCiBlY2hvICRhY19uICJjaGVja2luZyBQeXRob24gaW50 ZXJwcmV0ZXIiIi4uLiAkYWNfYyIgMT4mNg0KLWVjaG8gImNvbmZpZ3VyZTo1 OTg6IGNoZWNraW5nIFB5dGhvbiBpbnRlcnByZXRlciIgPiY1DQorZWNobyAi Y29uZmlndXJlOjYwMTogY2hlY2tpbmcgUHl0aG9uIGludGVycHJldGVyIiA+ JjUNCiBpZiB0ZXN0ICEgLXggJHdpdGhfcHl0aG9uDQogdGhlbg0KICAgICB7 IGVjaG8gImNvbmZpZ3VyZTogZXJyb3I6IA0KQEAgLTYzOCw3ICs2NDEsNyBA QA0KICMgU1ZSNCAvdXNyL3VjYi9pbnN0YWxsLCB3aGljaCB0cmllcyB0byB1 c2UgdGhlIG5vbmV4aXN0ZW50IGdyb3VwICJzdGFmZiINCiAjIC4vaW5zdGFs bCwgd2hpY2ggY2FuIGJlIGVycm9uZW91c2x5IGNyZWF0ZWQgYnkgbWFrZSBm cm9tIC4vaW5zdGFsbC5zaC4NCiBlY2hvICRhY19uICJjaGVja2luZyBmb3Ig YSBCU0QgY29tcGF0aWJsZSBpbnN0YWxsIiIuLi4gJGFjX2MiIDE+JjYNCi1l Y2hvICJjb25maWd1cmU6NjQyOiBjaGVja2luZyBmb3IgYSBCU0QgY29tcGF0 aWJsZSBpbnN0YWxsIiA+JjUNCitlY2hvICJjb25maWd1cmU6NjQ1OiBjaGVj a2luZyBmb3IgYSBCU0QgY29tcGF0aWJsZSBpbnN0YWxsIiA+JjUNCiBpZiB0 ZXN0IC16ICIkSU5TVEFMTCI7IHRoZW4NCiBpZiBldmFsICJ0ZXN0IFwiYGVj aG8gJyQnJ3snYWNfY3ZfcGF0aF9pbnN0YWxsJytzZXR9J2BcIiA9IHNldCI7 IHRoZW4NCiAgIGVjaG8gJGFjX24gIihjYWNoZWQpICRhY19jIiAxPiY2DQpA QCAtNjg4LDcgKzY5MSw3IEBADQogdGVzdCAteiAiJElOU1RBTExfREFUQSIg JiYgSU5TVEFMTF9EQVRBPScke0lOU1RBTEx9IC1tIDY0NCcNCiANCiBlY2hv ICRhY19uICJjaGVja2luZyB3aGV0aGVyICR7TUFLRS1tYWtlfSBzZXRzIFwk e01BS0V9IiIuLi4gJGFjX2MiIDE+JjYNCi1lY2hvICJjb25maWd1cmU6Njky OiBjaGVja2luZyB3aGV0aGVyICR7TUFLRS1tYWtlfSBzZXRzIFwke01BS0V9 IiA+JjUNCitlY2hvICJjb25maWd1cmU6Njk1OiBjaGVja2luZyB3aGV0aGVy ICR7TUFLRS1tYWtlfSBzZXRzIFwke01BS0V9IiA+JjUNCiBzZXQgZHVtbXkg JHtNQUtFLW1ha2V9OyBhY19tYWtlPWBlY2hvICIkMiIgfCBzZWQgJ3klLi8r LSVfX3BfJSdgDQogaWYgZXZhbCAidGVzdCBcImBlY2hvICckJyd7J2FjX2N2 X3Byb2dfbWFrZV8ke2FjX21ha2V9X3NldCcrc2V0fSdgXCIgPSBzZXQiOyB0 aGVuDQogICBlY2hvICRhY19uICIoY2FjaGVkKSAkYWNfYyIgMT4mNg0KQEAg LTcxNyw3ICs3MjAsNyBAQA0KIA0KICMgRmluZCBjb21waWxlciwgYWxsb3cg YWx0ZXJuYXRpdmVzIHRvIGdjYw0KIGVjaG8gJGFjX24gImNoZWNraW5nIGZv ciAtLXdpdGhvdXQtZ2NjIiIuLi4gJGFjX2MiIDE+JjYNCi1lY2hvICJjb25m aWd1cmU6NzIxOiBjaGVja2luZyBmb3IgLS13aXRob3V0LWdjYyIgPiY1DQor ZWNobyAiY29uZmlndXJlOjcyNDogY2hlY2tpbmcgZm9yIC0td2l0aG91dC1n Y2MiID4mNQ0KICMgQ2hlY2sgd2hldGhlciAtLXdpdGgtZ2NjIG9yIC0td2l0 aG91dC1nY2Mgd2FzIGdpdmVuLg0KIGlmIHRlc3QgIiR7d2l0aF9nY2Mrc2V0 fSIgPSBzZXQ7IHRoZW4NCiAgIHdpdGh2YWw9IiR3aXRoX2djYyINCkBAIC03 NDYsNyArNzQ5LDcgQEANCiAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2Yg ImdjYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3Mu DQogc2V0IGR1bW15IGdjYzsgYWNfd29yZD0kMg0KIGVjaG8gJGFjX24gImNo ZWNraW5nIGZvciAkYWNfd29yZCIiLi4uICRhY19jIiAxPiY2DQotZWNobyAi Y29uZmlndXJlOjc1MDogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUNCitl Y2hvICJjb25maWd1cmU6NzUzOiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4m NQ0KIGlmIGV2YWwgInRlc3QgXCJgZWNobyAnJCcneydhY19jdl9wcm9nX0ND JytzZXR9J2BcIiA9IHNldCI7IHRoZW4NCiAgIGVjaG8gJGFjX24gIihjYWNo ZWQpICRhY19jIiAxPiY2DQogZWxzZQ0KQEAgLTc3NSw3ICs3NzgsNyBAQA0K ICAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJjYyIsIHNvIGl0IGNh biBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuDQogc2V0IGR1bW15IGNj OyBhY193b3JkPSQyDQogZWNobyAkYWNfbiAiY2hlY2tpbmcgZm9yICRhY193 b3JkIiIuLi4gJGFjX2MiIDE+JjYNCi1lY2hvICJjb25maWd1cmU6Nzc5OiBj aGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQ0KK2VjaG8gImNvbmZpZ3VyZTo3 ODI6IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1DQogaWYgZXZhbCAidGVz dCBcImBlY2hvICckJyd7J2FjX2N2X3Byb2dfQ0MnK3NldH0nYFwiID0gc2V0 IjsgdGhlbg0KICAgZWNobyAkYWNfbiAiKGNhY2hlZCkgJGFjX2MiIDE+JjYN CiBlbHNlDQpAQCAtODIzLDcgKzgyNiw3IEBADQogZmkNCiANCiBlY2hvICRh Y19uICJjaGVja2luZyB3aGV0aGVyIHRoZSBDIGNvbXBpbGVyICgkQ0MgJENG TEFHUyAkTERGTEFHUykgd29ya3MiIi4uLiAkYWNfYyIgMT4mNg0KLWVjaG8g ImNvbmZpZ3VyZTo4Mjc6IGNoZWNraW5nIHdoZXRoZXIgdGhlIEMgY29tcGls ZXIgKCRDQyAkQ0ZMQUdTICRMREZMQUdTKSB3b3JrcyIgPiY1DQorZWNobyAi Y29uZmlndXJlOjgzMDogY2hlY2tpbmcgd2hldGhlciB0aGUgQyBjb21waWxl ciAoJENDICRDRkxBR1MgJExERkxBR1MpIHdvcmtzIiA+JjUNCiANCiBhY19l eHQ9Yw0KICMgQ0ZMQUdTIGlzIG5vdCBpbiBhY19jcHAgYmVjYXVzZSAtZywg LU8sIGV0Yy4gYXJlIG5vdCB2YWxpZCBjcHAgb3B0aW9ucy4NCkBAIC04MzMs MTEgKzgzNiwxMSBAQA0KIGNyb3NzX2NvbXBpbGluZz0kYWNfY3ZfcHJvZ19j Y19jcm9zcw0KIA0KIGNhdCA+IGNvbmZ0ZXN0LiRhY19leHQgPDxFT0YNCi0j bGluZSA4MzcgImNvbmZpZ3VyZSINCisjbGluZSA4NDAgImNvbmZpZ3VyZSIN CiAjaW5jbHVkZSAiY29uZmRlZnMuaCINCiBtYWluKCl7cmV0dXJuKDApO30N CiBFT0YNCi1pZiB7IChldmFsIGVjaG8gY29uZmlndXJlOjg0MTogXCIkYWNf bGlua1wiKSAxPiY1OyAoZXZhbCAkYWNfbGluaykgMj4mNTsgfSAmJiB0ZXN0 IC1zIGNvbmZ0ZXN0OyB0aGVuDQoraWYgeyAoZXZhbCBlY2hvIGNvbmZpZ3Vy ZTo4NDQ6IFwiJGFjX2xpbmtcIikgMT4mNTsgKGV2YWwgJGFjX2xpbmspIDI+ JjU7IH0gJiYgdGVzdCAtcyBjb25mdGVzdDsgdGhlbg0KICAgYWNfY3ZfcHJv Z19jY193b3Jrcz15ZXMNCiAgICMgSWYgd2UgY2FuJ3QgcnVuIGEgdHJpdmlh bCBwcm9ncmFtLCB3ZSBhcmUgcHJvYmFibHkgdXNpbmcgYSBjcm9zcyBjb21w aWxlci4NCiAgIGlmICguL2NvbmZ0ZXN0OyBleGl0KSAyPi9kZXYvbnVsbDsg dGhlbg0KQEAgLTg1NywxMiArODYwLDEyIEBADQogICB7IGVjaG8gImNvbmZp Z3VyZTogZXJyb3I6IGluc3RhbGxhdGlvbiBvciBjb25maWd1cmF0aW9uIHBy b2JsZW06IEMgY29tcGlsZXIgY2Fubm90IGNyZWF0ZSBleGVjdXRhYmxlcy4i IDE+JjI7IGV4aXQgMTsgfQ0KIGZpDQogZWNobyAkYWNfbiAiY2hlY2tpbmcg d2hldGhlciB0aGUgQyBjb21waWxlciAoJENDICRDRkxBR1MgJExERkxBR1Mp IGlzIGEgY3Jvc3MtY29tcGlsZXIiIi4uLiAkYWNfYyIgMT4mNg0KLWVjaG8g ImNvbmZpZ3VyZTo4NjE6IGNoZWNraW5nIHdoZXRoZXIgdGhlIEMgY29tcGls ZXIgKCRDQyAkQ0ZMQUdTICRMREZMQUdTKSBpcyBhIGNyb3NzLWNvbXBpbGVy IiA+JjUNCitlY2hvICJjb25maWd1cmU6ODY0OiBjaGVja2luZyB3aGV0aGVy IHRoZSBDIGNvbXBpbGVyICgkQ0MgJENGTEFHUyAkTERGTEFHUykgaXMgYSBj cm9zcy1jb21waWxlciIgPiY1DQogZWNobyAiJGFjX3QiIiRhY19jdl9wcm9n X2NjX2Nyb3NzIiAxPiY2DQogY3Jvc3NfY29tcGlsaW5nPSRhY19jdl9wcm9n X2NjX2Nyb3NzDQogDQogZWNobyAkYWNfbiAiY2hlY2tpbmcgd2hldGhlciB3 ZSBhcmUgdXNpbmcgR05VIEMiIi4uLiAkYWNfYyIgMT4mNg0KLWVjaG8gImNv bmZpZ3VyZTo4NjY6IGNoZWNraW5nIHdoZXRoZXIgd2UgYXJlIHVzaW5nIEdO VSBDIiA+JjUNCitlY2hvICJjb25maWd1cmU6ODY5OiBjaGVja2luZyB3aGV0 aGVyIHdlIGFyZSB1c2luZyBHTlUgQyIgPiY1DQogaWYgZXZhbCAidGVzdCBc ImBlY2hvICckJyd7J2FjX2N2X3Byb2dfZ2NjJytzZXR9J2BcIiA9IHNldCI7 IHRoZW4NCiAgIGVjaG8gJGFjX24gIihjYWNoZWQpICRhY19jIiAxPiY2DQog ZWxzZQ0KQEAgLTg3MSw3ICs4NzQsNyBAQA0KICAgeWVzOw0KICNlbmRpZg0K IEVPRg0KLWlmIHsgYWNfdHJ5PScke0NDLWNjfSAtRSBjb25mdGVzdC5jJzsg eyAoZXZhbCBlY2hvIGNvbmZpZ3VyZTo4NzU6IFwiJGFjX3RyeVwiKSAxPiY1 OyAoZXZhbCAkYWNfdHJ5KSAyPiY1OyB9OyB9IHwgZWdyZXAgeWVzID4vZGV2 L251bGwgMj4mMTsgdGhlbg0KK2lmIHsgYWNfdHJ5PScke0NDLWNjfSAtRSBj b25mdGVzdC5jJzsgeyAoZXZhbCBlY2hvIGNvbmZpZ3VyZTo4Nzg6IFwiJGFj X3RyeVwiKSAxPiY1OyAoZXZhbCAkYWNfdHJ5KSAyPiY1OyB9OyB9IHwgZWdy ZXAgeWVzID4vZGV2L251bGwgMj4mMTsgdGhlbg0KICAgYWNfY3ZfcHJvZ19n Y2M9eWVzDQogZWxzZQ0KICAgYWNfY3ZfcHJvZ19nY2M9bm8NCkBAIC04ODYs NyArODg5LDcgQEANCiAgIGFjX3NhdmVfQ0ZMQUdTPSIkQ0ZMQUdTIg0KICAg Q0ZMQUdTPQ0KICAgZWNobyAkYWNfbiAiY2hlY2tpbmcgd2hldGhlciAke0ND LWNjfSBhY2NlcHRzIC1nIiIuLi4gJGFjX2MiIDE+JjYNCi1lY2hvICJjb25m aWd1cmU6ODkwOiBjaGVja2luZyB3aGV0aGVyICR7Q0MtY2N9IGFjY2VwdHMg LWciID4mNQ0KK2VjaG8gImNvbmZpZ3VyZTo4OTM6IGNoZWNraW5nIHdoZXRo ZXIgJHtDQy1jY30gYWNjZXB0cyAtZyIgPiY1DQogaWYgZXZhbCAidGVzdCBc ImBlY2hvICckJyd7J2FjX2N2X3Byb2dfY2NfZycrc2V0fSdgXCIgPSBzZXQi OyB0aGVuDQogICBlY2hvICRhY19uICIoY2FjaGVkKSAkYWNfYyIgMT4mNg0K IGVsc2UNCkBAIC05MzQsNyArOTM3LDcgQEANCiAjIFB1bGwgdGhlIGhhc2gg bWFyayBvdXQgb2YgdGhlIG1hY3JvIGNhbGwgdG8gYXZvaWQgbTQgcHJvYmxl bXMuDQogYWNfbXNnPSJ3aGV0aGVyICMhIHdvcmtzIGluIHNoZWxsIHNjcmlw dHMiDQogZWNobyAkYWNfbiAiY2hlY2tpbmcgJGFjX21zZyIiLi4uICRhY19j IiAxPiY2DQotZWNobyAiY29uZmlndXJlOjkzODogY2hlY2tpbmcgJGFjX21z ZyIgPiY1DQorZWNobyAiY29uZmlndXJlOjk0MTogY2hlY2tpbmcgJGFjX21z ZyIgPiY1DQogaWYgZXZhbCAidGVzdCBcImBlY2hvICckJyd7J2FjX2N2X3N5 c19pbnRlcnByZXRlcicrc2V0fSdgXCIgPSBzZXQiOyB0aGVuDQogICBlY2hv ICRhY19uICIoY2FjaGVkKSAkYWNfYyIgMT4mNg0KIGVsc2UNCkBAIC05NzEs NyArOTc0LDcgQEANCiANCiAjIFVzZXIgYG1haWxtYW4nIG11c3QgZXhpc3QN CiBlY2hvICRhY19uICJjaGVja2luZyBmb3IgbWFpbG1hbiBVSUQiIi4uLiAk YWNfYyIgMT4mNg0KLWVjaG8gImNvbmZpZ3VyZTo5NzU6IGNoZWNraW5nIGZv ciBtYWlsbWFuIFVJRCIgPiY1DQorZWNobyAiY29uZmlndXJlOjk3ODogY2hl Y2tpbmcgZm9yIG1haWxtYW4gVUlEIiA+JjUNCiANCiAjIE1BSUxNQU5fVUlE ID09IHZhcmlhYmxlIG5hbWUNCiAjIG1haWxtYW4gPT0gdXNlciBpZCB0byBj aGVjayBmb3INCkBAIC0xMDE0LDcgKzEwMTcsNyBAQA0KIA0KICMgR3JvdXAg YG1haWxtYW4nIG11c3QgZXhpc3QNCiBlY2hvICRhY19uICJjaGVja2luZyBm b3IgbWFpbG1hbiBHSUQiIi4uLiAkYWNfYyIgMT4mNg0KLWVjaG8gImNvbmZp Z3VyZToxMDE4OiBjaGVja2luZyBmb3IgbWFpbG1hbiBHSUQiID4mNQ0KK2Vj aG8gImNvbmZpZ3VyZToxMDIxOiBjaGVja2luZyBmb3IgbWFpbG1hbiBHSUQi ID4mNQ0KIA0KICMgTUFJTE1BTl9HSUQgPT0gdmFyaWFibGUgbmFtZQ0KICMg bWFpbG1hbiA9PSB1c2VyIGlkIHRvIGNoZWNrIGZvcg0KQEAgLTEwNjYsNyAr MTA2OSw3IEBADQogZmkNCiANCiBlY2hvICRhY19uICJjaGVja2luZyBwZXJt aXNzaW9ucyBvbiAkcHJlZml4Y2hlY2siIi4uLiAkYWNfYyIgMT4mNg0KLWVj aG8gImNvbmZpZ3VyZToxMDcwOiBjaGVja2luZyBwZXJtaXNzaW9ucyBvbiAk cHJlZml4Y2hlY2siID4mNQ0KK2VjaG8gImNvbmZpZ3VyZToxMDczOiBjaGVj a2luZyBwZXJtaXNzaW9ucyBvbiAkcHJlZml4Y2hlY2siID4mNQ0KIA0KIGNh dCA+IGNvbmZ0ZXN0LnB5IDw8RU9GDQogaW1wb3J0IG9zLCBncnAsIHN0cmlu Zw0KQEAgLTExMTIsNyArMTExNSw3IEBADQogIyBOb3cgZmluZCB0aGUgVUlE cyBhbmQgR0lEcw0KICMgU3VwcG9ydCAtLXdpdGgtbWFpbC1naWQgYW5kIC0t d2l0aC1jZ2ktZ2lkDQogZWNobyAkYWNfbiAiY2hlY2tpbmcgZm9yIG1haWwg d3JhcHBlciBHSUQiIi4uLiAkYWNfYyIgMT4mNg0KLWVjaG8gImNvbmZpZ3Vy ZToxMTE2OiBjaGVja2luZyBmb3IgbWFpbCB3cmFwcGVyIEdJRCIgPiY1DQor ZWNobyAiY29uZmlndXJlOjExMTk6IGNoZWNraW5nIGZvciBtYWlsIHdyYXBw ZXIgR0lEIiA+JjUNCiAjIENoZWNrIHdoZXRoZXIgLS13aXRoLW1haWwtZ2lk IG9yIC0td2l0aG91dC1tYWlsLWdpZCB3YXMgZ2l2ZW4uDQogaWYgdGVzdCAi JHt3aXRoX21haWxfZ2lkK3NldH0iID0gc2V0OyB0aGVuDQogICB3aXRodmFs PSIkd2l0aF9tYWlsX2dpZCINCkBAIC0xMTI0LDcgKzExMjcsNyBAQA0KICAg ICBpZiBldmFsICJ0ZXN0IFwiYGVjaG8gJyQnJ3snYWNfY3ZfZ3JvdXBfbWFp bCcrc2V0fSdgXCIgPSBzZXQiOyB0aGVuDQogICBlY2hvICRhY19uICIoY2Fj aGVkKSAkYWNfYyIgMT4mNg0KIGVsc2UNCi0gICAgICBhY19jdl9ncm91cF9t YWlsPSJvdGhlciBtYWlsIGRhZW1vbiINCisgICAgICBhY19jdl9ncm91cF9t YWlsPSJub2ZpbGVzIG90aGVyIG1haWwgZGFlbW9uIg0KIGZpDQogDQogZWxz ZQ0KQEAgLTExNzMsNyArMTE3Niw3IEBADQogDQogDQogZWNobyAkYWNfbiAi Y2hlY2tpbmcgZm9yIENHSSB3cmFwcGVyIEdJRCIiLi4uICRhY19jIiAxPiY2 DQotZWNobyAiY29uZmlndXJlOjExNzc6IGNoZWNraW5nIGZvciBDR0kgd3Jh cHBlciBHSUQiID4mNQ0KK2VjaG8gImNvbmZpZ3VyZToxMTgwOiBjaGVja2lu ZyBmb3IgQ0dJIHdyYXBwZXIgR0lEIiA+JjUNCiAjIENoZWNrIHdoZXRoZXIg LS13aXRoLWNnaS1naWQgb3IgLS13aXRob3V0LWNnaS1naWQgd2FzIGdpdmVu Lg0KIGlmIHRlc3QgIiR7d2l0aF9jZ2lfZ2lkK3NldH0iID0gc2V0OyB0aGVu DQogICB3aXRodmFsPSIkd2l0aF9jZ2lfZ2lkIg0KQEAgLTEyMzIsMTEgKzEy MzUsMTMgQEANCiAqKioqKiBkb2N1bWVudGF0aW9uLCBhbmQgdGhlIElOU1RB TEwgZmlsZSBmb3IgZGV0YWlscyIgMT4mMjsgZXhpdCAxOyB9DQogZmkNCiAN CisjTU1fRklORF9VU0VSX0lEKEFMSUFTX1VJRCwgbWFpbG1hbiwgYWxpYXNf d3JhcHBlcikNCisjTU1fRklORF9HUk9VUF9JRChBTElBU19HSUQsIG1haWws IGFsaWFzX3dyYXBwZXIpDQogDQogIyBDR0kgZXh0ZW5zaW9uIGNoZWNraW5n DQogDQogZWNobyAkYWNfbiAiY2hlY2tpbmcgZm9yIENHSSBleHRlbnNpb24i Ii4uLiAkYWNfYyIgMT4mNg0KLWVjaG8gImNvbmZpZ3VyZToxMjQwOiBjaGVj a2luZyBmb3IgQ0dJIGV4dGVuc2lvbiIgPiY1DQorZWNobyAiY29uZmlndXJl OjEyNDU6IGNoZWNraW5nIGZvciBDR0kgZXh0ZW5zaW9uIiA+JjUNCiAjIENo ZWNrIHdoZXRoZXIgLS13aXRoLWNnaS1leHQgb3IgLS13aXRob3V0LWNnaS1l eHQgd2FzIGdpdmVuLg0KIGlmIHRlc3QgIiR7d2l0aF9jZ2lfZXh0K3NldH0i ID0gc2V0OyB0aGVuDQogICB3aXRodmFsPSIkd2l0aF9jZ2lfZXh0Ig0KQEAg LTEyNTIsOCArMTI1Nyw1NyBAQA0KIGZpDQogZWNobyAiJGFjX3QiIiR3aXRo X2NnaV9leHQiIDE+JjYNCiANCi0jTU1fRklORF9VU0VSX0lEKEFMSUFTX1VJ RCwgbWFpbG1hbiwgYWxpYXNfd3JhcHBlcikNCi0jTU1fRklORF9HUk9VUF9J RChBTElBU19HSUQsIG1haWwsIGFsaWFzX3dyYXBwZXIpDQorZWNobyAkYWNf biAiY2hlY2tpbmcgZm9yIHNlbmRtYWlsIHByb2dyYW1zIiIuLi4gJGFjX2Mi IDE+JjYNCitlY2hvICJjb25maWd1cmU6MTI2MjogY2hlY2tpbmcgZm9yIHNl bmRtYWlsIHByb2dyYW1zIiA+JjUNCisjIENoZWNrIHdoZXRoZXIgLS13aXRo LXNlbmRtYWlsIG9yIC0td2l0aG91dC1zZW5kbWFpbCB3YXMgZ2l2ZW4uDQor aWYgdGVzdCAiJHt3aXRoX3NlbmRtYWlsK3NldH0iID0gc2V0OyB0aGVuDQor ICB3aXRodmFsPSIkd2l0aF9zZW5kbWFpbCINCisgIDoNCitmaQ0KKw0KK2lm IHRlc3QgLXogIiR3aXRoX3NlbmRtYWlsIg0KK3RoZW4NCisgICAgaWYgZXZh bCAidGVzdCBcImBlY2hvICckJyd7J2FjX2N2X3NlbmRtYWlsJytzZXR9J2Bc IiA9IHNldCI7IHRoZW4NCisgIGVjaG8gJGFjX24gIihjYWNoZWQpICRhY19j IiAxPiY2DQorZWxzZQ0KKyAgCWFjX2N2X3NlbmRtYWlsPSIvdmFyL3FtYWls L2Jpbi9xbWFpbC1pbmplY3QgL3Vzci9saWIvc2VuZG1haWwgL3Vzci9zYmlu L3NlbmRtYWlsIC9ldGMvc2VuZG1haWwiDQorZmkNCisNCitlbHNlDQorICAg IGFjX2N2X3NlbmRtYWlsPSR3aXRoX3NlbmRtYWlsDQorZmkNCisNCisNCitj YXQgPiBjb25mdGVzdC5weSA8PEVPRg0KK2ltcG9ydCBvcywgc3RyaW5nDQor ZmlsID0gJycNCitmb3IgZmxlIGluIHN0cmluZy5zcGxpdCgiJGFjX2N2X3Nl bmRtYWlsIik6DQorICAgIHRyeToNCisJbCA9IG9zLnN0YXQoZmxlKQ0KKwlp ZiBsWzBdICYgMHgxMTE6DQorCSAgICBmaWwgPSBmbGUNCisJICAgIGJyZWFr DQorICAgIGV4Y2VwdDoNCisJcGFzcw0KK2ZwID0gb3BlbignY29uZnRlc3Qu b3V0JywgJ3cnKQ0KK2ZwLndyaXRlKCclc1xuJyAlIGZpbCkNCitmcC5jbG9z ZQ0KK0VPRg0KKw0KKyRQWVRIT04gY29uZnRlc3QucHkNCitTRU5ETUFJTD1g Y2F0IGNvbmZ0ZXN0Lm91dGANCisjIFBhcmFtZXRlcnMgYXJlIHRoZSBzYW1l IGZvciBxbWFpbC1pbmplY3QgYW5kIHNlbmRtYWlsLWNsb25lcyBidXQgd2hv IGtub3dzPw0KK2lmIHRlc3QgISAteiAkU0VORE1BSUw7IHRoZW4NCisgICAg aWYgdGVzdCAke1NFTkRNQUlMJSVxbWFpbC1pbmplY3R9ICE9ICRTRU5ETUFJ TDsgdGhlbg0KKwlTRU5ETUFJTD0iJFNFTkRNQUlMIC1mIDxtbV9zZW5kZXI+ IDxtbV9yZWNpcGllbnRzPiINCisgICAgZWxpZiB0ZXN0ICR7U0VORE1BSUwl JXNlbmRtYWlsfSAhPSAkU0VORE1BSUw7IHRoZW4NCisJU0VORE1BSUw9IiRT RU5ETUFJTCAtZiA8bW1fc2VuZGVyPiA8bW1fcmVjaXBpZW50cz4iDQorICAg IGVsc2UNCisJU0VORE1BSUw9DQorICAgIGZpDQorZmkNCitlY2hvICIkYWNf dCIiJFNFTkRNQUlMIiAxPiY2DQorcm0gLWYgY29uZnRlc3Qub3V0IGNvbmZ0 ZXN0LnB5DQogDQogIyBmaWd1cmUgb3V0IHRoZSBERUZBVUxUX0hPU1RfTkFN RSBhbmQgREVGQVVMVF9VUkwNCiANCkBAIC0xMjg3LDE0ICsxMzQxLDE0IEBA DQogJFBZVEhPTiBjb25mdGVzdC5weQ0KIA0KIGVjaG8gJGFjX24gImNoZWNr aW5nIGZvciBkZWZhdWx0IGZ1bGx5IHF1YWxpZmllZCBob3N0IG5hbWUiIi4u LiAkYWNfYyIgMT4mNg0KLWVjaG8gImNvbmZpZ3VyZToxMjkxOiBjaGVja2lu ZyBmb3IgZGVmYXVsdCBmdWxseSBxdWFsaWZpZWQgaG9zdCBuYW1lIiA+JjUN CitlY2hvICJjb25maWd1cmU6MTM0NTogY2hlY2tpbmcgZm9yIGRlZmF1bHQg ZnVsbHkgcXVhbGlmaWVkIGhvc3QgbmFtZSIgPiY1DQogaWYgdGVzdCAteiAi JEZRRE4iDQogdGhlbg0KICAgICBGUUROPWBoZWFkIC0xIGNvbmZ0ZXN0Lm91 dGANCiBmaQ0KIGVjaG8gIiRhY190IiIkRlFETiIgMT4mNg0KIGVjaG8gJGFj X24gImNoZWNraW5nIGZvciBkZWZhdWx0IFVSTCBob3N0IGNvbXBvbmVudCIi Li4uICRhY19jIiAxPiY2DQotZWNobyAiY29uZmlndXJlOjEyOTg6IGNoZWNr aW5nIGZvciBkZWZhdWx0IFVSTCBob3N0IGNvbXBvbmVudCIgPiY1DQorZWNo byAiY29uZmlndXJlOjEzNTI6IGNoZWNraW5nIGZvciBkZWZhdWx0IFVSTCBo b3N0IGNvbXBvbmVudCIgPiY1DQogaWYgdGVzdCAteiAiJFVSTCINCiB0aGVu DQogICAgIFVSTD1gdGFpbCAtMSBjb25mdGVzdC5vdXRgDQpAQCAtMTMwNiwx MiArMTM2MCwxMiBAQA0KIGZvciBhY19mdW5jIGluIHN0cmVycm9yDQogZG8N CiBlY2hvICRhY19uICJjaGVja2luZyBmb3IgJGFjX2Z1bmMiIi4uLiAkYWNf YyIgMT4mNg0KLWVjaG8gImNvbmZpZ3VyZToxMzEwOiBjaGVja2luZyBmb3Ig JGFjX2Z1bmMiID4mNQ0KK2VjaG8gImNvbmZpZ3VyZToxMzY0OiBjaGVja2lu ZyBmb3IgJGFjX2Z1bmMiID4mNQ0KIGlmIGV2YWwgInRlc3QgXCJgZWNobyAn JCcneydhY19jdl9mdW5jXyRhY19mdW5jJytzZXR9J2BcIiA9IHNldCI7IHRo ZW4NCiAgIGVjaG8gJGFjX24gIihjYWNoZWQpICRhY19jIiAxPiY2DQogZWxz ZQ0KICAgY2F0ID4gY29uZnRlc3QuJGFjX2V4dCA8PEVPRg0KLSNsaW5lIDEz MTUgImNvbmZpZ3VyZSINCisjbGluZSAxMzY5ICJjb25maWd1cmUiDQogI2lu Y2x1ZGUgImNvbmZkZWZzLmgiDQogLyogU3lzdGVtIGhlYWRlciB0byBkZWZp bmUgX19zdHViIG1hY3JvcyBhbmQgaG9wZWZ1bGx5IGZldyBwcm90b3R5cGVz LA0KICAgICB3aGljaCBjYW4gY29uZmxpY3Qgd2l0aCBjaGFyICRhY19mdW5j KCk7IGJlbG93LiAgKi8NCkBAIC0xMzM0LDcgKzEzODgsNyBAQA0KIA0KIDsg cmV0dXJuIDA7IH0NCiBFT0YNCi1pZiB7IChldmFsIGVjaG8gY29uZmlndXJl OjEzMzg6IFwiJGFjX2xpbmtcIikgMT4mNTsgKGV2YWwgJGFjX2xpbmspIDI+ JjU7IH0gJiYgdGVzdCAtcyBjb25mdGVzdDsgdGhlbg0KK2lmIHsgKGV2YWwg ZWNobyBjb25maWd1cmU6MTM5MjogXCIkYWNfbGlua1wiKSAxPiY1OyAoZXZh bCAkYWNfbGluaykgMj4mNTsgfSAmJiB0ZXN0IC1zIGNvbmZ0ZXN0OyB0aGVu DQogICBybSAtcmYgY29uZnRlc3QqDQogICBldmFsICJhY19jdl9mdW5jXyRh Y19mdW5jPXllcyINCiBlbHNlDQpAQCAtMTM2MSw3ICsxNDE1LDcgQEANCiAN CiAjIENoZWNrcyBmb3IgaGVhZGVyIGZpbGVzLg0KIGVjaG8gJGFjX24gImNo ZWNraW5nIGhvdyB0byBydW4gdGhlIEMgcHJlcHJvY2Vzc29yIiIuLi4gJGFj X2MiIDE+JjYNCi1lY2hvICJjb25maWd1cmU6MTM2NTogY2hlY2tpbmcgaG93 IHRvIHJ1biB0aGUgQyBwcmVwcm9jZXNzb3IiID4mNQ0KK2VjaG8gImNvbmZp Z3VyZToxNDE5OiBjaGVja2luZyBob3cgdG8gcnVuIHRoZSBDIHByZXByb2Nl c3NvciIgPiY1DQogIyBPbiBTdW5zLCBzb21ldGltZXMgJENQUCBuYW1lcyBh IGRpcmVjdG9yeS4NCiBpZiB0ZXN0IC1uICIkQ1BQIiAmJiB0ZXN0IC1kICIk Q1BQIjsgdGhlbg0KICAgQ1BQPQ0KQEAgLTEzNzYsMTMgKzE0MzAsMTMgQEAN CiAgICMgT24gdGhlIE5lWFQsIGNjIC1FIHJ1bnMgdGhlIGNvZGUgdGhyb3Vn aCB0aGUgY29tcGlsZXIncyBwYXJzZXIsDQogICAjIG5vdCBqdXN0IHRocm91 Z2ggY3BwLg0KICAgY2F0ID4gY29uZnRlc3QuJGFjX2V4dCA8PEVPRg0KLSNs aW5lIDEzODAgImNvbmZpZ3VyZSINCisjbGluZSAxNDM0ICJjb25maWd1cmUi DQogI2luY2x1ZGUgImNvbmZkZWZzLmgiDQogI2luY2x1ZGUgPGFzc2VydC5o Pg0KIFN5bnRheCBFcnJvcg0KIEVPRg0KIGFjX3RyeT0iJGFjX2NwcCBjb25m dGVzdC4kYWNfZXh0ID4vZGV2L251bGwgMj5jb25mdGVzdC5vdXQiDQoteyAo ZXZhbCBlY2hvIGNvbmZpZ3VyZToxMzg2OiBcIiRhY190cnlcIikgMT4mNTsg KGV2YWwgJGFjX3RyeSkgMj4mNTsgfQ0KK3sgKGV2YWwgZWNobyBjb25maWd1 cmU6MTQ0MDogXCIkYWNfdHJ5XCIpIDE+JjU7IChldmFsICRhY190cnkpIDI+ JjU7IH0NCiBhY19lcnI9YGdyZXAgLXYgJ14gKisnIGNvbmZ0ZXN0Lm91dGAN CiBpZiB0ZXN0IC16ICIkYWNfZXJyIjsgdGhlbg0KICAgOg0KQEAgLTEzOTMs MTMgKzE0NDcsMTMgQEANCiAgIHJtIC1yZiBjb25mdGVzdCoNCiAgIENQUD0i JHtDQy1jY30gLUUgLXRyYWRpdGlvbmFsLWNwcCINCiAgIGNhdCA+IGNvbmZ0 ZXN0LiRhY19leHQgPDxFT0YNCi0jbGluZSAxMzk3ICJjb25maWd1cmUiDQor I2xpbmUgMTQ1MSAiY29uZmlndXJlIg0KICNpbmNsdWRlICJjb25mZGVmcy5o Ig0KICNpbmNsdWRlIDxhc3NlcnQuaD4NCiBTeW50YXggRXJyb3INCiBFT0YN CiBhY190cnk9IiRhY19jcHAgY29uZnRlc3QuJGFjX2V4dCA+L2Rldi9udWxs IDI+Y29uZnRlc3Qub3V0Ig0KLXsgKGV2YWwgZWNobyBjb25maWd1cmU6MTQw MzogXCIkYWNfdHJ5XCIpIDE+JjU7IChldmFsICRhY190cnkpIDI+JjU7IH0N Cit7IChldmFsIGVjaG8gY29uZmlndXJlOjE0NTc6IFwiJGFjX3RyeVwiKSAx PiY1OyAoZXZhbCAkYWNfdHJ5KSAyPiY1OyB9DQogYWNfZXJyPWBncmVwIC12 ICdeICorJyBjb25mdGVzdC5vdXRgDQogaWYgdGVzdCAteiAiJGFjX2VyciI7 IHRoZW4NCiAgIDoNCkBAIC0xNDIyLDEyICsxNDc2LDEyIEBADQogZWNobyAi JGFjX3QiIiRDUFAiIDE+JjYNCiANCiBlY2hvICRhY19uICJjaGVja2luZyBm b3IgQU5TSSBDIGhlYWRlciBmaWxlcyIiLi4uICRhY19jIiAxPiY2DQotZWNo byAiY29uZmlndXJlOjE0MjY6IGNoZWNraW5nIGZvciBBTlNJIEMgaGVhZGVy IGZpbGVzIiA+JjUNCitlY2hvICJjb25maWd1cmU6MTQ4MDogY2hlY2tpbmcg Zm9yIEFOU0kgQyBoZWFkZXIgZmlsZXMiID4mNQ0KIGlmIGV2YWwgInRlc3Qg XCJgZWNobyAnJCcneydhY19jdl9oZWFkZXJfc3RkYycrc2V0fSdgXCIgPSBz ZXQiOyB0aGVuDQogICBlY2hvICRhY19uICIoY2FjaGVkKSAkYWNfYyIgMT4m Ng0KIGVsc2UNCiAgIGNhdCA+IGNvbmZ0ZXN0LiRhY19leHQgPDxFT0YNCi0j bGluZSAxNDMxICJjb25maWd1cmUiDQorI2xpbmUgMTQ4NSAiY29uZmlndXJl Ig0KICNpbmNsdWRlICJjb25mZGVmcy5oIg0KICNpbmNsdWRlIDxzdGRsaWIu aD4NCiAjaW5jbHVkZSA8c3RkYXJnLmg+DQpAQCAtMTQzNSw3ICsxNDg5LDcg QEANCiAjaW5jbHVkZSA8ZmxvYXQuaD4NCiBFT0YNCiBhY190cnk9IiRhY19j cHAgY29uZnRlc3QuJGFjX2V4dCA+L2Rldi9udWxsIDI+Y29uZnRlc3Qub3V0 Ig0KLXsgKGV2YWwgZWNobyBjb25maWd1cmU6MTQzOTogXCIkYWNfdHJ5XCIp IDE+JjU7IChldmFsICRhY190cnkpIDI+JjU7IH0NCit7IChldmFsIGVjaG8g Y29uZmlndXJlOjE0OTM6IFwiJGFjX3RyeVwiKSAxPiY1OyAoZXZhbCAkYWNf dHJ5KSAyPiY1OyB9DQogYWNfZXJyPWBncmVwIC12ICdeICorJyBjb25mdGVz dC5vdXRgDQogaWYgdGVzdCAteiAiJGFjX2VyciI7IHRoZW4NCiAgIHJtIC1y ZiBjb25mdGVzdCoNCkBAIC0xNDUyLDcgKzE1MDYsNyBAQA0KIGlmIHRlc3Qg JGFjX2N2X2hlYWRlcl9zdGRjID0geWVzOyB0aGVuDQogICAjIFN1bk9TIDQu eCBzdHJpbmcuaCBkb2VzIG5vdCBkZWNsYXJlIG1lbSosIGNvbnRyYXJ5IHRv IEFOU0kuDQogY2F0ID4gY29uZnRlc3QuJGFjX2V4dCA8PEVPRg0KLSNsaW5l IDE0NTYgImNvbmZpZ3VyZSINCisjbGluZSAxNTEwICJjb25maWd1cmUiDQog I2luY2x1ZGUgImNvbmZkZWZzLmgiDQogI2luY2x1ZGUgPHN0cmluZy5oPg0K IEVPRg0KQEAgLTE0NzAsNyArMTUyNCw3IEBADQogaWYgdGVzdCAkYWNfY3Zf aGVhZGVyX3N0ZGMgPSB5ZXM7IHRoZW4NCiAgICMgSVNDIDIuMC4yIHN0ZGxp Yi5oIGRvZXMgbm90IGRlY2xhcmUgZnJlZSwgY29udHJhcnkgdG8gQU5TSS4N CiBjYXQgPiBjb25mdGVzdC4kYWNfZXh0IDw8RU9GDQotI2xpbmUgMTQ3NCAi Y29uZmlndXJlIg0KKyNsaW5lIDE1MjggImNvbmZpZ3VyZSINCiAjaW5jbHVk ZSAiY29uZmRlZnMuaCINCiAjaW5jbHVkZSA8c3RkbGliLmg+DQogRU9GDQpA QCAtMTQ5MSw3ICsxNTQ1LDcgQEANCiAgIDoNCiBlbHNlDQogICBjYXQgPiBj b25mdGVzdC4kYWNfZXh0IDw8RU9GDQotI2xpbmUgMTQ5NSAiY29uZmlndXJl Ig0KKyNsaW5lIDE1NDkgImNvbmZpZ3VyZSINCiAjaW5jbHVkZSAiY29uZmRl ZnMuaCINCiAjaW5jbHVkZSA8Y3R5cGUuaD4NCiAjZGVmaW5lIElTTE9XRVIo YykgKCdhJyA8PSAoYykgJiYgKGMpIDw9ICd6JykNCkBAIC0xNTAyLDcgKzE1 NTYsNyBAQA0KIGV4aXQgKDApOyB9DQogDQogRU9GDQotaWYgeyAoZXZhbCBl Y2hvIGNvbmZpZ3VyZToxNTA2OiBcIiRhY19saW5rXCIpIDE+JjU7IChldmFs ICRhY19saW5rKSAyPiY1OyB9ICYmIHRlc3QgLXMgY29uZnRlc3QgJiYgKC4v Y29uZnRlc3Q7IGV4aXQpIDI+L2Rldi9udWxsDQoraWYgeyAoZXZhbCBlY2hv IGNvbmZpZ3VyZToxNTYwOiBcIiRhY19saW5rXCIpIDE+JjU7IChldmFsICRh Y19saW5rKSAyPiY1OyB9ICYmIHRlc3QgLXMgY29uZnRlc3QgJiYgKC4vY29u ZnRlc3Q7IGV4aXQpIDI+L2Rldi9udWxsDQogdGhlbg0KICAgOg0KIGVsc2UN CkBAIC0xNTI5LDE3ICsxNTgzLDE3IEBADQogZG8NCiBhY19zYWZlPWBlY2hv ICIkYWNfaGRyIiB8IHNlZCAneSUuLystJV9fcF8lJ2ANCiBlY2hvICRhY19u ICJjaGVja2luZyBmb3IgJGFjX2hkciIiLi4uICRhY19jIiAxPiY2DQotZWNo byAiY29uZmlndXJlOjE1MzM6IGNoZWNraW5nIGZvciAkYWNfaGRyIiA+JjUN CitlY2hvICJjb25maWd1cmU6MTU4NzogY2hlY2tpbmcgZm9yICRhY19oZHIi ID4mNQ0KIGlmIGV2YWwgInRlc3QgXCJgZWNobyAnJCcneydhY19jdl9oZWFk ZXJfJGFjX3NhZmUnK3NldH0nYFwiID0gc2V0IjsgdGhlbg0KICAgZWNobyAk YWNfbiAiKGNhY2hlZCkgJGFjX2MiIDE+JjYNCiBlbHNlDQogICBjYXQgPiBj b25mdGVzdC4kYWNfZXh0IDw8RU9GDQotI2xpbmUgMTUzOCAiY29uZmlndXJl Ig0KKyNsaW5lIDE1OTIgImNvbmZpZ3VyZSINCiAjaW5jbHVkZSAiY29uZmRl ZnMuaCINCiAjaW5jbHVkZSA8JGFjX2hkcj4NCiBFT0YNCiBhY190cnk9IiRh Y19jcHAgY29uZnRlc3QuJGFjX2V4dCA+L2Rldi9udWxsIDI+Y29uZnRlc3Qu b3V0Ig0KLXsgKGV2YWwgZWNobyBjb25maWd1cmU6MTU0MzogXCIkYWNfdHJ5 XCIpIDE+JjU7IChldmFsICRhY190cnkpIDI+JjU7IH0NCit7IChldmFsIGVj aG8gY29uZmlndXJlOjE1OTc6IFwiJGFjX3RyeVwiKSAxPiY1OyAoZXZhbCAk YWNfdHJ5KSAyPiY1OyB9DQogYWNfZXJyPWBncmVwIC12ICdeICorJyBjb25m dGVzdC5vdXRgDQogaWYgdGVzdCAteiAiJGFjX2VyciI7IHRoZW4NCiAgIHJt IC1yZiBjb25mdGVzdCoNCkBAIC0xNTY4LDEyICsxNjIyLDEyIEBADQogDQog IyBDaGVja3MgZm9yIHR5cGVkZWZzLCBzdHJ1Y3R1cmVzLCBhbmQgY29tcGls ZXIgY2hhcmFjdGVyaXN0aWNzLg0KIGVjaG8gJGFjX24gImNoZWNraW5nIGZv ciB1aWRfdCBpbiBzeXMvdHlwZXMuaCIiLi4uICRhY19jIiAxPiY2DQotZWNo byAiY29uZmlndXJlOjE1NzI6IGNoZWNraW5nIGZvciB1aWRfdCBpbiBzeXMv dHlwZXMuaCIgPiY1DQorZWNobyAiY29uZmlndXJlOjE2MjY6IGNoZWNraW5n IGZvciB1aWRfdCBpbiBzeXMvdHlwZXMuaCIgPiY1DQogaWYgZXZhbCAidGVz dCBcImBlY2hvICckJyd7J2FjX2N2X3R5cGVfdWlkX3QnK3NldH0nYFwiID0g c2V0IjsgdGhlbg0KICAgZWNobyAkYWNfbiAiKGNhY2hlZCkgJGFjX2MiIDE+ JjYNCiBlbHNlDQogICBjYXQgPiBjb25mdGVzdC4kYWNfZXh0IDw8RU9GDQot I2xpbmUgMTU3NyAiY29uZmlndXJlIg0KKyNsaW5lIDE2MzEgImNvbmZpZ3Vy ZSINCiAjaW5jbHVkZSAiY29uZmRlZnMuaCINCiAjaW5jbHVkZSA8c3lzL3R5 cGVzLmg+DQogRU9GDQpAQCAtMTYwMiw3ICsxNjU2LDcgQEANCiBmaQ0KIA0K IGVjaG8gJGFjX24gImNoZWNraW5nIHR5cGUgb2YgYXJyYXkgYXJndW1lbnQg dG8gZ2V0Z3JvdXBzIiIuLi4gJGFjX2MiIDE+JjYNCi1lY2hvICJjb25maWd1 cmU6MTYwNjogY2hlY2tpbmcgdHlwZSBvZiBhcnJheSBhcmd1bWVudCB0byBn ZXRncm91cHMiID4mNQ0KK2VjaG8gImNvbmZpZ3VyZToxNjYwOiBjaGVja2lu ZyB0eXBlIG9mIGFycmF5IGFyZ3VtZW50IHRvIGdldGdyb3VwcyIgPiY1DQog aWYgZXZhbCAidGVzdCBcImBlY2hvICckJyd7J2FjX2N2X3R5cGVfZ2V0Z3Jv dXBzJytzZXR9J2BcIiA9IHNldCI7IHRoZW4NCiAgIGVjaG8gJGFjX24gIihj YWNoZWQpICRhY19jIiAxPiY2DQogZWxzZQ0KQEAgLTE2MTAsNyArMTY2NCw3 IEBADQogICBhY19jdl90eXBlX2dldGdyb3Vwcz1jcm9zcw0KIGVsc2UNCiAg IGNhdCA+IGNvbmZ0ZXN0LiRhY19leHQgPDxFT0YNCi0jbGluZSAxNjE0ICJj b25maWd1cmUiDQorI2xpbmUgMTY2OCAiY29uZmlndXJlIg0KICNpbmNsdWRl ICJjb25mZGVmcy5oIg0KIA0KIC8qIFRoYW5rcyB0byBNaWtlIFJlbmRlbGwg Zm9yIHRoaXMgdGVzdC4gICovDQpAQCAtMTYzNSw3ICsxNjg5LDcgQEANCiB9 DQogDQogRU9GDQotaWYgeyAoZXZhbCBlY2hvIGNvbmZpZ3VyZToxNjM5OiBc IiRhY19saW5rXCIpIDE+JjU7IChldmFsICRhY19saW5rKSAyPiY1OyB9ICYm IHRlc3QgLXMgY29uZnRlc3QgJiYgKC4vY29uZnRlc3Q7IGV4aXQpIDI+L2Rl di9udWxsDQoraWYgeyAoZXZhbCBlY2hvIGNvbmZpZ3VyZToxNjkzOiBcIiRh Y19saW5rXCIpIDE+JjU7IChldmFsICRhY19saW5rKSAyPiY1OyB9ICYmIHRl c3QgLXMgY29uZnRlc3QgJiYgKC4vY29uZnRlc3Q7IGV4aXQpIDI+L2Rldi9u dWxsDQogdGhlbg0KICAgICBhY19jdl90eXBlX2dldGdyb3Vwcz1naWRfdA0K IGVsc2UNCkBAIC0xNjQ5LDcgKzE3MDMsNyBAQA0KIA0KIGlmIHRlc3QgJGFj X2N2X3R5cGVfZ2V0Z3JvdXBzID0gY3Jvc3M7IHRoZW4NCiAgICAgICAgIGNh dCA+IGNvbmZ0ZXN0LiRhY19leHQgPDxFT0YNCi0jbGluZSAxNjUzICJjb25m aWd1cmUiDQorI2xpbmUgMTcwNyAiY29uZmlndXJlIg0KICNpbmNsdWRlICJj b25mZGVmcy5oIg0KICNpbmNsdWRlIDx1bmlzdGQuaD4NCiBFT0YNCkBAIC0x Njc1LDEyICsxNzI5LDEyIEBADQogDQogIyBDaGVja3MgZm9yIGxpYnJhcnkg ZnVuY3Rpb25zLg0KIGVjaG8gJGFjX24gImNoZWNraW5nIGZvciB2cHJpbnRm IiIuLi4gJGFjX2MiIDE+JjYNCi1lY2hvICJjb25maWd1cmU6MTY3OTogY2hl Y2tpbmcgZm9yIHZwcmludGYiID4mNQ0KK2VjaG8gImNvbmZpZ3VyZToxNzMz OiBjaGVja2luZyBmb3IgdnByaW50ZiIgPiY1DQogaWYgZXZhbCAidGVzdCBc ImBlY2hvICckJyd7J2FjX2N2X2Z1bmNfdnByaW50Zicrc2V0fSdgXCIgPSBz ZXQiOyB0aGVuDQogICBlY2hvICRhY19uICIoY2FjaGVkKSAkYWNfYyIgMT4m Ng0KIGVsc2UNCiAgIGNhdCA+IGNvbmZ0ZXN0LiRhY19leHQgPDxFT0YNCi0j bGluZSAxNjg0ICJjb25maWd1cmUiDQorI2xpbmUgMTczOCAiY29uZmlndXJl Ig0KICNpbmNsdWRlICJjb25mZGVmcy5oIg0KIC8qIFN5c3RlbSBoZWFkZXIg dG8gZGVmaW5lIF9fc3R1YiBtYWNyb3MgYW5kIGhvcGVmdWxseSBmZXcgcHJv dG90eXBlcywNCiAgICAgd2hpY2ggY2FuIGNvbmZsaWN0IHdpdGggY2hhciB2 cHJpbnRmKCk7IGJlbG93LiAgKi8NCkBAIC0xNzAzLDcgKzE3NTcsNyBAQA0K IA0KIDsgcmV0dXJuIDA7IH0NCiBFT0YNCi1pZiB7IChldmFsIGVjaG8gY29u ZmlndXJlOjE3MDc6IFwiJGFjX2xpbmtcIikgMT4mNTsgKGV2YWwgJGFjX2xp bmspIDI+JjU7IH0gJiYgdGVzdCAtcyBjb25mdGVzdDsgdGhlbg0KK2lmIHsg KGV2YWwgZWNobyBjb25maWd1cmU6MTc2MTogXCIkYWNfbGlua1wiKSAxPiY1 OyAoZXZhbCAkYWNfbGluaykgMj4mNTsgfSAmJiB0ZXN0IC1zIGNvbmZ0ZXN0 OyB0aGVuDQogICBybSAtcmYgY29uZnRlc3QqDQogICBldmFsICJhY19jdl9m dW5jX3ZwcmludGY9eWVzIg0KIGVsc2UNCkBAIC0xNzI3LDEyICsxNzgxLDEy IEBADQogDQogaWYgdGVzdCAiJGFjX2N2X2Z1bmNfdnByaW50ZiIgIT0geWVz OyB0aGVuDQogZWNobyAkYWNfbiAiY2hlY2tpbmcgZm9yIF9kb3BybnQiIi4u LiAkYWNfYyIgMT4mNg0KLWVjaG8gImNvbmZpZ3VyZToxNzMxOiBjaGVja2lu ZyBmb3IgX2RvcHJudCIgPiY1DQorZWNobyAiY29uZmlndXJlOjE3ODU6IGNo ZWNraW5nIGZvciBfZG9wcm50IiA+JjUNCiBpZiBldmFsICJ0ZXN0IFwiYGVj aG8gJyQnJ3snYWNfY3ZfZnVuY19fZG9wcm50JytzZXR9J2BcIiA9IHNldCI7 IHRoZW4NCiAgIGVjaG8gJGFjX24gIihjYWNoZWQpICRhY19jIiAxPiY2DQog ZWxzZQ0KICAgY2F0ID4gY29uZnRlc3QuJGFjX2V4dCA8PEVPRg0KLSNsaW5l IDE3MzYgImNvbmZpZ3VyZSINCisjbGluZSAxNzkwICJjb25maWd1cmUiDQog I2luY2x1ZGUgImNvbmZkZWZzLmgiDQogLyogU3lzdGVtIGhlYWRlciB0byBk ZWZpbmUgX19zdHViIG1hY3JvcyBhbmQgaG9wZWZ1bGx5IGZldyBwcm90b3R5 cGVzLA0KICAgICB3aGljaCBjYW4gY29uZmxpY3Qgd2l0aCBjaGFyIF9kb3By bnQoKTsgYmVsb3cuICAqLw0KQEAgLTE3NTUsNyArMTgwOSw3IEBADQogDQog OyByZXR1cm4gMDsgfQ0KIEVPRg0KLWlmIHsgKGV2YWwgZWNobyBjb25maWd1 cmU6MTc1OTogXCIkYWNfbGlua1wiKSAxPiY1OyAoZXZhbCAkYWNfbGluaykg Mj4mNTsgfSAmJiB0ZXN0IC1zIGNvbmZ0ZXN0OyB0aGVuDQoraWYgeyAoZXZh bCBlY2hvIGNvbmZpZ3VyZToxODEzOiBcIiRhY19saW5rXCIpIDE+JjU7IChl dmFsICRhY19saW5rKSAyPiY1OyB9ICYmIHRlc3QgLXMgY29uZnRlc3Q7IHRo ZW4NCiAgIHJtIC1yZiBjb25mdGVzdCoNCiAgIGV2YWwgImFjX2N2X2Z1bmNf X2RvcHJudD15ZXMiDQogZWxzZQ0KQEAgLTE5NDIsNiArMTk5Niw3IEBADQog cyVATUFJTF9HSURAJSRNQUlMX0dJRCVnDQogcyVAQ0dJX0dJREAlJENHSV9H SUQlZw0KIHMlQENHSUVYVEAlJENHSUVYVCVnDQorcyVAU0VORE1BSUxAJSRT RU5ETUFJTCVnDQogcyVARlFETkAlJEZRRE4lZw0KIHMlQFVSTEAlJFVSTCVn DQogcyVAQ1BQQCUkQ1BQJWcNCmRpZmYgLXJ1TiBtYWlsbWFuLTItY2dpZXh0 L2NvbmZpZ3VyZS5pbiBtYWlsbWFuL2NvbmZpZ3VyZS5pbg0KLS0tIG1haWxt YW4tMi1jZ2lleHQvY29uZmlndXJlLmluCUZyaSBKYW4gIDggMDk6MzA6MjIg MTk5OQ0KKysrIG1haWxtYW4vY29uZmlndXJlLmluCUZyaSBKYW4gIDggMDk6 NDU6MjMgMTk5OQ0KQEAgLTI1OCw3ICsyNTgsNyBAQA0KIGlmIHRlc3QgLXog IiR3aXRoX21haWxfZ2lkIg0KIHRoZW4NCiAgICAgQUNfQ0FDSEVfVkFMKGFj X2N2X2dyb3VwX21haWwsIFtkbmwNCi0gICAgYWNfY3ZfZ3JvdXBfbWFpbD0i b3RoZXIgbWFpbCBkYWVtb24iXSkNCisgICAgYWNfY3ZfZ3JvdXBfbWFpbD0i bm9maWxlcyBvdGhlciBtYWlsIGRhZW1vbiJdKQ0KIGVsc2UNCiAgICAgYWNf Y3ZfZ3JvdXBfbWFpbD0kd2l0aF9tYWlsX2dpZA0KIGZpDQpAQCAtMjk3LDEy ICsyOTcsMTQgQEANCiAqKioqKiBkb2N1bWVudGF0aW9uLCBhbmQgdGhlIElO U1RBTEwgZmlsZSBmb3IgZGV0YWlsc10pDQogZmkNCiANCisjTU1fRklORF9V U0VSX0lEKEFMSUFTX1VJRCwgbWFpbG1hbiwgYWxpYXNfd3JhcHBlcikNCisj TU1fRklORF9HUk9VUF9JRChBTElBU19HSUQsIG1haWwsIGFsaWFzX3dyYXBw ZXIpDQogDQogIyBDR0kgZXh0ZW5zaW9uIGNoZWNraW5nDQogQUNfU1VCU1Qo Q0dJRVhUKQ0KIEFDX01TR19DSEVDS0lORyhmb3IgQ0dJIGV4dGVuc2lvbikN CiBBQ19BUkdfV0lUSChjZ2ktZXh0LCBbDQotICAgICAgIC0td2l0aC1jZ2kt ZXh0ICAgICAgICBzcGVjaWZ5IGV4dGVuc2lvbnMgb2YgQ0dJIHByb2dyYW1z XSkNCisJLS13aXRoLWNnaS1leHQgICAgICAgIHNwZWNpZnkgZXh0ZW5zaW9u cyBvZiBDR0kgcHJvZ3JhbXNdKQ0KIGlmIHRlc3QgLXogIiR3aXRoX2NnaV9l eHQiDQogdGhlbg0KICAgICBDR0lFWFQ9JycNCkBAIC0zMTIsOCArMzE0LDQ4 IEBADQogZmkNCiBBQ19NU0dfUkVTVUxUKCR3aXRoX2NnaV9leHQpDQogDQot I01NX0ZJTkRfVVNFUl9JRChBTElBU19VSUQsIG1haWxtYW4sIGFsaWFzX3dy YXBwZXIpDQotI01NX0ZJTkRfR1JPVVBfSUQoQUxJQVNfR0lELCBtYWlsLCBh bGlhc193cmFwcGVyKQ0KK0FDX01TR19DSEVDS0lORyhmb3Igc2VuZG1haWwg cHJvZ3JhbXMpDQorQUNfQVJHX1dJVEgoc2VuZG1haWwsIFsNCisJLS13aXRo LXNlbmRtYWlsICAgICAgZG8gZGVsaXZlcmllcyB3aXRoIHRoaXMgcHJvZ3Jh bV0pDQoraWYgdGVzdCAteiAiJHdpdGhfc2VuZG1haWwiDQordGhlbg0KKyAg ICBBQ19DQUNIRV9WQUwoYWNfY3Zfc2VuZG1haWwsIFtkbmwNCisJYWNfY3Zf c2VuZG1haWw9Ii92YXIvcW1haWwvYmluL3FtYWlsLWluamVjdCAvdXNyL2xp Yi9zZW5kbWFpbCAvdXNyL3NiaW4vc2VuZG1haWwgL2V0Yy9zZW5kbWFpbCJd KQ0KK2Vsc2UNCisgICAgYWNfY3Zfc2VuZG1haWw9JHdpdGhfc2VuZG1haWwN CitmaQ0KK0FDX1NVQlNUKFNFTkRNQUlMKQ0KK2NoYW5nZXF1b3RlKCwpDQor Y2F0ID4gY29uZnRlc3QucHkgPDxFT0YNCitpbXBvcnQgb3MsIHN0cmluZw0K K2ZpbCA9ICcnDQorZm9yIGZsZSBpbiBzdHJpbmcuc3BsaXQoIiRhY19jdl9z ZW5kbWFpbCIpOg0KKyAgICB0cnk6DQorCWwgPSBvcy5zdGF0KGZsZSkNCisJ aWYgbFswXSAmIDB4MTExOg0KKwkgICAgZmlsID0gZmxlDQorCSAgICBicmVh aw0KKyAgICBleGNlcHQ6DQorCXBhc3MNCitmcCA9IG9wZW4oJ2NvbmZ0ZXN0 Lm91dCcsICd3JykNCitmcC53cml0ZSgnJXNcbicgJSBmaWwpDQorZnAuY2xv c2UNCitFT0YNCitjaGFuZ2VxdW90ZShbLCBdKQ0KKyRQWVRIT04gY29uZnRl c3QucHkNCitTRU5ETUFJTD1gY2F0IGNvbmZ0ZXN0Lm91dGANCisjIFBhcmFt ZXRlcnMgYXJlIHRoZSBzYW1lIGZvciBxbWFpbC1pbmplY3QgYW5kIHNlbmRt YWlsLWNsb25lcyBidXQgd2hvIGtub3dzPw0KK2lmIHRlc3QgISAteiAkU0VO RE1BSUw7IHRoZW4NCisgICAgaWYgdGVzdCAke1NFTkRNQUlMJSVxbWFpbC1p bmplY3R9ICE9ICRTRU5ETUFJTDsgdGhlbg0KKwlTRU5ETUFJTD0iJFNFTkRN QUlMIC1mIDxtbV9zZW5kZXI+IDxtbV9yZWNpcGllbnRzPiINCisgICAgZWxp ZiB0ZXN0ICR7U0VORE1BSUwlJXNlbmRtYWlsfSAhPSAkU0VORE1BSUw7IHRo ZW4NCisJU0VORE1BSUw9IiRTRU5ETUFJTCAtZiA8bW1fc2VuZGVyPiA8bW1f cmVjaXBpZW50cz4iDQorICAgIGVsc2UNCisJU0VORE1BSUw9DQorICAgIGZp DQorZmkNCitBQ19NU0dfUkVTVUxUKCRTRU5ETUFJTCkNCitybSAtZiBjb25m dGVzdC5vdXQgY29uZnRlc3QucHkNCiANCiAjIGZpZ3VyZSBvdXQgdGhlIERF RkFVTFRfSE9TVF9OQU1FIGFuZCBERUZBVUxUX1VSTA0KIEFDX1NVQlNUKEZR RE4pDQo= ---456965764-233999344-915788868=:3512-- From droege@uni-koblenz.de Fri Jan 8 11:46:46 1999 From: droege@uni-koblenz.de (Detlev Droege) Date: Fri, 8 Jan 99 12:46:46 +0100 Subject: [Mailman-Developers] Mailman 1.0b7 bug reports Message-ID: <199901081146.MAA19567@mailhost.uni-koblenz.de> Hi Mailman Developers, thanks for Mailman - its great to have that tool ! We did set up Mailman at http://mailhost.uni-koblenz.de/mailman/admin/ mostly to admin local user groups. I'm the list-admin of the single non-local group (EINST-Mitglieder). Most things run just fine, however I had following problems: 1 - I did a bulk subscribe for approx. 100 members via the HTML interface. I overlooked a bogus line when pasting the addresses into the textfield and Mailman generated a strange entry. A syntax check on the mail addresses would be helpful. [The bogus address had a pending closing paranthesis: "AUser@somewhere.com)" ] 2 - The abovementioned list of email addresses did contain mixed-case entries like "Detlev.Droege@uni-koblenz.de". Mailman did lowercase them in most places, but not in all places. The subscription welcome message to those members contained URLs like http://host/mailman/options/einst-mitglieder/Detlev.Droege@uni-koblenz.de to access the specific member record (note the upper case letters). The "options" program does not recognize these entries unles all letters are changed to lower case. Either the case in the generated mail should be changed or, even better, "options" should accept valid mail addresses in any case. 3 - When the first external member submitted an article, its From: address differed from the subscribed address, so I as the list admin was asked to approve the message. I did so, however the message was never sent out to the list members. It appears in the "post" logfile, it is archived in the HTML archive, but it was never mailed to the list members. Our postmaster could not detect any failure of our mail system nor any error messages. Is it possible Mailman just forgot to send it out ? 4 - As list admin I'd like to have an interface to change the mail address of list members. I allready got several requests to do so. It's a little boring to do so by unsubscribing the old and then subscribing the new address. Moreover, this generates a useles "Good Bye" and "Welcome" message which might confuse the subscriber. Anyway - Mailman is a great tool and I like it a lot ! Don't take this as complaint, but as my (very) small effort to make it even better. Detlev --- Detlev Droege, Uni Koblenz, FB Informatik, Rheinau 1, D-56075 Koblenz, Germany Fon: +49 261 287-2769 (NEU !) | Email: droege@informatik Fax: +49 261 287-2745 (NEU !) | .uni-koblenz.de From julian7@kva.hu Fri Jan 8 17:31:45 1999 From: julian7@kva.hu (Balazs Nagy) Date: Fri, 8 Jan 1999 18:31:45 +0100 (CET) Subject: [Mailman-Developers] Admindb bug Message-ID: Hiyas, There's an error in admindb in the login form. Here's the fast patch against the latest CVS snapshots: --- admindb.py.orig Fri Jan 8 18:23:22 1999 +++ admindb.py Fri Jan 8 18:23:44 1999 @@ -113,7 +113,7 @@ 'admlogin.txt', {'listname': list_name, 'path' : os.environ.get('REQUEST_URI', - '/mailman/admin/' + list_name), + '/mailman/admindb/' + list_name), 'message' : message, }) print text ... and of course against my patches: --- admindb.py.orig Fri Jan 8 18:20:15 1999 +++ admindb.py Fri Jan 8 17:45:02 1999 @@ -113,7 +113,7 @@ 'admlogin.txt', {'listname': list_name, 'path' : os.environ.get('REQUEST_URI', - '/mailman/' + mm_cfg.admin_cgi + '/' + list_name), + '/mailman/' + mm_cfg.admindb_cgi + '/' + list_name), 'message' : message, }) print text Regards: Jul -- Linux Supporting Center -- Red Hat Qmail packages -- http://lsc.kva.hu PGP 0x1DE3631D / A8 B4 92 EE 1F 55 27 C8 86 64 9C 42 41 A4 BD B8 Don't spell GLIB backwards! From grin@tolna.net Fri Jan 8 19:08:19 1999 From: grin@tolna.net (Peter Gervai) Date: Fri, 8 Jan 1999 20:08:19 +0100 Subject: [Mailman-Developers] is restricted unsubscribe possible? Message-ID: <19990108200819.H25894@mail.tolna.net> I think I failed to see how can I make a list set up so that its members cannot unsubscribe without owner's approval? (Or does "approval for subscribe" setting cover unsub messages as well?) I would like to use a list as our 'problem notification' service but I don't want to see clueless idiots, erm, I mean, windows users :) playing with subscriptions at all. It should be act just like a 'glorified alias file' (but much easier to handle). bye, grin From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Jan 8 19:39:05 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 8 Jan 1999 14:39:05 -0500 (EST) Subject: [Mailman-Developers] Little bug(?) in admindb References: <13973.43448.461046.183947@anthem.cnri.reston.va.us> Message-ID: <13974.24281.760791.768849@anthem.cnri.reston.va.us> >>>>> "BN" == Balazs Nagy writes: BN> I didn't have a mouse but a simple console screen with lynx. BN> Here's my new test: BN> With one pending: OK BN> With two or more pendings: I'm unable to reproduce this, but I can see how this might happen. Please try this patch instead. -Barry -------------------- snip snip -------------------- Index: admindb.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/Cgi/admindb.py,v retrieving revision 1.7 diff -c -r1.7 admindb.py *** admindb.py 1998/12/19 04:43:46 1.7 --- admindb.py 1999/01/08 19:34:49 *************** *** 192,199 **** ignore_subscribes = 1 SubscribeNone() for k in form.keys(): try: ! v = int(form[k].value) request_id = int(k) except ValueError: continue --- 192,202 ---- ignore_subscribes = 1 SubscribeNone() for k in form.keys(): + formv = form[k] + if type(formv) == types.ListType: + continue try: ! v = int(formv.value) request_id = int(k) except ValueError: continue From Harald.Meland@usit.uio.no Fri Jan 8 21:55:53 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 08 Jan 1999 22:55:53 +0100 Subject: [Mailman-Developers] fwd: Cron /usr/bin/python /home/mailman/cron/senddigests (fwd) In-Reply-To: Jerry Adlersfluegel's message of "Wed, 6 Jan 1999 17:20:55 -0600 (CST)" References: Message-ID: [Jerry Adlersfluegel] > Traceback (innermost last): > File "/home/mailman/cron/senddigests", line 37, in ? > main() > File "/home/mailman/cron/senddigests", line 34, in main > list.SendDigestIfAny() > File "/home/mailman/Mailman/Digester.py", line 194, in SendDigestIfAny > self.SendDigestOnSize(0) > File "/home/mailman/Mailman/Digester.py", line 206, in SendDigestOnSize > self.SendDigest() > File "/home/mailman/Mailman/Digester.py", line 290, in SendDigest > self.DeliverToList(d.Present(mime=0), > File "/home/mailman/Mailman/Deliverer.py", line 172, in DeliverToList > status = cmdproc.close() > IOError: (10, 'No child processes') > > > Any ideas? Yup. I believe this is a known problem with at least some RedHat cron daemons -- they run their jobs with some (rather vital, like SIGCHLD) signals set up to be ignored. Workaround: I think that adding something like this to the top of any script that is to be run from cron would work (as long as it is SIGCHLD that is being incorrectly ignored, anyway): import signal signal.signal(signal.SIGCHLD, signal.SIG_DFL) If this workaround does the job, it would IMHO be less obtrusive than the workaround currently in CVS. -- Harald From jerrya@fastrans.net Fri Jan 8 22:21:30 1999 From: jerrya@fastrans.net (Jerry Adlersfluegel) Date: Fri, 08 Jan 1999 16:21:30 -0600 Subject: [Mailman-Developers] fwd: Cron /usr/bin/python /home/mailman/cron/senddigests (fwd) References: Message-ID: <369684EA.4920C5CF@fastrans.net> Harald Meland wrote: > > [Jerry Adlersfluegel] > > > Traceback (innermost last): > > File "/home/mailman/cron/senddigests", line 37, in ? > > main() > > File "/home/mailman/cron/senddigests", line 34, in main > > list.SendDigestIfAny() > > File "/home/mailman/Mailman/Digester.py", line 194, in SendDigestIfAny > > self.SendDigestOnSize(0) > > File "/home/mailman/Mailman/Digester.py", line 206, in SendDigestOnSize > > self.SendDigest() > > File "/home/mailman/Mailman/Digester.py", line 290, in SendDigest > > self.DeliverToList(d.Present(mime=0), > > File "/home/mailman/Mailman/Deliverer.py", line 172, in DeliverToList > > status = cmdproc.close() > > IOError: (10, 'No child processes') > > > > > > Any ideas? > > Yup. I believe this is a known problem with at least some RedHat cron > daemons -- they run their jobs with some (rather vital, like SIGCHLD) > signals set up to be ignored. > > Workaround: I think that adding something like this to the top of any > script that is to be run from cron would work (as long as it is > SIGCHLD that is being incorrectly ignored, anyway): > > import signal > signal.signal(signal.SIGCHLD, signal.SIG_DFL) > > If this workaround does the job, it would IMHO be less obtrusive than > the workaround currently in CVS. > -- > Harald I have been paying attention, and that error report does not get sent every day. I think it only went out two or three times this week. I did not get that error today or yesterday. I haven't applied anything to the 1.0b7 installation. I'll pay attention to what happens. Thanks! From gstein@lyra.org Sat Jan 9 02:06:52 1999 From: gstein@lyra.org (Greg Stein) Date: Fri, 08 Jan 1999 18:06:52 -0800 Subject: [Mailman-Developers] Digests and Cron and Signals Message-ID: <3696B9BC.19691E55@lyra.org> [ responding from the archive, so this message will be formatted funny... ] ----INCLUDED MESSAGE---- I have upgraded mailman to the new release, 1.0b7, on my redhat 5 system. $ uname -a Linux jerrya 2.0.32 #4 Wed Jan 7 23:14:32 CST 1998 i486 unknown I still receive the following message every day when the digests go out. They are going out successfully, but this message still gets delivered. [snip of Cron Daemon traceback...] ----INCLUDED MESSAGE---- Actually, if you run MULTIPLE lists, then your mail is NOT being delivered. The traceback will occur on the FIRST mail list, preventing the rest from being delivered. I run into this EVERY day with mine and I patched my installation to ignore the error so that digests can go out for all lists. I put in a hack, though, to ignore it (similar to Barry's). I'm going to try Harald's signal patch (cool!) and report back on its success. If I stop getting my noon cron reports of failure, then we'll be golden. Note: mine is occuring on a RedHat 5.1 system. -g -- Greg Stein, http://www.lyra.org/ From gstein@lyra.org Sat Jan 9 02:16:17 1999 From: gstein@lyra.org (Greg Stein) Date: Fri, 08 Jan 1999 18:16:17 -0800 Subject: [Mailman-Developers] shipstopper bug Message-ID: <3696BBF0.31971360@lyra.org> This is a multi-part message in MIME format. --------------2F2A7A284F92DB72623DFFB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I've reported this before, and I will reiterate it again. Moreover, I would call it a "shipstopper" for the 1.0 release. I'm using 1.0b6 here. This has hit me FIVE times in the past 24 hours. Each time, I have to take manual action to fix things (as reported before). Basically, shutting down the sendmail listener to stop the mail loop, clearing the Mailman queue and sendmail queue of the loop-inducing garbage, and then bringing it back up. What happens is that somebody types in a request to the Mailman subscription page with a *local* mail address (i.e. no domain name). The confirmation email then gets sent. This bounces back to Mailman, but it doesn't understand that it is a bounce and tries to process the dumb thing. That fails massively (as seen in the attached mail), and responds to mailer-daemon with the error. More on this in a bit. What appears wonky is that Mailman seems to attempt to deliver the confirmation over and over, nonstop. Here is a portion of the mail log for RAB25492: Jan 8 17:18:19 ns1 sendmail[25492]: RAA25492: ... User unknown Jan 8 17:18:19 ns1 sendmail[25492]: lost input channel from localhost [127.0.0.1] Jan 8 17:18:19 ns1 sendmail[25492]: RAA25492: from=, size=0, class=0, pri=0, nrcpts=0, proto=SMTP, relay=localhost [127.0.0.1] Jan 8 17:18:19 ns1 sendmail[25492]: RAA25492: RAB25492: DSN: ... User unknown Jan 8 17:18:27 ns1 sendmail[25492]: RAB25492: to=|"/home/mailman/install/mail/wrapper mailcmd hognews", delay=00:00:08, xdelay=00:00:07, mailer=prog, stat=Sent Note the "lost input channel". I don't think that is right. The cycle above repeats at 17:18:32. This goes on until I kill it. In the above case, the mailer-deamon is responding to Mailman (the last line). Mailman then processes that mail, and returns a message like the attached garbage to root. I just deleted 1400 messages from my root mailbox. Some more information: In logs/error, I see the following traceback repeated every 30 minutes: Jan 08 11:12:07 1999 smtplib: Traceback (innermost last): smtplib: File "/home/mailman/install/cron/run_queue", line 31, in ? smtplib: OutgoingQueue.processQueue() smtplib: File "/home/mailman/install/Mailman/OutgoingQueue.py", line 38, in processQueue smtplib: Utils.TrySMTPDelivery(recip,sender,text,full_fname) smtplib: File "/home/mailman/install/Mailman/Utils.py", line 201, in TrySMTPDelivery smtplib: con.send(to=recipient,frm=sender,text=text) smtplib: File "/home/mailman/install/Mailman/smtplib.py", line 75, in send smtplib: self.getresp() smtplib: File "/home/mailman/install/Mailman/smtplib.py", line 147, in getresp smtplib: raise bad, resp smtplib: smtplib.error_proto : 550 ... User unknown I suspect that the "lost input channel" further above is due to a similar condition. The traceback drops the socket, fails to log anything, and fails to clear the confirmation email from the outgoing queue. Mailman processes the error response from mailer-daemon and drops it into the queue. It runs the queue which processes that response (flooding the root email box) along with the confirmation (again), which starts the loop again. I also believe that I now understand why my machine died back in August due to this bug, but that hasn't happened to me recently. Because of the queueing nature of Mailman, there is only one loop occurring at a time. HOWEVER: if that cron job wakes up and processes the queue, then it starts a second, simultaneous loop. If enough of those 30-minute cron-caused loop-creations occurs, then your machine is completely dead as it thrashes, trying to process all those loops. I've been catching them relatively soon in this past spate of them (although I did miss one last night for a long while, causing my loadavg to hit 15... heh. it's also a DNS server and its response became SLOWWWWWW... which led me to look into it) So, I see one or more errors here: 1) a possible traceback not being logged during Q processing 2) said traceback fouling the outgoing mail queue processing 3) should probably disallow domain-less addresses in all places 4) bounce detection needs to recognize the mail that caused the attached response (read between the lines for the content) And because this can swamp a box, I would highly recommend it gets fixed :-) thx -g -- Greg Stein, http://www.lyra.org/ --------------2F2A7A284F92DB72623DFFB Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from ns1.lyra.org (root@ns1.lyra.org [208.192.43.10]) by svpal.svpal.org (8.9.0/8.9.0) with ESMTP id RAA12486 for ; Fri, 8 Jan 1999 17:05:39 -0800 (PST) Received: (from root@localhost) by ns1.lyra.org (8.8.5/8.8.5) id RAA25542 for gstein@lyra.org; Fri, 8 Jan 1999 17:19:53 -0800 Date: Fri, 8 Jan 1999 17:19:53 -0800 From: Greg Stein Message-Id: <199901090119.RAA25542@ns1.lyra.org> To: gstein@lyra.org ( Subject: Mailman results for Hognews To: mailer-daemon@ns1.lyra.org **** Subject line ignored: Returned mail: ... User unknown >>>> This is a MIME-encapsulated message **** this: Command UNKNOWN. >>>> --RAB25528.915844738/ns1.lyra.org **** --rab25528.915844738/ns1.lyra.org: Command UNKNOWN. >>>> The original message was received at Fri, 8 Jan 1999 17:18:56 -0800 **** the: Command UNKNOWN. >>>> from localhost [127.0.0.1] **** from: Command UNKNOWN. >>>> ----- The following addresses had permanent fatal errors ----- **** -----: Command UNKNOWN. >>>> **** : Command UNKNOWN. >>>> ----- Transcript of session follows ----- **** -----: Command UNKNOWN. >>>> <<< RCPT TO: **** <<<: Command UNKNOWN. >>>> 550 ... User unknown **** 550: Command UNKNOWN. >>>> 421 ns1.lyra.org Lost input channel from localhost [127.0.0.1] **** 421: Command UNKNOWN. >>>> ns1.lyra.org Lost input channel from localhost [127.0.0.1] **** ns1.lyra.org: Command UNKNOWN. >>>> --RAB25528.915844738/ns1.lyra.org **** --rab25528.915844738/ns1.lyra.org: Command UNKNOWN. >>>> Content-Type: message/delivery-status **** content-type:: Command UNKNOWN. >>>> Reporting-MTA: dns; ns1.lyra.org **** reporting-mta:: Command UNKNOWN. >>>> Received-From-MTA: DNS; localhost **** received-from-mta:: Command UNKNOWN. >>>> Arrival-Date: Fri, 8 Jan 1999 17:18:56 -0800 **** arrival-date:: Command UNKNOWN. >>>> Final-Recipient: RFC822; ch9517@ns1.lyra.org **** final-recipient:: Command UNKNOWN. >>>> Action: failed **** action:: Command UNKNOWN. >>>> Status: 5.1.1 **** status:: Command UNKNOWN. >>>> Last-Attempt-Date: Fri, 8 Jan 1999 17:18:58 -0800 **** last-attempt-date:: Command UNKNOWN. >>>> --RAB25528.915844738/ns1.lyra.org-- **** --rab25528.915844738/ns1.lyra.org--: Command UNKNOWN. --------------2F2A7A284F92DB72623DFFB-- From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Jan 9 06:06:28 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sat, 9 Jan 1999 01:06:28 -0500 (EST) Subject: [Mailman-Developers] Mailman 1.0b7 bug reports References: <199901081146.MAA19567@mailhost.uni-koblenz.de> Message-ID: <13974.61924.456561.780766@anthem.cnri.reston.va.us> >>>>> "DD" == Detlev Droege writes: DD> We did set up Mailman at DD> http://mailhost.uni-koblenz.de/mailman/admin/ mostly to admin DD> local user groups. I'm the list-admin of the single non-local DD> group (EINST-Mitglieder). I see you're using 1.0b7, so I can't chalk your problems up to an old release ;-) DD> 1 - I did a bulk subscribe for approx. 100 members via the DD> HTML interface. I overlooked a bogus line when pasting DD> the addresses into the textfield and Mailman generated DD> a strange entry. A syntax check on the mail addresses DD> would be helpful. [The bogus address had a pending DD> closing paranthesis: "AUser@somewhere.com)" ] I've added more checks on the email address for the next release. You should not be able to subscribe any address that starts with a -, has any of []<>()|; in the address, or be unqualified (i.e. local; have no `@' in the string). DD> 2 - The abovementioned list of email addresses did contain DD> mixed-case entries like "Detlev.Droege@uni-koblenz.de". DD> Mailman did lowercase them in most places, but not in all DD> places. To be RFC compliant, Mailman case-preserves the username portion of the email address for sending email. Almost everywhere else, the email address should just be lower cased. You found one place that we missed. This will be fixed in the next release. DD> 3 - When the first external member submitted an article, its DD> From: address differed from the subscribed address, so I as DD> the list admin was asked to approve the message. I did so, DD> however the message was never sent out to the list members. DD> It appears in the "post" logfile, it is archived in the DD> HTML archive, but it was never mailed to the list members. DD> Our postmaster could not detect any failure of our mail DD> system nor any error messages. Is it possible Mailman DD> just forgot to send it out ? Sure, anything's possible, but I haven't been able to reproduce this problem. I set up a list that does not require admin approval, but does restrict postings to members. Then I sent a message with a non-member From: line, and went through approval Web page. The message got posted to the list. I'll need some help, or more information, to help debug this. DD> 4 - As list admin I'd like to have an interface to change DD> the mail address of list members. I allready got several DD> requests to do so. It's a little boring to do so by DD> unsubscribing the old and then subscribing the new address. DD> Moreover, this generates a useles "Good Bye" and "Welcome" DD> message which might confuse the subscriber. This is definitely on the list, but it requires some architectural changes to Mailman, so we're putting anything like this off for a while. One thing we though might not be too hard would be the ability to `clone' a user to a new address. You'd still have to remove the old address, but at least you wouldn't have to go and reset all their options. Still, I don't think we'll do this for 1.0, but perhaps for 1.1. DD> Anyway - Mailman is a great tool and I like it a lot ! DD> Don't take this as complaint, but as my (very) small effort DD> to make it even better. And we appreciate it! Hopefully we can get more information and figure out what's going on with #3 above. Thanks, -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Jan 9 06:29:49 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sat, 9 Jan 1999 01:29:49 -0500 (EST) Subject: [Mailman-Developers] is restricted unsubscribe possible? References: <19990108200819.H25894@mail.tolna.net> Message-ID: <13974.63325.280292.249197@anthem.cnri.reston.va.us> >>>>> "PG" == Peter Gervai writes: PG> I think I failed to see how can I make a list set up so that PG> its members cannot unsubscribe without owner's approval? (Or PG> does "approval for subscribe" setting cover unsub messages as PG> well?) Nope, can't currently be done. PG> I would like to use a list as our 'problem notification' PG> service but I don't want to see clueless idiots, erm, I mean, PG> windows users :) playing with subscriptions at all. It should PG> be act just like a 'glorified alias file' (but much easier to PG> handle). Would you also want the ability to not allow users to edit their options? Anyway, I've put both these suggestions on the TODO list. -Barry From markw98@ibm.net Sat Jan 9 18:33:31 1999 From: markw98@ibm.net (Mark Williamson) Date: Sat, 9 Jan 1999 10:33:31 -0800 Subject: [Mailman-Developers] New to Mailman, Question on Platforms Message-ID: <005801be3bfe$8f581900$aad9fea9@mark.pacbell.net> I've looked through the archives, but i couldn't find the answer to my question. I am not proficient at all on Linux/Unix systems, just a novice. The bulk of my experience has been on NT. That leads to my question: SInce Python has been ported to NT, can mailman run on this platform? Are there any FAQ's, docs or links that i can read on how to do this? Or is this undoable because of the need to compile some of the .C programs? Can the .C program's functionality be duplicated on NT or rewritten in Python? Regards, Mark Williamson From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Jan 9 19:10:04 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sat, 9 Jan 1999 14:10:04 -0500 (EST) Subject: [Mailman-Developers] New to Mailman, Question on Platforms References: <005801be3bfe$8f581900$aad9fea9@mark.pacbell.net> Message-ID: <13975.43404.933257.241961@anthem.cnri.reston.va.us> >>>>> "MW" == Mark Williamson writes: MW> That leads to my question: SInce Python has been ported to NT, MW> can mailman run on this platform? Are there any FAQ's, docs MW> or links that i can read on how to do this? Or is this MW> undoable because of the need to compile some of the .C MW> programs? Can the .C program's functionality be duplicated on MW> NT or rewritten in Python? At this point, I think it's mostly undoable because of our heavy reliance on a forking model. Win32 doesn't have fork(). We've talked about moving to a threaded long-running server model, or adopting Zope as a platform, and both of those (very future) developments would probably let us support NT. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Jan 9 19:24:41 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sat, 9 Jan 1999 14:24:41 -0500 (EST) Subject: [Mailman-Developers] shipstopper bug References: <3696BBF0.31971360@lyra.org> Message-ID: <13975.44281.396310.817435@anthem.cnri.reston.va.us> >>>>> "GS" == Greg Stein writes: GS> What happens is that somebody types in a request to the GS> Mailman subscription page with a *local* mail address (i.e. no GS> domain name). The confirmation email then gets sent. This GS> bounces back to Mailman, but it doesn't understand that it is GS> a bounce and tries to process the dumb thing. That fails GS> massively (as seen in the attached mail), and responds to GS> mailer-daemon with the error. More on this in a bit. GS> 3) should probably disallow domain-less addresses in all GS> places Greg, It should now (with 1.0b7+) be impossible to subscribe a domainless email address. I've verified this with the Membership Management interface, a normal user's use of the subscribe page, attempting to subscribe via email directly, and using bin/add_members. If this means that from now on, no one will encounter the problem, I'm tempted not to investigate further. My question to the developers is, how important do you think it is to fix this problem for the early adopters? You guys can `just' delete the unqualified addresses and force those people to re-subscribe using a now valid address. Would this be a huge burden? Of course, if anybody's seen this happen for qualified addresses, then obviously we need to debug it. -Barry From John@list.org Sat Jan 9 19:59:55 1999 From: John@list.org (John Viega) Date: Sat, 9 Jan 1999 11:59:55 -0800 Subject: [Mailman-Developers] New to Mailman, Question on Platforms In-Reply-To: <13975.43404.933257.241961@anthem.cnri.reston.va.us>; from Barry A. Warsaw on Sat, Jan 09, 1999 at 02:10:04PM -0500 References: <005801be3bfe$8f581900$aad9fea9@mark.pacbell.net> <13975.43404.933257.241961@anthem.cnri.reston.va.us> Message-ID: <19990109115955.B2647@viega.org> I mostly agree with Barry's answer, but for different reasons. You can use the cygwin stuff to get fork(), etc... under windows. There is no reasonable *free* mail transport for windows that I know of, but you could always pass that off to another machine, with some hacking. I don't know what web servers look like for windows. All in all, the pieces are probably all there, but there would be a lot of work involved in getting everything working. John On Sat, Jan 09, 1999 at 02:10:04PM -0500, Barry A. Warsaw wrote: > > >>>>> "MW" == Mark Williamson writes: > > At this point, I think it's mostly undoable because of our heavy > reliance on a forking model. Win32 doesn't have fork(). > > We've talked about moving to a threaded long-running server model, or > adopting Zope as a platform, and both of those (very > future) developments would probably let us support NT. > > -Barry > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Jan 9 19:48:18 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sat, 9 Jan 1999 14:48:18 -0500 (EST) Subject: [Mailman-Developers] Logo contest Message-ID: <13975.45698.360777.704107@anthem.cnri.reston.va.us> I would like to have a Mailman logo, that would serve a function similar to Just van Rossum's excellent "Python Powered" logo. I am not much of a (visual :-) artist so if I had to do it, I'd probably hack around with Gimp's logo scripts for an hour or so and come up with something really cheezy. So I figured I'd open up a logo contents with y'all to tap the fast energies and talents of our community. See http://www.python.org/psa/Logo.html for the logos that Just came up with for Python. Here are my requirements: - The phrase should be "Delivered by Mailman" - We should have a large logo and a small logo, of approximately the sizes Just chose, but I'm not as concerned about animated versions. - I'm thinking that the background should be a simple caricature of an envelope, either of the obverse side (with a stamp in the upper left corner), or the reverse side, with flap lines. This is just a suggestion. - Colors and fonts are up to you, but readability is of utmost importance. - GIF is probably the best format. - You will have to GPL your logo, and be willing to assign it to the FSF (and probably have your employer do the same). Send your submissions to me -- MIME is fine. I'll post them on the Web so we can all see and vote on them. The winner gets his or her little chunk of net.immortality and the eternal thanks of Mailman users for years to come. I would like to have a logo for the 1.0 release, which I think will realistically be end-of-January. Thanks, -Barry From markw98@ibm.net Sat Jan 9 21:57:30 1999 From: markw98@ibm.net (Mark Williamson) Date: Sat, 9 Jan 1999 13:57:30 -0800 Subject: [Mailman-Developers] New to Mailman, Question on Platforms Message-ID: <015901be3c1b$0ed6e320$aad9fea9@mark.pacbell.net> i.e. not worth the effort :) hehehe, always knew i'd put this redhat disk to use -----Original Message----- From: John Viega To: Barry A. Warsaw ; Mark Williamson Cc: mailman-developers@python.org Date: Saturday, January 09, 1999 11:47 AM Subject: Re: [Mailman-Developers] New to Mailman, Question on Platforms >I mostly agree with Barry's answer, but for different reasons. You >can use the cygwin stuff to get fork(), etc... under windows. There >is no reasonable *free* mail transport for windows that I know of, but >you could always pass that off to another machine, with some hacking. >I don't know what web servers look like for windows. All in all, the >pieces are probably all there, but there would be a lot of work >involved in getting everything working. > >John > > >On Sat, Jan 09, 1999 at 02:10:04PM -0500, Barry A. Warsaw wrote: >> >> >>>>> "MW" == Mark Williamson writes: >> >> At this point, I think it's mostly undoable because of our heavy >> reliance on a forking model. Win32 doesn't have fork(). >> >> We've talked about moving to a threaded long-running server model, or >> adopting Zope as a platform, and both of those (very >> future) developments would probably let us support NT. >> >> -Barry >> >> _______________________________________________ >> Mailman-Developers maillist - Mailman-Developers@python.org >> http://www.python.org/mailman/listinfo/mailman-developers > From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Jan 9 22:53:19 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sat, 9 Jan 1999 17:53:19 -0500 (EST) Subject: [Mailman-Developers] New to Mailman, Question on Platforms References: <005801be3bfe$8f581900$aad9fea9@mark.pacbell.net> <13975.43404.933257.241961@anthem.cnri.reston.va.us> <19990109115955.B2647@viega.org> Message-ID: <13975.56799.556929.398149@anthem.cnri.reston.va.us> >>>>> "JV" == John Viega writes: JV> I mostly agree with Barry's answer, but for different reasons. JV> You can use the cygwin stuff to get fork(), etc... under JV> windows. The problem is that there isn't a standard Python distribution built on top of cygwin. I don't know if anybody's tried to that either. -Barry From gorgo@caesar.elte.hu Sun Jan 10 01:41:38 1999 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Sun, 10 Jan 1999 02:41:38 +0100 (MET) Subject: [Mailman-Developers] error message from cron Message-ID: Hello, Since I upgraded to 1.0b7 I get a couple of these messages each day. Any ideas why ? Traceback (innermost last): File "/usr/lib/mailman/cron/run_queue", line 27, in ? OutgoingQueue.processQueue() File "/usr/lib/mailman/Mailman/OutgoingQueue.py", line 126, in processQueue Utils.TrySMTPDelivery(recip,sender,text,full_fname) File "/usr/lib/mailman/Mailman/Utils.py", line 217, in TrySMTPDelivery OutgoingQueue.dequeueMessage(queue_entry) File "/usr/lib/mailman/Mailman/OutgoingQueue.py", line 184, in dequeueMessage os.unlink(q_entry) os.error: (2, 'No such file or directory') Greg From grin@tolna.net Sun Jan 10 16:43:08 1999 From: grin@tolna.net (Peter Gervai) Date: Sun, 10 Jan 1999 17:43:08 +0100 Subject: [Mailman-Developers] colored columns in memberlist management table Message-ID: <19990110174308.C16780@mail.tolna.net> Would be quite easy to gray the background of even coloumns of the membership management table to make it easier to see which switch goes for what settings. And maybe the header at the end of the table wouldn't hurt as well. (My screen is maybe too small and the header gets scrolled off the screen when I go to the bottom of the memberlist.) bye, grin From julian7@kva.hu Mon Jan 11 08:41:32 1999 From: julian7@kva.hu (Balazs Nagy) Date: Mon, 11 Jan 1999 09:41:32 +0100 (CET) Subject: [Mailman-Developers] error message from cron In-Reply-To: Message-ID: On Sun, 10 Jan 1999, Gergely Madarasz wrote: > Hello, > > Since I upgraded to 1.0b7 I get a couple of these messages each day. Any > ideas why ? > > Traceback (innermost last): > File "/usr/lib/mailman/cron/run_queue", line 27, in ? > OutgoingQueue.processQueue() > File "/usr/lib/mailman/Mailman/OutgoingQueue.py", line 126, in processQueue > Utils.TrySMTPDelivery(recip,sender,text,full_fname) > File "/usr/lib/mailman/Mailman/Utils.py", line 217, in TrySMTPDelivery > OutgoingQueue.dequeueMessage(queue_entry) > File "/usr/lib/mailman/Mailman/OutgoingQueue.py", line 184, in dequeueMessage > os.unlink(q_entry) > os.error: (2, 'No such file or directory') Fast fix: --- OutgoingQueue.py.orig Mon Jan 11 09:40:30 1999 +++ OutgoingQueue.py Mon Jan 11 09:40:50 1999 @@ -176,4 +176,7 @@ # remove it from the queue # def dequeueMessage(q_entry): - os.unlink(q_entry) + try: + os.unlink(q_entry) + except: + pass -- Linux Supporting Center -- Red Hat Qmail packages -- http://lsc.kva.hu PGP 0x1DE3631D / A8 B4 92 EE 1F 55 27 C8 86 64 9C 42 41 A4 BD B8 Don't spell GLIB backwards! From klm@python.org Mon Jan 11 16:57:32 1999 From: klm@python.org (Ken Manheimer) Date: Mon, 11 Jan 1999 11:57:32 -0500 (EST) Subject: [Mailman-Developers] error message from cron In-Reply-To: Message-ID: On Mon, 11 Jan 1999, Balazs Nagy wrote: > On Sun, 10 Jan 1999, Gergely Madarasz wrote: > > [...] > > os.error: (2, 'No such file or directory') > > Fast fix: > > --- OutgoingQueue.py.orig Mon Jan 11 09:40:30 1999 > +++ OutgoingQueue.py Mon Jan 11 09:40:50 1999 > @@ -176,4 +176,7 @@ > # remove it from the queue > # > def dequeueMessage(q_entry): > - os.unlink(q_entry) > + try: > + os.unlink(q_entry) > + except: > + pass (Thanks for the suggestion! Due to some overriding other concerns i won't have time immediately to look at incorporating it - maybe one of the other central folks will - but i do have a fairly important coding practice to suggest for mailman submissions. Avoid using unqualified 'excepts' unless the exception case code does something specific with the results. Ie, prevent hiding unanticipated exceptions, just catch the ones you mean to catch. In this case, something like 'except os.error' instead of 'except'. And that's just for the fast fix - a real fix should take check that the os.error is "no such file...", and perhaps log something... We're urgently trying to eliminate anything that hides bugs, otherwise the system's operation becomes full of mysteries, and not approachable as an open source effort. (Hidden bugs are nuisances in *any* context.) Please don't take this as a criticism of your input - i'm just taking the opportunity to make this practice clear to everyone.) ken manheimer klm@python.org From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Tue Jan 12 20:26:54 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 12 Jan 1999 15:26:54 -0500 (EST) Subject: [Mailman-Developers] Re: [Mailman-Users] Wierd Mailman problem References: <369B7E1A.B3A5F822@blowtorch.com> Message-ID: <13979.45070.392127.454362@anthem.cnri.reston.va.us> >>>>> "GH" == George Hartz writes: GH> The web interface seems to work okay, although I don't get GH> anything in the archives. Should clicking on the archives link GH> work before any messages have been posted to the list? No, that's a buglet. The archive link is not functional until at least one message has been posted to the list. GH> Anyway the problem I seem to be having is that Mailman is GH> failing without any errors at all. User and group ID's seem to GH> be set correctly. The wrapper programs aren't logging any GH> errors for bad UID's. (And running the programs as an GH> incorrect user *does* log them, so I know the logging itself GH> works. I'm sure you know that if the error occurs because of a gid mismatch, in either the CGI wrapper or the mail wrapper, errors are only logged to syslog, not to $prefix/logs/error. For mail, you ought to also get a bounce containing the error message, and for CGI -- with the next version -- you will get a more useful Web diagnostic page. Once control has been passed to the Python world (e.g. the `driver' script for CGI, or `post' for mail), then errors get logged to Mailman's log files. Note that a misconfiguration of syslog or your mail system might mean that those pre-Python errors are getting lost. [This is probably more useful to mailman-developers] Once you're in the Python world, there are several ways to log error messages for debugging. My favorite is, once I have a MailList object, I like to call the LogMsg() method with kind=='debug', kind of like so: mlistobj.LogMsg('debug', 'I got to here: %s', 'foo method') This will timestamp the message, and write it to $prefix/errors/debug. -Barry From klm@python.org Tue Jan 12 21:02:14 1999 From: klm@python.org (Ken Manheimer) Date: Tue, 12 Jan 1999 16:02:14 -0500 (EST) Subject: [Mailman-Developers] mailman FAQ? Message-ID: <13979.46721.23513.829273@glyph.cnri.reston.va.us> I'm scrambling with a job change (possibly an exciting one for mailman, as well as for me), but have an idea i'd like to put out there, in the meanwhile. Barry, and harald, and others - thanks all! - have been answering some questions that are clearly coming up Frequently - seems like perfect fodder for the start of a mailman FAQ. Would anyone like to form such a thing? How about a mailman faq wizard, somewhere on list.org? Or maybe python.org? I won't have time to set it up - but it probably ought be... (The questions that i clearly see are setting of the mailman UID/GID, debugging it when it goes awry, and dealing with the archives stuff, particularly the slightly surprising fact that a public archive link is not created until the first posting, while the actual private-dir file already is there. While barry's recent checkin to make the UID/GID setting error message provide more info should go a long way to helping (and ought to be factored in to any explanation), it still may be worth answering OAFA - once and for all. Any other hidden items worth mentioning?) ken manheimer klm@python.org From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Tue Jan 12 21:09:07 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 12 Jan 1999 16:09:07 -0500 (EST) Subject: [Mailman-Developers] mailman FAQ? References: <13979.46721.23513.829273@glyph.cnri.reston.va.us> Message-ID: <13979.47603.491341.234786@anthem.cnri.reston.va.us> >>>>> "KM" == Ken Manheimer writes: KM> How about a mailman faq wizard, somewhere on list.org? Or KM> maybe python.org? I won't have time to set it up - but it KM> probably ought be... The distrib now has a FAQ file (renamed from PROBLEMS which no one seemed to read :-). A faqwiz on python.org or list.org is definitely something I'd like to set up, when I get some time. -Barry From gstein@lyra.org Wed Jan 13 12:12:00 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 13 Jan 1999 04:12:00 -0800 Subject: [Mailman-Developers] Re: Digests and Cron and Signals References: <3696B9BC.19691E55@lyra.org> Message-ID: <369C8D90.22C53D8@lyra.org> Harald's signal patch worked on my system. No more annoying reports from Cron about "No such process". Thanx, Harald! For my particular test, I added the two lines to cron/senddigests. I would recommend that the next Mailman release include the two lines in each of cron/*. thx, -g Greg Stein wrote: > > [ responding from the archive, so this message will be formatted > funny... ] > > ----INCLUDED MESSAGE---- > I have upgraded mailman to the new release, 1.0b7, on my redhat 5 > system. > > $ uname -a > Linux jerrya 2.0.32 #4 Wed Jan 7 23:14:32 CST 1998 i486 unknown > > I still receive the following message every day when the digests go out. > They are going out successfully, but this message still gets delivered. > > [snip of Cron Daemon traceback...] > ----INCLUDED MESSAGE---- > > Actually, if you run MULTIPLE lists, then your mail is NOT being > delivered. The traceback will occur on the FIRST mail list, preventing > the rest from being delivered. > > I run into this EVERY day with mine and I patched my installation to > ignore the error so that digests can go out for all lists. > > I put in a hack, though, to ignore it (similar to Barry's). I'm going to > try Harald's signal patch (cool!) and report back on its success. If I > stop getting my noon cron reports of failure, then we'll be golden. > > Note: mine is occuring on a RedHat 5.1 system. > > -g > > -- > Greg Stein, http://www.lyra.org/ -- Greg Stein, http://www.lyra.org/ From andy@nachoz.com Wed Jan 13 15:20:30 1999 From: andy@nachoz.com (Andy Harrison) Date: Wed, 13 Jan 1999 10:20:30 -0500 (EST) Subject: [Mailman-Developers] Re: [Mailman-Users] Wierd Mailman problem In-Reply-To: <13979.45070.392127.454362@anthem.cnri.reston.va.us> Message-ID: On 12-Jan-99 Barry A. Warsaw wrote: > >>>>>> "GH" == George Hartz writes: > > GH> The web interface seems to work okay, although I don't get > GH> anything in the archives. Should clicking on the archives link > GH> work before any messages have been posted to the list? > > No, that's a buglet. The archive link is not functional until at > least one message has been posted to the list. > What if messages have been posted to the list but the archiving still isn't working? --------------------------------- E-Mail: Andy Harrison Date: 13-Jan-99 Time: 10:15:31 This message was sent by XFMail --------------------------------- From gstein@lyra.org Wed Jan 13 17:18:48 1999 From: gstein@lyra.org (Greg Stein) Date: Wed, 13 Jan 1999 09:18:48 -0800 Subject: [Mailman-Developers] BUG: virtual hosting (was Re: [Mailman-Users] Bug in b7?) References: Message-ID: <369CD578.3E955457@lyra.org> Ken Manheimer wrote: > On Wed, 13 Jan 1999, Greg Stein wrote: > ... > > Could this be due to the "per-virtual host" list option? I don't recall > > exactly how/where you set that, but I've got it set on my mailman > > installation. Lists will only appear if the hostname in the URL matches > > the hostname listed in the configuration for the "URL root" or whatever it > > is called. > > Correct - jason, you might try adding the line: > > VIRTUAL_HOST_OVERVIEW = 0 > > to the end of Mailman/mm_cfg.py. > > By inhibiting VIRTUAL_HOST_OVERVIEW you set the overview pages to show > all the advertised hosts, not just the hosts which have a "preferred" > host name that's the same as the one by which people are getting to the > overview page. If it works, then you may want to check the setting for > DEFAULT_HOST_NAME, also in mm_cfg.py (or Defaults.py in the same dir, if > it was never overridden). You can also specify the preferred host name > on a per-list basis - it's one of the the options at the bottom of the > admin 'general options' page. Speaking of virtual hosts... BUG REPORT: When the automated, monthly reminder goes out, the text uses a host name that might not apply to all the mailing lists in the combined reminder(!). I got a number of emails on January 1 when people received their mailing list reminder for harleydavidson.com (I run a mailing list for that domain). People couldn't quite see how the Python2C Announcement list should be hosted on harleydavidson.com :-) The combined report is cool and all :-), but I would recommend that it only combines reports for lists on the same virtual host! thx -g -- Greg Stein, http://www.lyra.org/ From klm@python.org Wed Jan 13 19:08:55 1999 From: klm@python.org (Ken Manheimer) Date: Wed, 13 Jan 1999 14:08:55 -0500 (EST) Subject: [Mailman-Developers] BUG: virtual hosting (was Re: [Mailman-Users] Bug in b7?) In-Reply-To: <369CD578.3E955457@lyra.org> Message-ID: On Wed, 13 Jan 1999, Greg Stein wrote: > Speaking of virtual hosts... > > BUG REPORT: > > When the automated, monthly reminder goes out, the text uses a host name > that might not apply to all the mailing lists in the combined > reminder(!). > > I got a number of emails on January 1 when people received their mailing > list reminder for harleydavidson.com (I run a mailing list for that > domain). People couldn't quite see how the Python2C Announcement list > should be hosted on harleydavidson.com :-) Yikes! But with an amusing touch of irony, i must say:-) > The combined report is cool and all :-), but I would recommend that it > only combines reports for lists on the same virtual host! Good point. It should not be hard. All the relevant logic is in ~mailman/cron/mailpasswds. The fragment that does the grouping needs to be more discerning about how it groups, factoring in virtual host, and then the messages need to be sent out as if from mailman-admin on that virtual host. (Hmm - that's a bit of a problem, because currently mailman doesn't distinguish a number of owners. It can be kludged for now in mailpasswd, but a functional interface should be created to provide an owner address distinguished by host.) If anyone want to look at it, please do so - but realize that changes to mailpasswds requires good testing, because it only happens periodically, and causes a lot of traffic, quite a nuisance if it goes awry. I usually test with a version where the actual sends are inhibited, producing output to identify that it's doing what i want, before committing anything. If no one gets to it, i should before the end of the year. (Kidding - but i really do not know when i will next be able to change anything in mailman and have adquate time for testing the changes - no point in hacking if i can't be confident it works!) Ken From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Jan 15 02:46:05 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 14 Jan 1999 21:46:05 -0500 (EST) Subject: [Mailman-Developers] Re: [Mailman-Users] Wierd Mailman problem References: <13979.45070.392127.454362@anthem.cnri.reston.va.us> Message-ID: <13982.44013.659040.374536@anthem.cnri.reston.va.us> >>>>> "AH" == Andy Harrison writes: AH> What if messages have been posted to the list but the AH> archiving still isn't working? Even if you toggle to private archiving, that doesn't work either? What does the listing of the archives directory look like? -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Jan 15 04:40:18 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 14 Jan 1999 23:40:18 -0500 (EST) Subject: [Mailman-Developers] [ANNOUNCE] Mailman 1.0b8 Message-ID: <13982.50866.34365.722114@anthem.cnri.reston.va.us> While there are still a few outstanding problems reported by users, I think we've nailed enough bugs since 1.0b7 to warrant a new release, so I'm announcing 1.0b8 tonight. As usual, feel free to pick it up from www.list.org. I think we're getting really close. I'm hoping my last minute changes didn't bust anything, and I'm also hoping we can nail down the last few showstoppers people have reported (in particular the archiving problems). I also want to get Scott's envelope-sender change backed out. Please give 1.0b8 a shot and let us know if you have any problems. Feel free to continue to send ideas and suggestions. I'm in conservative mode now though -- let's get 1.0 out so we can start working on some of those cool ideas. Thanks, -Barry From julian7@kva.hu Fri Jan 15 14:10:05 1999 From: julian7@kva.hu (Balazs Nagy) Date: Fri, 15 Jan 1999 15:10:05 +0100 (CET) Subject: [Mailman-Developers] My new patches Message-ID: Hiyas, I have fixed some bugs in my MTA package and fitted to the latest CVS snapshot. You can download'em from http://www.kva.hu/~mailman/mailman-patches-19910115.tar.bz2 or http://www.kva.hu/~mailman/mailman-patches-19910115.tgz These patches apply 1 - a little code fix for the 'set' email command 2 - CGI extension handling 3 - Usage of Message Transfer Unit (sendmail and others) instead of SMTP (but uses SMTP if MTU sending doesn't work) Download it, apply it, use it, collect it! Send bugs to me, success stories to the list. Regards: Balazs -- #!/bin/perl -sp0777i I wrote two patches: -sendcommand: it creates two new command. The 'filelist' command sends the list of documents located in the $listdir/documents directory (filenames beginning with a '.' aren't included). The 'send filename' command sends a document to the user via email. This is only a quick code, because I needed it, please comment (I used the another parts of the code, because I'm not perfect in python...) (patch-sendcommand) -hungarian patch: perhaps this is useful for hungarian users. It includes the hungarian version of most of the files in the templates/ directory, and the hungarian version of the e-mail-messages (confirmation, welcome, request etc.) (patch-mailmanhu-1.0b8) Location: ftp://ftp.kma.bme.hu/pub/bence/mailman Regards: Bence From julian7@kva.hu Mon Jan 18 13:26:15 1999 From: julian7@kva.hu (Balazs Nagy) Date: Mon, 18 Jan 1999 14:26:15 +0100 (CET) Subject: [Mailman-Developers] Two patches In-Reply-To: Message-ID: On Mon, 18 Jan 1999, Hermann Benedek wrote: > I wrote two patches: > > -sendcommand: it creates two new command. The 'filelist' command sends the > list of documents located in the $listdir/documents directory (filenames > beginning with a '.' aren't included). The 'send filename' command sends a > document to the user via email. This is only a quick code, because I needed > it, please comment (I used the another parts of the code, because I'm not > perfect in python...) > (patch-sendcommand) I think we want to define a method how to handle - admin requests - document services via email. I wrote a similar patch to handle admin requests, but I'll wait until the stable release. > -hungarian patch: perhaps this is useful for hungarian users. It includes > the hungarian version of most of the files in the templates/ directory, and > the hungarian version of the e-mail-messages (confirmation, welcome, request > etc.) > (patch-mailmanhu-1.0b8) This is great because nowadays internationalization (i18n) is a great effort in every package. BUT... Did you try to enter an accented string to a WWW admin page? For example 'általános' (== general in Hungarian). It will say '\341ltal\341nos' next time. If you press a simple OK, you'll see '\\341ltal\\341nos' next time. This is due to string parsing in Python and I don't know how to handle it. Regards: Jul (aka Balazs) -- #!/bin/perl -sp0777i Hiyas, Three days ago I downloaded the latest CVS snapshot and I applied my patches to it. Now my users reported that their letters didn't posted to the list. I found that there's an error in MailList.py (I think). These fast fixes comes from experience and not from evidence :-> --- MailList.py.orig Mon Jan 11 09:33:44 1999 +++ MailList.py Mon Jan 18 15:33:35 1999 @@ -1140,7 +1140,7 @@ members = self.GetDeliveryMembers() if dont_send_to_sender: try: - recipients.remove(members) + recips.remove(members) # # sender not in list (case sensitive username problem?) # @@ -1149,14 +1149,14 @@ "couldn't remove %s from recipient list: %s", sender, str(members)) - recipients = [] + recips = [] for m in members: if not self.GetUserOption(m, mm_cfg.DisableDelivery): - recipients.append(m) + recips.append(m) self.LogMsg("post", "post to %s from %s size=%d", self._internal_name, msg.GetSender(), len(msg.body)) - self.DeliverToList(msg, recipients, + self.DeliverToList(msg, recips, header = self.msg_header % self.__dict__, footer = self.msg_footer % self.__dict__) if ack_post: -- #!/bin/perl -sp0777i >BUT... Did you try to enter an accented string to a WWW admin page? For >example '=E1ltal=E1nos' (=3D=3D general in Hungarian). It will say >'\341ltal\341nos' next time. If you press a simple OK, you'll see >'\\341ltal\\341nos' next time. This is due to string parsing in Python and I used only english characters (non-accented) in the email-messages. Not too good, but works with all system. I tried to write a 'MIME' line to the header, but I don't know how to do it in the MailCommandhandler.py. Is there a function that writes a string to the header, and can be used from MailCommandhandler? Web-admin page: I have the problem too. It works good until you change the page next time. Regards, Bence From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Tue Jan 19 05:15:59 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 19 Jan 1999 00:15:59 -0500 (EST) Subject: [Mailman-Developers] Mailman logo submission Message-ID: <13988.5391.688604.511812@anthem.cnri.reston.va.us> Hi folks, we have our first Mailman logo submission! Heidi Henderson has contributed a very cool logo -- see www.list.org for the large and small version. -Barry From tomas@euronetics.se Wed Jan 20 18:58:39 1999 From: tomas@euronetics.se (Tomas Fasth) Date: Wed, 20 Jan 1999 19:58:39 +0100 Subject: [Mailman-Developers] Mailman archive and MIME Message-ID: <00a301be44a6$e70c3770$f6d52dc1@bishop.twinspot.net> This is a multi-part message in MIME format. ------=_NextPart_000_00A0_01BE44AF.45E23210 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi. Are there anyone on this list currently working on a MIME fix for = mailman pipermail archiving? It currently (1.0b8) lack even the simplest = MIME support, as far as I understand. If you browse a pipermail archive = any MIME composed messages appears right out ugly and sometimes = unreadable (a matter of skill of course). There are at least two angles on this. One is that when MIME encoding = (quoted-printable,base64) has been applied it looks messy in raw format. = The other is that some mailers (outlook express...) can be configured to = send multipart/alternative with message in both HTML and plain text = versions. Looks even more messy in raw format. I know you guys are working hard to get a stable release of 1.0 out on = the streets. But before that happens I highly recommend to have this = particular issue addressed somehow. My point is: making a stable release = of a email/web based software in the year of 1999 without basic support = for MIME is a big shame. Hopefully, I am plain wrong about the whole = issue. May be I have missed the obvious. Of course, it is my hope that someone already have a solution on the = problem, or working on one. If not, as a last resort, I may volunteer but not before a few weeks = from now. Comments, any? Tomas ------=_NextPart_000_00A0_01BE44AF.45E23210 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi.
Are there = anyone on this=20 list currently working on a MIME fix for mailman pipermail archiving?=20 It currently (1.0b8) lack = even the=20 simplest MIME support, as far as I understand. If you browse a pipermail = archive any MIME=20 composed messages appears right out ugly and sometimes unreadable (a = matter of=20 skill of course).
There are at=20 least two angles on this. One is that when MIME encoding=20 (quoted-printable,base64) has been applied it looks messy in raw format. = The=20 other is that some mailers (outlook express...) can be configured to = send=20 multipart/alternative with message in both HTML and plain text versions. = Looks=20 even more messy in raw format.
I know you guys are working hard to get a stable release of 1.0 out = on the=20 streets. But before that happens I = highly=20 recommend to have this particular issue addressed somehow. My point is: making a stable release of a email/web based = software in the=20 year of 1999 without basic support for MIME is a big shame. Hopefully, I am plain wrong about the whole issue. May be I = have missed=20 the obvious.
Of course, it is my hope that someone already have a = solution=20 on the problem, or working on one.
If not, as a last resort, I may volunteer but not = before a few=20 weeks from now.
 
Comments, any?
 
Tomas
 
------=_NextPart_000_00A0_01BE44AF.45E23210-- From julian7@kva.hu Thu Jan 21 07:13:23 1999 From: julian7@kva.hu (Balazs Nagy) Date: Thu, 21 Jan 1999 08:13:23 +0100 (CET) Subject: [Mailman-Developers] Mailman archive and MIME In-Reply-To: <00a301be44a6$e70c3770$f6d52dc1@bishop.twinspot.net> Message-ID: On Wed, 20 Jan 1999, Tomas Fasth wrote: > Hi. > Are there anyone on this list currently working on a MIME fix for mailman > pipermail archiving? It currently (1.0b8) lack even the simplest MIME > support, as far as I understand. If you browse a pipermail archive any Not just the pipermail archiving lacks any mail support but admindb too. Just check out any admindb warning. Can you see any email addresses in <>s? The most important thing to replace < > and & characters, outside of any MIME encoded things. > MIME composed messages appears right out ugly and sometimes unreadable (a > matter of skill of course). > There are at least two angles on this. One is that when MIME encoding > (quoted-printable,base64) has been applied it looks messy in raw format. > The other is that some mailers (outlook express...) can be configured to > send multipart/alternative with message in both HTML and plain text > versions. Looks even more messy in raw format. Well, if someone sent me (or to my lists) any HTML + embedded crap, I warn him/her for the first time... > I know you guys are working hard to get a stable release of 1.0 out on the > streets. But before that happens I highly recommend to have this > particular issue addressed somehow. My point is: making a stable release > of a email/web based software in the year of 1999 without basic support > for MIME is a big shame. Hopefully, I am plain wrong about the whole > issue. May be I have missed the obvious. Agreed. > Of course, it is my hope that someone already have a solution on the > problem, or working on one. I saw something in the core Python and it could be easy to write a MIME converter but I have to do my state exam next week thus I can't work on the problem right now. Regards: Balazs -- #!/bin/perl -sp0777i Message-ID: [Balazs Nagy] > On Wed, 20 Jan 1999, Tomas Fasth wrote: > > > Hi. > > > Are there anyone on this list currently working on a MIME fix for mailman > > pipermail archiving? It currently (1.0b8) lack even the simplest MIME > > support, as far as I understand. If you browse a pipermail archive any > > Not just the pipermail archiving lacks any mail support but admindb > too. I think that's a separate issue -- you're talking about quoting special HTML characters. Which, of course, should be done -- but it hasn't got anything to do with MIME. > > MIME composed messages appears right out ugly and sometimes unreadable (a > > matter of skill of course). I haven't tried this, but wouldn't simply squeezing the mail text through the .unmimify() method of the `mimify' standard Python module before formatting it into HTML work (for the QP/base64 MIME issue, multipart messages is a whole other can of worms)? Is there a problem with what headers are retained in the mbox-format version of the archive (i.e. are the headers needed for proper MIME decoding stripped from the archive)? -- Harald From tomas@euronetics.se Thu Jan 21 16:37:28 1999 From: tomas@euronetics.se (Tomas Fasth) Date: Thu, 21 Jan 1999 17:37:28 +0100 Subject: [Mailman-Developers] Mailman archive and MIME Message-ID: <019001be455c$5598d620$f6d52dc1@bishop.twinspot.net> From: Harald Meland Date: den 21 januari 1999 13:16 >I haven't tried this, but wouldn't simply squeezing the mail text >through the .unmimify() method of the `mimify' standard Python module >before formatting it into HTML work (for the QP/base64 MIME issue, >multipart messages is a whole other can of worms)? That's probably one way to go. A good thing trying to use existing code. I'm not sure what exactly .unmimify() does, though. The minimum requirements for messages written in western european languages would be for the archiver's email-to-html conversion to honor the MIME header encoding (RFC 2047) and the basics of MIME body format (RFC 2045). >Is there a problem with what headers are retained in the mbox-format >version of the archive (i.e. are the headers needed for proper MIME >decoding stripped from the archive)? Not as far as I can see. Both Content-* and MIME-Version headers seem to be retained. The problem occurs when the static html pages are generated. Tomas From Harald.Meland@usit.uio.no Thu Jan 21 23:55:17 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 22 Jan 1999 00:55:17 +0100 Subject: [Mailman-Developers] Mailman archive and MIME In-Reply-To: Tomas Fasth's message of "Thu, 21 Jan 1999 17:37:28 +0100" References: <019001be455c$5598d620$f6d52dc1@bishop.twinspot.net> Message-ID: [Tomas Fasth] > From: Harald Meland > > >I haven't tried this, but wouldn't simply squeezing the mail text > >through the .unmimify() method of the `mimify' standard Python module > >before formatting it into HTML work (for the QP/base64 MIME issue, > >multipart messages is a whole other can of worms)? In the general case it wouldn't, unless there also was some kind of 8bit-character-set -> HTML representation thingy, i.e. something to convert the ISO-8859-1 character "å" into the HTML element "å". Unless there is some standard Python module for doing this, I opt for leaving it all out until after 1.0 is out -- we might as well do this Right from the start. > That's probably one way to go. A good thing trying to use existing code. I'm > not sure what exactly .unmimify() does, though. It converts quoted-printable (and optionally base64) encoded parts to 8bit parts. I does not format it as HTML, though. It also does nothing with regard to "Content-Type:"-type things. > The minimum requirements for messages written in western european > languages would be for the archiver's email-to-html conversion to > honor the MIME header encoding (RFC 2047) and the basics of MIME > body format (RFC 2045). Do include all of RFC2045 when you say "the basics of MIME body format"? I really can't see the benefit of e.g. parsing multipart/alternative messages and such when formatting them as HTML. > >Is there a problem with what headers are retained in the mbox-format > >version of the archive (i.e. are the headers needed for proper MIME > >decoding stripped from the archive)? > > Not as far as I can see. Both Content-* and MIME-Version headers > seem to be retained. Duh, just me looking in the wrong place -- indeed, the listname.mbox/listname.mbox archive does include all headers. BTW, is there any way of configuring which headers (if any) should be removed when generating the static downloadable text files? -- Harald From tomas@euronetics.se Fri Jan 22 19:54:04 1999 From: tomas@euronetics.se (Tomas Fasth) Date: Fri, 22 Jan 1999 20:54:04 +0100 Subject: [Mailman-Developers] Mailman archive and MIME Message-ID: <002c01be4640$f6c1a650$f6d52dc1@bishop.twinspot.net> From: Harald Meland Date: den 22 januari 1999 01:02 Subject: Re: [Mailman-Developers] Mailman archive and MIME >Unless there is some standard Python module for doing this, I opt for >leaving it all out until after 1.0 is out -- we might as well do this >Right from the start. Have a look at http://www.oac.uci.edu/indiv/ehood/mhonarc.html It's written in Perl but even so a good piece of software when it comes to graceful handling of MIME messages. >Do include all of RFC2045 when you say "the basics of MIME body >format"? I really can't see the benefit of e.g. parsing >multipart/alternative messages and such when formatting them as HTML. Again, take a look at http://www.oac.uci.edu/indiv/ehood/mhamimeeg/complex.html for an example on how it could be handled gracefully. The example is way to it's extreme but still... Tomas From janne@avocado.pc.helsinki.fi Sat Jan 23 10:15:53 1999 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 23 Jan 1999 12:15:53 +0200 Subject: [Mailman-Developers] An upgrading experience Message-ID: I just upgraded from 1.0b4 to the latest b8 (CVS snapshot). It went mostly fine. Some problems though: - Python 1.5 doesn't have smtplib.py. Python 1.5.1 does. The documentation claims that 1.5 is good enough. - When I try to edit HTML through the WWW interface, I get an attribute error about Error.MMBadPassword (or some such). Is this a bug, or are my mailing list objects too old? - in update.log mailman says templates seem like pre-b4. Do I need to upgrade them manually, or does it just meant the templates were in wrong directories? - I had some archives, but after running 'make update' a few times, they are gone. Instead I have symlinks (list, list.mbox - yes both are symlinks) in the archives directory pointing to public_html/archives/*. But public_html/archives does not exist. Further, apparently new messages do not get archived now, at least I can't find them anywhere. Should the mailboxes reside in the $prefix/archives directory? Just out of curiosity, I tried to run the $prefix/cron/archive script manually (writing "python archive 1"). The current crontab does not seem to call it. It complains: Traceback (innermost last): File "archive", line 55, in ? if level <= list.archive_update_frequency: AttributeError: archive_update_frequency Does just loading and saving all the mailing lists help, or should I set archive_update_frequency manually? -- Janne From janne@avocado.pc.helsinki.fi Sat Jan 23 15:08:41 1999 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 23 Jan 1999 17:08:41 +0200 Subject: [Mailman-Developers] An upgrading experience In-Reply-To: Janne Sinkkonen's message of "23 Jan 1999 12:15:53 +0200" References: Message-ID: Some clarifications to my earlier blurb: > - I had some archives, but after running 'make update' a few times, > they are gone. Instead I have symlinks (list, list.mbox - yes both are > symlinks) in the archives directory pointing to > public_html/archives/*. But public_html/archives does not > exist. This was partly incorrect and I did find the archives from $prefix/archives/private. > Further, apparently new messages do not get archived now, at least I > can't find them anywhere. Should the mailboxes reside in the > $prefix/archives directory? Actually they do get archived, no problem here. It seems that I should have mailed to the mailman-users list first or checked things more carefully. Sorry... -- Janne From ken@digicool.com Sat Jan 23 17:59:12 1999 From: ken@digicool.com (Ken Manheimer) Date: Sat, 23 Jan 1999 12:59:12 -0500 (EST) Subject: [Mailman-Developers] commercial maillist system, lyris, looks rather similar Message-ID: I just heard mention of a commercial mailling list manager, lyris, that upon a tiny bit of investigation looks similar in some ways to mailman - eg, the admin interface layout: http://www.lyris.com/demo/list/listinfo.html (listinfo?), the orientation on web interfaces, "automatic error handling" (bounce handling), built-in archives, built-in mail engine (for "blinding speed"), etc. From poking around a little, it looks like they use perl at least as an extension language - i wonder how it's built. I'm pretty curious how long it's been around - they claim that: "Lyris was the first email list server to offer a web interface for list administrators and members." so i wonder if it predates the mailman betas. (I also noticed the phrase No more "get me off this list!" messages. on the lyris "about" page (http://www.lyris.com/about.html), , framed as "failsafe unsubscribing" - i think i saw this phrase in a recent mailman-users posting, i would not be surprised if the poster saw it there...) It has some nice stuff that mailman doesn't - one interesting idea seems to be to use a news server for the archives. That way, archive browsers can use a news interface, or use a web browser to a news/web gateway. (They probably do not do exactly this - the mail interface is a separate product, "multi view", so i'm probably missing something...) Wish i had more time to investigate, if anyone does, please report back... Ken Manheimer klm@digicool.com From tomas@euronetics.se Sun Jan 24 11:49:28 1999 From: tomas@euronetics.se (Tomas Fasth) Date: Sun, 24 Jan 1999 12:49:28 +0100 Subject: [Mailman-Developers] Archiving using news gateway References: Message-ID: <36AB08C8.93359F4@euronetics.se> In "Re: [Mailman-Developers] commercial maillist system, lyris, looks rather similar" Ken Manheimer wrote: > It has some nice stuff that mailman doesn't - one interesting idea seems > to be to use a news server for the archives. That way, archive browsers > can use a news interface, or use a web browser to a news/web gateway. Interesting approach. That is surely a possible workaround for the current lack of MIME support in pipermail archiving. As a matter of fact, I like the idea so much that I will give it a try. Why didn't I thought of that before ;-) Now, if I only could remember where I last saw that nice (MIME aware) web frontend for reading (mail and) news... On the other hand, most people today already have the necessary software (part from a browser) for reading both mail and news. So I guess the archive-through-news approach will work in most cases. Comments? Tomas From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sun Jan 24 19:40:34 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sun, 24 Jan 1999 14:40:34 -0500 (EST) Subject: [Mailman-Developers] Posting bug References: Message-ID: <13995.30514.407214.934422@anthem.cnri.reston.va.us> >>>>> "BN" == Balazs Nagy writes: BN> Three days ago I downloaded the latest CVS snapshot and I BN> applied my patches to it. Now my users reported that their BN> letters didn't posted to the list. BN> I found that there's an error in MailList.py (I think). These BN> fast fixes comes from experience and not from evidence :-> I just noticed this one myself today! Here's a better patch, IMO. -Barry -------------------- snip snip -------------------- Index: MailList.py =================================================================== RCS file: /projects/cvsroot/mailman/Mailman/MailList.py,v retrieving revision 1.109 diff -c -r1.109 MailList.py *** MailList.py 1999/01/13 23:55:23 1.109 --- MailList.py 1999/01/24 19:30:29 *************** *** 1138,1146 **** ack_post = 1 # Deliver the mail. members = self.GetDeliveryMembers() if dont_send_to_sender: try: ! recipients.remove(members) # # sender not in list (case sensitive username problem?) # --- 1138,1150 ---- ack_post = 1 # Deliver the mail. members = self.GetDeliveryMembers() + recipients = [] + for m in members: + if not self.GetUserOption(m, mm_cfg.DisableDelivery): + recipients.append(m) if dont_send_to_sender: try: ! recipients.remove(sender) # # sender not in list (case sensitive username problem?) # *************** *** 1149,1158 **** "couldn't remove %s from recipient list: %s", sender, str(members)) - recipients = [] - for m in members: - if not self.GetUserOption(m, mm_cfg.DisableDelivery): - recipients.append(m) self.LogMsg("post", "post to %s from %s size=%d", self._internal_name, msg.GetSender(), len(msg.body)) --- 1153,1158 ---- From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sun Jan 24 20:06:35 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sun, 24 Jan 1999 15:06:35 -0500 (EST) Subject: [Mailman-Developers] Mailman archive and MIME References: <00a301be44a6$e70c3770$f6d52dc1@bishop.twinspot.net> Message-ID: <13995.32075.566466.108157@anthem.cnri.reston.va.us> Just a quick note on this thread. I'd love it if Pipermail could handle MIME, but I gather that Andrew isn't very interested in working on Pipermail anymore. Unfortunately I probably do not have the time to hack on this either. But if someone else wants to contribute some patches, I'd be very happy to install them. It would be a Good Thing if the bundled archiver could handle this. An alternative is to make sure that Mailman can work with external archivers like MHonArc. This might be an easier way to go, leverages off of someone else's maintained code, and since MHonArc is GPL'd we could use it with no problems. Still, I doubt we'll ever bundle such archivers with Mailman. Finally, yes there are places where non-quoted HTML special characters are leaking through, and these do need to be fixed. -Barry From tomas@euronetics.se Sun Jan 24 21:38:50 1999 From: tomas@euronetics.se (Tomas Fasth) Date: Sun, 24 Jan 1999 22:38:50 +0100 Subject: [Mailman-Developers] Mailman archive and MIME References: <00a301be44a6$e70c3770$f6d52dc1@bishop.twinspot.net> <13995.32075.566466.108157@anthem.cnri.reston.va.us> Message-ID: <36AB92EA.9182FABD@euronetics.se> "Barry A. Warsaw" wrote: > I'd love it if Pipermail could handle MIME, but I gather that Andrew > isn't very interested in working on Pipermail anymore. Unfortunately > I probably do not have the time to hack on this either. But if > someone else wants to contribute some patches, I'd be very happy to > install them. It would be a Good Thing if the bundled archiver could > handle this. We are about to drop pipermail for now at our site (situated in Sweden). We will use either MHonArc or news gating or both. That will satisfy our need of accessing archives with correct handling of national characters as well as attachments. > An alternative is to make sure that Mailman can work with external > archivers like MHonArc. This might be an easier way to go, leverages > off of someone else's maintained code, and since MHonArc is GPL'd we > could use it with no problems. Still, I doubt we'll ever bundle such > archivers with Mailman. Having an archiver written in Perl bundled with an otherwise superb software (mainly) written in Python seem kind of weird to me. Anyway, Pipermail will surely do for the MIME-allergic community for the time being. Tomas From bwarsaw@python.org Mon Jan 25 04:21:56 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Sun, 24 Jan 1999 23:21:56 -0500 (EST) Subject: [Mailman-Developers] Mailman archive and MIME References: <00a301be44a6$e70c3770$f6d52dc1@bishop.twinspot.net> <13995.32075.566466.108157@anthem.cnri.reston.va.us> <36AB92EA.9182FABD@euronetics.se> Message-ID: <13995.61796.29935.601693@anthem.cnri.reston.va.us> >>>>> "TF" == Tomas Fasth writes: TF> We are about to drop pipermail for now at our site (situated TF> in Sweden). We will use either MHonArc or news gating or TF> both. That will satisfy our need of accessing archives with TF> correct handling of national characters as well as TF> attachments. Please tell us how it goes, and send us any patches that are necessary to interface Mailman with either solution. TF> Having an archiver written in Perl bundled with an otherwise TF> superb software (mainly) written in Python seem kind of weird TF> to me. Indeed! -Barry From akuchlin@cnri.reston.va.us Mon Jan 25 14:56:38 1999 From: akuchlin@cnri.reston.va.us (Andrew M. Kuchling) Date: Mon, 25 Jan 1999 09:56:38 -0500 (EST) Subject: [Mailman-Developers] Mailman archive and MIME In-Reply-To: <13995.32075.566466.108157@anthem.cnri.reston.va.us> References: <00a301be44a6$e70c3770$f6d52dc1@bishop.twinspot.net> <13995.32075.566466.108157@anthem.cnri.reston.va.us> Message-ID: <13996.33269.321434.225937@amarok.cnri.reston.va.us> Barry A. Warsaw writes: >I'd love it if Pipermail could handle MIME, but I gather that Andrew >isn't very interested in working on Pipermail anymore. Unfortunately >I probably do not have the time to hack on this either. But if The original motivation for writing Pipermail was because Hypermail was unmaintained at the time; it hadn't been updated since 1995. Things have changed now; a group of people has taken over Hypermail maintenance (http://www.landfield.com/hypermail/), there are various other programs such as MHonArc around, and e-mail archives are getting much fancier (look at egroups.com for an example). The other archivers are advancing faster on features because I don't really have time to hack on Mailman; for example, I think the current Hypermail version handles MIME-encoded messages. In short, I think the way of the future is to keep the existing Pipermail archive for the 70% of users with relatively simple needs, and provide a way to hook into arbitrary archivers for those users who need something more powerful. -- A.M. Kuchling http://starship.skyport.net/crew/amk/ "I thought you could foretell the future?" "I don't need to know the future. When the future's over, then it's me..." -- Orpheus and Death, in SANDMAN: "The Song of Orpheus" From claw@under.engr.sgi.com Tue Jan 26 02:12:59 1999 From: claw@under.engr.sgi.com (J C Lawrence) Date: Mon, 25 Jan 1999 18:12:59 -0800 Subject: [Mailman-Developers] commercial maillist system, lyris, looks rather similar In-Reply-To: Message from Ken Manheimer of "Sat, 23 Jan 1999 12:59:12 EST." Message-ID: <199901260212.SAA33406@under.engr.sgi.com> On Sat, 23 Jan 1999 12:59:12 -0500 (EST) Ken Manheimer wrote: > I just heard mention of a commercial mailling list manager, lyris, > that upon a tiny bit of investigation looks similar in some ways > to mailman - eg, the admin interface layout: Aye, and a very brag happy set of PR staff that rather got my dander up. > (listinfo?), the orientation on web interfaces, "automatic error > handling" (bounce handling), built-in archives, built-in mail > engine (for "blinding speed"), etc. From poking around a little, > it looks like they use perl at least as an extension language - i > wonder how it's built. Monolithic on top of an DBC-accessable database (C++ strongly rumoured), runs its own SMTP server/MTA, all archive/message access is via dynamic database queries, etc. > I'm pretty curious how long it's been around - they claim that: At least 4 years, probably more. > "Lyris was the first email list server to offer a web > interface for list administrators and members." Utter codswhallop, but there's nobody with money to argue. > No more "get me off this list!" messages. > on the lyris "about" page (http://www.lyris.com/about.html), , > framed as "failsafe unsubscribing" - i think i saw this phrase in > a recent mailman-users posting, i would not be surprised if the > poster saw it there...) They do this by posting a per-user unsubscribe address on EVERY message (single message with optional unique MessageID per message) sent to each subscriber. Thus, for isntance, every message you get from a Lyris based list will have a trailer ala: To unsuscribe from this list send a message to listname-unsubscribe-817689161263@domain with the above text having a unique and different address (seemingly random string of digits hashed from your subscription ID) for everybody who receives the posting (yup, no RCPT TO bundling). As a member you then just email that address to unsubscribe. -- J C Lawrence Internet: claw@kanga.nu (Contractor) Internet: coder@kanga.nu ---------(*) Internet: claw@under.engr.sgi.com ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From claw@under.engr.sgi.com Tue Jan 26 02:16:49 1999 From: claw@under.engr.sgi.com (J C Lawrence) Date: Mon, 25 Jan 1999 18:16:49 -0800 Subject: [Mailman-Developers] commercial maillist system, lyris, looks rather similar In-Reply-To: Message from Ken Manheimer of "Sat, 23 Jan 1999 12:59:12 EST." Message-ID: <199901260216.SAA33238@under.engr.sgi.com> On Sat, 23 Jan 1999 12:59:12 -0500 (EST) Ken Manheimer wrote: > Wish i had more time to investigate, if anyone does, please report > back... One thing they do have that I really like: You can place members on moderator detention. There are two flavours: 1) Have the next XXX posts from that user require moderator approval. Once they get XXX approvals then they are able to post freely. 2) Ditto to #1, but bounded by time, not count. One thing I really dislike: By default they rewrite the MessageID's on all outbound messages to give a unique MessageID per subscriber. This of course breaks reference threading, dupe checking, etc. This can (finally, it took a very long time) be turned off, but it is on by default and admin interface text is phrased to discourage turning it off. -- J C Lawrence Internet: claw@kanga.nu (Contractor) Internet: coder@kanga.nu ---------(*) Internet: claw@under.engr.sgi.com ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From claw@under.engr.sgi.com Tue Jan 26 02:23:33 1999 From: claw@under.engr.sgi.com (J C Lawrence) Date: Mon, 25 Jan 1999 18:23:33 -0800 Subject: [Mailman-Developers] Archiving using news gateway In-Reply-To: Message from Tomas Fasth of "Sun, 24 Jan 1999 12:49:28 +0100." <36AB08C8.93359F4@euronetics.se> Message-ID: <199901260223.SAA33438@under.engr.sgi.com> On Sun, 24 Jan 1999 12:49:28 +0100 Tomas Fasth wrote: > In "Re: [Mailman-Developers] commercial maillist system, lyris, > looks rather similar" Ken Manheimer wrote: >> It has some nice stuff that mailman doesn't - one interesting >> idea seems to be to use a news server for the archives. That >> way, archive browsers can use a news interface, or use a web >> browser to a news/web gateway. > Interesting approach. That is surely a possible workaround for the > current lack of MIME support in pipermail archiving. As a matter > of fact, I like the idea so much that I will give it a try. It has a problem: lack of good search facilities. HTML or database based list archives allow useful/intelligent search engines to be used to process them. eg I have roughly 40,000 messages up and HTML-iesed via MHonArc and indexed via WebGlimpse. Its an utter bitch to find anything without WebGlimpse. > So I guess the archive-through-news approach will work in most > cases. > Comments? Its a good option. Mostly I just want an MH-style folder for each quarter's (I operate on quarter's worth of messages, not months). -- J C Lawrence Internet: claw@kanga.nu (Contractor) Internet: coder@kanga.nu ---------(*) Internet: claw@under.engr.sgi.com ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From david@topware.com.tw Wed Jan 27 14:48:21 1999 From: david@topware.com.tw (David Li) Date: Wed, 27 Jan 1999 22:48:21 +0800 Subject: [Mailman-Developers] Localization? Message-ID: <36AF2735.FC6B05B@topware.com.tw> Hi, I recently discover mailman and it has been a great tool. However, because of the user of my mailing lists are mainly Chinese, I need to localize all message. Is there build-in support for locatilization in mailman? If not, is there a plan to develop one? The lack of localization makes it painful to track the prograss of mailman. Thanks. David Li david@topware.com.tw From david@topware.com.tw Wed Jan 27 15:12:22 1999 From: david@topware.com.tw (David Li) Date: Wed, 27 Jan 1999 23:12:22 +0800 Subject: [Mailman-Developers] Localization, a proposal... Message-ID: <36AF2CD6.73ABC6ED@topware.com.tw> I have a couple suggestions for supporting localization. 1. Add locale setting for mailing list. 2. In the template library, add support for locale in terms of directory. Thus, the default files for locale C will be under templates/C and for locale zh_TW.Big5 will be under templates/zh_TW.Big5. 3. Add support for locale in the in the 'maketext' method of Mailman/Utils.py, add the search capacity so it search the file first in the lists/mailinglist, then templates/LOCALE and then templates/C. From Harald.Meland@usit.uio.no Thu Jan 28 14:07:00 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 28 Jan 1999 15:07:00 +0100 Subject: [Mailman-Developers] (Maybe) wrong permissions on archives/private/listname/database Message-ID: First of all: This problem could be occuring because I have messed things up by not being consistent in the way I upgrade Mailman. I have, from time to time, run "make install" and "make update" as root, mailman or myself. Yeah, I'm not the most organized person in the world, I know. :) Anyway: My Mailman is configured like this: ./configure --prefix=/local/Mailman --without-gcc \ --with-python=/local/bin/python --with-cgi-gid=nobody \ --with-mail-gid=mailman My MTA pipes all the mailman stuff into /local/Mailman/mail/wrapper, running as the user "mailman" (which has default group "mailman"). For some of my lists, I have this situation: $ ls -l archives/private/LISTNAME/ total 20 drwxrwsr-x 2 nobody mailman 512 Dec 1 16:51 1998-December -rw-rw-r-- 1 nobody mailman 939 Dec 1 16:51 1998-December.txt drwxrwsrwx 2 nobody mailman 512 Nov 13 18:26 1998-November -rw-rw-rw- 1 nobody mailman 2663 Nov 23 15:32 1998-November.txt drwxrwsrwx 2 nobody mailman 512 Oct 29 15:18 1998-October -rw-rw-rw- 1 nobody mailman 2898 Oct 29 15:18 1998-October.txt drwxrwsr-x 2 nobody mailman 512 Jan 19 14:03 1999-January -rw-rw-r-- 1 nobody mailman 2573 Jan 19 14:03 1999-January.txt drwx--S--- 2 nobody mailman 2048 Jan 19 14:03 database -rw-rw-rw- 1 nobody mailman 2246 Jan 19 14:03 index.html -rw-rw-rw- 1 nobody mailman 555 Jan 19 14:03 pipermail.pck Are the permissions/owner on the "database" directory good? Why are some of the files world writable? For some other lists, which seem to have set very similar archival options to the list above, the owner of the "database" directory are: drwx--S--- 2 mailman mailman 1536 Jan 26 14:41 database or drwxrws--- 2 nobody mailman 1536 Jan 20 00:07 database I suppose pipermail is running as user/group "mailman" when it does it's job, and that pipermail not getting access to the "database" directory is a bad thing, right? Whenever I run "make update" as non-root, I get some warnings of the type: /local/gnu/bin/install: /local/Mailman/Mailman/pythonlib/getpass.py: Permission denied Compiling /local/Mailman/Mailman/Archiver/Archiver.py ... Sorry: IOError: (13, 'Permission denied') (which I now have fixed by chowning the necessary files/directories), and then some like this: Listing /local/Mailman/archives/private/LISTNAME/database ... Can't list /local/Mailman/archives/private/LISTNAME/database (which I'm not sure how to, or even *if*I*should*, fix). So, should "make update" scream louder/suggest manual interaction when it discovers anomalies like this? Should there (somewhere) be a warning about not varying what user you run "make install" and "make update" as? And shouldn't "make update" (or something) revoke those scary world writable permission bits? -- Harald From benfati@zzp.com.br Thu Jan 28 18:59:28 1999 From: benfati@zzp.com.br (Jose Carlos Benfati) Date: Thu, 28 Jan 1999 16:59:28 -0200 (EDT) Subject: [Mailman-Developers] thousands of subscribers Message-ID: Hello, I'm considering installing mailman to serve some very big lists. The biggest has more than 25000 members. Is there any restriction in mailman (like hardcoded values) that could cause me problems? Do you recommend mailman for that? thanks a lot. Jose Carlos Benfati ZZP Consultoria http://zzp.com.br From julian7@kva.hu Fri Jan 29 08:57:22 1999 From: julian7@kva.hu (Balazs Nagy) Date: Fri, 29 Jan 1999 09:57:22 +0100 (CET) Subject: [Mailman-Developers] Big lists Message-ID: Hiyas, How can I (we) set up mailman to handle big (with 25k or more subscribers) lists? I mean it would be nice if Mailman sent some mail to a distribution server which sent the same letter to a subset of subscribers. It can lower heavily the outgoing traffic. Regards: Balazs -- #!/usr/bin/perl -export-a-crypto-system-sig -http://dcs.ex.ac.uk/~aba/rsa print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0 Message-ID: Jose Carlos Benfati writes: > Hello, > > I'm considering installing mailman to serve some very big lists. The > biggest has more than 25000 members. One thing is the subscriber list, visible for subscribers themselves. It is linear, everything on one page and doesn't work well for 25000 members. Another thing is the digest format which triggers a sendmail MIME bug. Be sure to have sendmail 8.9.1 or newer, otherwise you site will explode. :) Even if your sendmail works, you're going to get annoyed messages from administrators of other sites who have an older sendmail dumping core because of your digests. These are my experiences with a list of about 1000 members. Otherwise, things have been running quite well. Load of the mailing list administrator is still quite high, because we use a strict filter catching all MIME and HTML messages. -- Janne From bwarsaw@python.org Fri Jan 29 17:16:48 1999 From: bwarsaw@python.org (Barry A. Warsaw) Date: Fri, 29 Jan 1999 12:16:48 -0500 (EST) Subject: [Mailman-Developers] Re: Please stop the cross posting References: <36B1E948.42CE8FE3@appliedbiometrics.com> Message-ID: <14001.60672.211755.185830@anthem.cnri.reston.va.us> >>>>> "CT" == Christian Tismer writes: CT> I will also propose to change Mailman to handle this CT> in a better way. My own patched version on Starship CT> never prepends the list name if it can be matched in the CT> "re" already. I thought Mailman already does this too. I'll double check. Chris, you might want to send your patches to mailman-developers@python.org -Barry From tismer@appliedbiometrics.com Fri Jan 29 17:29:28 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Fri, 29 Jan 1999 18:29:28 +0100 Subject: [Mailman-Developers] Re: Please stop the cross posting References: <36B1E948.42CE8FE3@appliedbiometrics.com> <14001.60672.211755.185830@anthem.cnri.reston.va.us> Message-ID: <36B1EFF8.FC755D60@appliedbiometrics.com> Barry A. Warsaw wrote: > > >>>>> "CT" == Christian Tismer writes: > > CT> I will also propose to change Mailman to handle this > CT> in a better way. My own patched version on Starship > CT> never prepends the list name if it can be matched in the > CT> "re" already. > > I thought Mailman already does this too. I'll double check. Chris, > you might want to send your patches to mailman-developers@python.org Well, these patches were for a very old Mailman. I don't know wether they still apply. But the idea is simple. Only prepend the prefix if you cannot string.find it. From maillist.py (V0.95): # Prepend the subject_prefix to the subject line. subj = msg.getheader('subject') prefix = self.subject_prefix if prefix: prefix = prefix + ' ' if not subj: msg.SetHeader('Subject', '%s(no subject)' % prefix) else: #CT begin #CT adding only if not already present if string.find(subj, prefix) < 0: msg.SetHeader('Subject', '%s%s' % (prefix, subj)) #CT end dont_send_to_sender = 0 ack_post = 0 -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.skyport.net 10553 Berlin : PGP key -> http://pgp.ai.mit.edu/ we're tired of banana software - shipped green, ripens at home From tismer@appliedbiometrics.com Fri Jan 29 17:36:13 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Fri, 29 Jan 1999 18:36:13 +0100 Subject: [Mailman-Developers] Re: Please stop the cross posting References: <36B1E948.42CE8FE3@appliedbiometrics.com> <14001.60672.211755.185830@anthem.cnri.reston.va.us> Message-ID: <36B1F18D.39BA7539@appliedbiometrics.com> Barry A. Warsaw wrote: > > >>>>> "CT" == Christian Tismer writes: > > CT> I will also propose to change Mailman to handle this > CT> in a better way. My own patched version on Starship > CT> never prepends the list name if it can be matched in the > CT> "re" already. > > I thought Mailman already does this too. I'll double check. Chris, > you might want to send your patches to mailman-developers@python.org Well, I had a look: New Mailman does this: prefix = self.subject_prefix if not subj: msg.SetHeader('Subject', '%s(no subject)' % prefix) elif not re.match("(re:? *)?" + re.escape(self.subject_prefix), subj, re.I): msg.SetHeader('Subject', '%s%s' % (prefix, subj)) if self.anonymous_list: This is insufficient for cross-posts which are replied to from a different list. I think my string.find approach is crude, simple, but exactly the right thing. Forget about seldom possible missing prefixes... ciao - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.skyport.net 10553 Berlin : PGP key -> http://pgp.ai.mit.edu/ we're tired of banana software - shipped green, ripens at home From petrilli@amber.org Fri Jan 29 17:40:42 1999 From: petrilli@amber.org (Christopher G. Petrilli) Date: Fri, 29 Jan 1999 12:40:42 -0500 Subject: [Mailman-Developers] Re: Please stop the cross posting In-Reply-To: <36B1EFF8.FC755D60@appliedbiometrics.com>; from Christian Tismer on Fri, Jan 29, 1999 at 06:29:28PM +0100 References: <36B1E948.42CE8FE3@appliedbiometrics.com> <14001.60672.211755.185830@anthem.cnri.reston.va.us> <36B1EFF8.FC755D60@appliedbiometrics.com> Message-ID: <19990129124042.14584@amber.org> On Fri, Jan 29, 1999 at 06:29:28PM +0100, Christian Tismer wrote: > Barry A. Warsaw wrote: > > > > >>>>> "CT" == Christian Tismer writes: > > > > CT> I will also propose to change Mailman to handle this > > CT> in a better way. My own patched version on Starship > > CT> never prepends the list name if it can be matched in the > > CT> "re" already. > > > > I thought Mailman already does this too. I'll double check. Chris, > > you might want to send your patches to mailman-developers@python.org > > Well, these patches were for a very old Mailman. I don't know > wether they still apply. But the idea is simple. Only prepend > the prefix if you cannot string.find it. > Hmm, would anyone else be interested in the option to "merge" x-posted mailings... what I guess I mean is that I'm on a bunch of python.org lists, and when things get crossposted, I get like 400 copies of each message... it'd be nice to figure out a way to only get ONE copy :-) Chris -- | Christopher Petrilli | petrilli@amber.org From ken@digicool.com Fri Jan 29 17:59:02 1999 From: ken@digicool.com (Ken Manheimer) Date: Fri, 29 Jan 1999 12:59:02 -0500 (EST) Subject: [Mailman-Developers] Re: Please stop the cross posting In-Reply-To: <36B1EFF8.FC755D60@appliedbiometrics.com> Message-ID: (Proper handling of the subject line prefix was one of the first things i did - i'm pretty sure it was before 1.0b3, maybe 1.0b1. If i recall correctly, i implemented a slightly more stringent strategy, only looking for the prefix early on in the subject line, after "re:"'s, but before other text. I know it takes care of the vast majority of cases, and i suspect it's preferable more of the time in offbeat cases than looking for the prefix anywhere in the subject line, but i may be wrong. I didn't see the original post - still sorting out environment and email - so i'm not sure about the specific case being discussed...) Ken On Fri, 29 Jan 1999, Christian Tismer wrote: > Barry A. Warsaw wrote: > > > > >>>>> "CT" == Christian Tismer writes: > > > > CT> I will also propose to change Mailman to handle this > > CT> in a better way. My own patched version on Starship > > CT> never prepends the list name if it can be matched in the > > CT> "re" already. > > > > I thought Mailman already does this too. I'll double check. Chris, > > you might want to send your patches to mailman-developers@python.org > > Well, these patches were for a very old Mailman. I don't know > wether they still apply. But the idea is simple. Only prepend > the prefix if you cannot string.find it. From ken@digicool.com Fri Jan 29 18:01:25 1999 From: ken@digicool.com (Ken Manheimer) Date: Fri, 29 Jan 1999 13:01:25 -0500 (EST) Subject: [Mailman-Developers] Re: Please stop the cross posting In-Reply-To: <36B1F18D.39BA7539@appliedbiometrics.com> Message-ID: > This is insufficient for cross-posts which are replied to > from a different list. > I think my string.find approach is crude, simple, but exactly > the right thing. Forget about seldom possible missing prefixes... You're probably right - the simpler approach would prevent alternation across lists from compounding the respective prefixes. (Though the idea of messages alternating from list to list gives me the willies, but that's besides the point...-) Ken From ken@digicool.com Fri Jan 29 18:05:33 1999 From: ken@digicool.com (Ken Manheimer) Date: Fri, 29 Jan 1999 13:05:33 -0500 (EST) Subject: [Mailman-Developers] Re: Please stop the cross posting In-Reply-To: <19990129124042.14584@amber.org> Message-ID: On Fri, 29 Jan 1999, Christopher G. Petrilli wrote: > Hmm, would anyone else be interested in the option to "merge" x-posted > mailings... what I guess I mean is that I'm on a bunch of python.org > lists, and when things get crossposted, I get like 400 copies of each > message... it'd be nice to figure out a way to only get ONE copy :-) This would be one reason to have an object database to keep track of what gets posted where. I think this sort of thing is likely in a new architecture for mailman, using and as components for a zope framework. (An issue here is whether zope's new relaxation of the attribution requirement, and Open Source certification, will satisfy stallman for gnu-yness - if so, it'd make it easy to integrate mailma and zope more closely, exploit bobopos/zopepos, etc.) Ken From tismer@appliedbiometrics.com Fri Jan 29 18:24:21 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Fri, 29 Jan 1999 19:24:21 +0100 Subject: [Mailman-Developers] Re: Please stop the cross posting References: Message-ID: <36B1FCD5.EDACFFAC@appliedbiometrics.com> Ken Manheimer wrote: > > > This is insufficient for cross-posts which are replied to > > from a different list. > > I think my string.find approach is crude, simple, but exactly > > the right thing. Forget about seldom possible missing prefixes... > > You're probably right - the simpler approach would prevent alternation > across lists from compounding the respective prefixes. (Though the idea > of messages alternating from list to list gives me the willies, but that's > besides the point...-) It basically appeared to me as bad manners to reply to cross-posted messages in a zig-zag. On the other hand, if somebody is really on one list and not on the other, this is the only way that works. That thread on XML/Zope sigs became really unreadable since prefixes piled up. It seems to be hard to tackle this in a more intelligent way. Ok, we can prevend prefixes from stacking. But the bigger problem which hurts at the same time (See Chris Petrilli's message) is that you get these crossposted things twice, also. I don't see an easy way to avoid this when cross posting is allowed. One way would be this: When Mailman receives a post, it can see all the recipients, especially it can see its own hostname, with different mailing lists. Unfortunately, the receiving process will duplicate the message and send it to the different aliases, one for each list. To capture this, sendmail must be intercepted by something like procmail (just as an example) which first makes sure that only one list gets that message. The one list which receives the message now reads the recipient list, and temporarily merges the user lists of the mentioned mailing lists into one. This could make sure that you don't get a duplicate message. How about that? - ciao - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.skyport.net 10553 Berlin : PGP key -> http://pgp.ai.mit.edu/ we're tired of banana software - shipped green, ripens at home From petrilli@amber.org Fri Jan 29 18:34:49 1999 From: petrilli@amber.org (Christopher G. Petrilli) Date: Fri, 29 Jan 1999 13:34:49 -0500 Subject: [Mailman-Developers] Re: Please stop the cross posting In-Reply-To: <36B1FCD5.EDACFFAC@appliedbiometrics.com>; from Christian Tismer on Fri, Jan 29, 1999 at 07:24:21PM +0100 References: <36B1FCD5.EDACFFAC@appliedbiometrics.com> Message-ID: <19990129133449.31890@amber.org> On Fri, Jan 29, 1999 at 07:24:21PM +0100, Christian Tismer wrote: > > You're probably right - the simpler approach would prevent alternation > > across lists from compounding the respective prefixes. (Though the idea > > of messages alternating from list to list gives me the willies, but that's > > besides the point...-) > > It basically appeared to me as bad manners to reply to > cross-posted messages in a zig-zag. On the other hand, if somebody > is really on one list and not on the other, this is the only > way that works. That thread on XML/Zope sigs became really > unreadable since prefixes piled up. I'm sure I was partially to blame for that one, unfortunately it's easy to get confused, plus sometimes I get them in different orders, and I usually respond to the first example :-) Oh well, the human brain works in mysterious and lousy ways. > It seems to be hard to tackle this in a more intelligent way. > Ok, we can prevend prefixes from stacking. > But the bigger problem which hurts at the same time (See > Chris Petrilli's message) is that you get these crossposted > things twice, also. Also, I think it should be possible to prevent xposts period... At least if the lists are hosted on the same machine... or maybe even an ability to define lists that aren't allowed to be xpoststed to... I dunno, this needs to be thought out more. I have some ideas about how to restructure the mailing list delivery stuff so that it will not send out multiple copies to the same person through different lists. > I don't see an easy way to avoid this when cross posting is allowed. > One way would be this: > > When Mailman receives a post, it can see all the recipients, > especially it can see its own hostname, with different > mailing lists. Unfortunately, the receiving process will > duplicate the message and send it to the different aliases, > one for each list. To capture this, sendmail must be intercepted > by something like procmail (just as an example) which first makes > sure that only one list gets that message. I don't think this belongs in the MTA, it belongs in the mailing list manager... but that's just me... Also, remember that a lot of us (myself for example) don't use Sendmail any more... > The one list which receives the message now reads the recipient > list, and temporarily merges the user lists of the mentioned > mailing lists into one. This could make sure that you don't > get a duplicate message. Hmm... I'll try and write down my ideas for a more hmm, "elegant" solution, at least in my mind... think garbage collection, it's a bizarre premise, but... Basically, you have a list of all recipients on all lists merged together, you then have a list of messages that need to be delivered to recipients with certain interests... you can then attach this message object to all the recipients (via whatever method), thereby determining whether or not the recipient will already be receiving the message. I've written (a long time ago) a Usenet server that worked on a similar principle... was quite quick, and very effecient. It was in C, but I can't imagine that it should be that hard in Python... this is NOT a Mailman 1.x exercise :-) Chris -- | Christopher Petrilli | petrilli@amber.org From ken@digicool.com Fri Jan 29 18:40:50 1999 From: ken@digicool.com (Ken Manheimer) Date: Fri, 29 Jan 1999 13:40:50 -0500 (EST) Subject: [Mailman-Developers] Re: Please stop the cross posting In-Reply-To: <36B1FCD5.EDACFFAC@appliedbiometrics.com> Message-ID: [... regarding compounding subject prefixes in cross-posted maillist messages, and more generally avoiding duplication of cross posts ...] On Fri, 29 Jan 1999, Christian Tismer wrote: > It seems to be hard to tackle this in a more intelligent way. > Ok, we can prevent prefixes from stacking. > But the bigger problem which hurts at the same time (See > Chris Petrilli's message) is that you get these crossposted > things twice, also. > > I don't see an easy way to avoid this when cross posting is allowed. > One way would be this: Offhand, there seem to me to be two key items here: - mailman can unequivocally identify the message id and the recipients of members of any lists which it is serving on the same host, so given a decent architecture (modularized message flow tracking db) it should be easy to provide users the option to inhibit receiving more than the first copy of a cross posted message - this issue does not seem critical enough to retrofit it to the existing architecture (which does virtually no flow tracking, certainly not across lists), at least not compared to the various rough edges that currently need to be polished off (eg, subscription delivery address changing without un/resubscribe, better implementation of admin pending items, lots of other stuff.) > When Mailman receives a post, it can see all the recipients, > especially it can see its own hostname, with different > mailing lists. Unfortunately, the receiving process will > duplicate the message and send it to the different aliases, > one for each list. To capture this, sendmail must be intercepted > by something like procmail (just as an example) which first makes > sure that only one list gets that message. Um, it doesn't make sense to go external when all the info is available internally to mailman as a whole! Instead, the internal infrastructure needs to be developed - something that should go on the list for modular mailman, or whatever it'll be... Ken From ken@digicool.com Fri Jan 29 18:47:21 1999 From: ken@digicool.com (Ken Manheimer) Date: Fri, 29 Jan 1999 13:47:21 -0500 (EST) Subject: [Mailman-Developers] Re: Please stop the cross posting In-Reply-To: <19990129133449.31890@amber.org> Message-ID: On Fri, 29 Jan 1999, Christopher G. Petrilli wrote: > Basically, you have a list of all recipients on all lists merged > together, you then have a list of messages that need to be delivered to > recipients with certain interests... you can then attach this message > object to all the recipients (via whatever method), thereby determining > whether or not the recipient will already be receiving the message. > > I've written (a long time ago) a Usenet server that worked on a similar > principle... was quite quick, and very effecient. It was in C, but I > can't imagine that it should be that hard in Python... this is NOT a > Mailman 1.x exercise :-) I don't think it's a hard problem, and i agree, i don't think it's high enough priority to retrofit to 1.x. If there's sufficient mandate (read, incentives for digital creations) for mailman and zope to exploit on eachother's capabilities, we may be able to spend some time tailoring them for eachother a bit, avoiding locking mailman to zope, but strengthing mailman where zope is available... Exciting prospects, and i actually think there will be the mandate. Got a lot to do before then, though, so don't hold your breath. (BTW, ironically, i've been tempted to post my messages in this to the zope list!-) Ken From rocon@pivot.net Fri Jan 29 18:45:11 1999 From: rocon@pivot.net (Robert OConnor) Date: Fri, 29 Jan 1999 13:45:11 -0500 Subject: [Mailman-Developers] Forward e-mail fix needed Message-ID: <004501be4bb8$0862a220$0201a8c0@hawkeye.bob.oc> Hi mailmen, I am subscribed to the zope.org list and when I subscribed, I could not use my forwarded email address from my domain bob@rocnet.com Instead, I had to use my ISP address rocon@pivot.net. When I used the forwarded address, I was subscribed and confirmed but never see my posts on the list come back as a post. Thank you. -bobo connor From petrilli@amber.org Fri Jan 29 18:57:17 1999 From: petrilli@amber.org (Christopher G. Petrilli) Date: Fri, 29 Jan 1999 13:57:17 -0500 Subject: [Mailman-Developers] Re: Please stop the cross posting In-Reply-To: ; from Ken Manheimer on Fri, Jan 29, 1999 at 01:47:21PM -0500 References: <19990129133449.31890@amber.org> Message-ID: <19990129135717.59463@amber.org> On Fri, Jan 29, 1999 at 01:47:21PM -0500, Ken Manheimer wrote: > On Fri, 29 Jan 1999, Christopher G. Petrilli wrote: > > > [I propose some half-baked thoughts about object relationships] > I don't think it's a hard problem, and i agree, i don't think it's high > enough priority to retrofit to 1.x. If there's sufficient mandate (read, > incentives for digital creations) for mailman and zope to exploit on > eachother's capabilities, we may be able to spend some time tailoring them > for eachother a bit, avoiding locking mailman to zope, but strengthing > mailman where zope is available... Exciting prospects, and i actually > think there will be the mandate. Got a lot to do before then, though, so > don't hold your breath. > Well, given all the licensing things not being resolved yet, these are just hypothetical ideas... well, real ideas with hypothetical probability! What I see is this... not Mailmain as part of Zope, but a parallel "application" on top of the Zbase... this of course depends on the new ideas proposed by Jim for BoboPOS3, ney Zbase 3? Zope could then be used to provide a management interface to the mailing-list "publisher" that works off the same database. I don't know... hmm... it's all so complex! :-) I'm going to sit down and think through the object-model that would be necessary for this, maybe whip out a few UML models to put it down on virtual paper... assuming I remember all my modeling theory! ;-) One idea, and I don't know how feasible it is at THIS point, is to use ZPublisher as the basis for a new management interface, and then wrap that up in such a way as to allow it to be Productized for Zope so someone could just plug the interface in anywhere they want :-) > (BTW, ironically, i've been tempted to post my messages in this to the > zope list!-) No no, not at this point anyway... I'm new to this whole thign anyway, so maybe I'm just wacko and thinking of things that have been hased out to death already. Chris -- | Christopher Petrilli | petrilli@amber.org From jeff@ollie.clive.ia.us Fri Jan 29 19:26:46 1999 From: jeff@ollie.clive.ia.us (Jeffrey C. Ollie) Date: Fri, 29 Jan 1999 13:26:46 -0600 Subject: [Mailman-Developers] Limiting copies of cross posts sent Message-ID: <36B20B76.9D9955B0@ollie.clive.ia.us> This is a cryptographically signed message in MIME format. --------------ms6F55531ACE1126FB6C6E561C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here's one idea for limiting the number of messages sent when a message is cross-posted to multiple lists. I haven't actually tried implementing this idea yet so it may be impractical. The nice thing that I like about this method is that it doesn't require that a database of message-ids be kept. Ok, here's the idea: SMTP allows for multiple recipients to be specified for any message sent. A typical conversation would look something like this (apologies if my mailer wraps the lines): 220 python.org ESMTP Sendmail 8.9.1a/8.9.1 (klm); Fri, 29 Jan 1999 14:15:14 -0500 (EST) HELO max.ollie.clive.ia.us 250 python.org Hello IDENT:jcollie@max.ollie.clive.ia.us [161.210.214.102], pleased to meet you MAIL From: 250 ... Sender ok RCPT To: 250 ... Recipient ok RCPT To: 250 ... Recipient ok DATA 354 Enter mail, end with "." on a line by itself . 250 OAA18072 Message accepted for delivery Now, if you can get the SMTP daemon to invoke MailMan once and pass all of the recipients, MailMan could use that information to send one copy of the message to the union of the set of subscribers for each list. Of course MailMan would need to be changed significantly to handle this, but you wouldn't need a database. Jeff --------------ms6F55531ACE1126FB6C6E561C Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIJ6AYJKoZIhvcNAQcCoIIJ2TCCCdUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B3QwggQ+MIIDp6ADAgECAhAH45KMD5ppjHBDd8plU0arMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk4MTAwMjAwMDAw MFoXDTk5MTAwMjIzNTk1OVowggEWMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxFjAUBgNVBAMUDUplZmZyZXkgT2xsaWUxJTAjBgkqhkiG 9w0BCQEWFmplZmZAb2xsaWUuY2xpdmUuaWEudXMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALznR/JfeMFeOL38y5n0N48TKu+pvfHuCa4mNMTl0/Im7S+rqGMc33+8SkjTUAik31nq iCNV2rSkcoegAkl3Ap0R5vEavmBA+v3PKKoDtl4jlhItCUlFxYqTMZ/sv43NbJ7O8EzJNs4s gcG4uqMqLcY4ASjpIdDk+Uy75j7kW+VHAgMBAAGjgdMwgdAwCQYDVR0TBAIwADCBrwYDVR0g BIGnMIAwgAYLYIZIAYb4RQEHAQEwgDAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNp Z24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlT aWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNp Z24AAAAAAAAwEQYJYIZIAYb4QgEBBAQDAgeAMA0GCSqGSIb3DQEBBAUAA4GBAEPk6HE6JHjs dKTRSz5YCSD5mj1zzeTo0MMWPB17NuUvssI6iCndVzzVxgwfsRGymWjTv6wijb0NlZ4HpkKW WY5v34W3775MLT+dO5N854iJJ6l5Ym2RVUPkkwGyCKElMoO6ds67fTIj/2u2ZjURZtzxoMwb ZFA+s6XT1rNEcZRsMIIDLjCCApegAwIBAgIRANJ2Lo0UDD19sqglXa/uDXUwDQYJKoZIhvcN AQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQL Ey5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4 MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNp Z24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgw RgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJz b25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV /QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC 8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+ 78nbN2rISsgJBuSZAgMBAAGjfDB6MBEGCWCGSAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwG C2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEA iLg3O93alDcAraqf4YEBcR6Sam0v9vGd08pkONwbmAwHhluFFWoPuUmFpJXxF31ntH8tLN2a Qp7DPrSOquULBt7yVir6M8e+GddTTMO9yOMXtaRJQmPswqYXD11YGkk8kFxVo2UgAP0YIOVf gqaxqJLFWGrBjQM868PNBaKQrm4xggI8MIICOAIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3 dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFRE KGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3Jp YmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQB+OSjA+aaYxwQ3fKZVNGqzAJBgUrDgMCGgUA oIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk5MDEyOTE5 MjY0N1owIwYJKoZIhvcNAQkEMRYEFFWP57GZ4isjuf45nfhh1dOCmpqvMFIGCSqGSIb3DQEJ DzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAtwP2TeO8JLOiXMCY3U5PU81V eYGun8xKS8vkYRTh2WC0xpXeRKxM0cv/TXz4VVTLRtRsWqjXpucjxcSHyNh+byqPIsGBv/Nv gAp6KvN6l55M1IKFFtOAS/kfoiWKOvsGvLtdKny+ElCkYPxVt+Fv2IYolyz2cdsbbbxbyeyE 5jE= --------------ms6F55531ACE1126FB6C6E561C-- From tismer@appliedbiometrics.com Fri Jan 29 19:25:19 1999 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Fri, 29 Jan 1999 20:25:19 +0100 Subject: [Mailman-Developers] Re: Please stop the cross posting References: Message-ID: <36B20B1F.87887A7F@appliedbiometrics.com> (Ken) > Offhand, there seem to me to be two key items here: > > - mailman can unequivocally identify the message id and the recipients of > members of any lists which it is serving on the same host, so given a > decent architecture (modularized message flow tracking db) it should be > easy to provide users the option to inhibit receiving more than the > first copy of a cross posted message Well, I forgot about that. This makes it of course easy. > Um, it doesn't make sense to go external when all the info is available > internally to mailman as a whole! Instead, the internal infrastructure > needs to be developed - something that should go on the list for modular > mailman, or whatever it'll be... Of course! For me, identifying the message was the problem, but I should have known better. And instead of waiting for a new Mailman generation, I see that this problem has two sides: A message appears to have always an ID which is generated by the email program (not sure if that is guaranteed, but very likely). That means one could set up the sendmail (qmail, whatever) configuration in a way that it checks the incoming mail for duplicate IDs. This would also work for cross-postings to different Mailman sites. Having both would be perfect and would save bandwidth, but one suffices to yield the desired effect. Should I try to write a little filter which keeps track of message IDs for a short period, and drops those already seen? This would be a small Python tool for the email client side, not touching Mailman at all. Looks quite practical to me. ciao - chris -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Allee 101 : *Starship* http://starship.skyport.net 10553 Berlin : PGP key -> http://pgp.ai.mit.edu/ we're tired of banana software - shipped green, ripens at home From petrilli@amber.org Fri Jan 29 19:35:09 1999 From: petrilli@amber.org (Christopher G. Petrilli) Date: Fri, 29 Jan 1999 14:35:09 -0500 Subject: [Mailman-Developers] Object ideas for duplicate supression Message-ID: <19990129143509.10781@amber.org> yeah yeah, I know ... it's me again... here's some ideas for Mailman2, and note these objects could be stored in a nice fancy object database :-) ---- ramblings begin Ok, here's the 5 minute concept... think of it as modeling-light. Two types of objects: * List object * Subscriber object There is a many-many relationship between Lists and Subscribers, meaning obviously that Lists can contain many subscribers, and Subscribers can contain many lists. This creates a concern for clean-up given circular references. Need to think through this.[1] Now, the best way to understand this is to deal with a message coming in, and how does it get exploded into the subscribers necessary: First, you know who the mailer sent it to (say listA), but then you parse through the To:/CC: headers looking for other lists, making a note of them. If there are no other lists (local lists, not remote lists) identified then proceed with the normal delivery, no reason here to compare Message-Id: with those stored. However, if another local list is discovered (listB) then duplicate-supression should be run. What this requires is exploding the message into all of its subscribers, and matching that with the subscribers of listB, if no overlap, short-circuit to normal delivery. But, if you do have overlap, then for each overlap, check the subscribers 'recent-ids' attribute for the current message's attribute, if it doesn't exist, append it, and send the message out. If it does exist, delete the recipient from the list passed to the MTA. Seems simple, though I'm sure I've glossed over a billion and one things. --- Footnotes [1] This can probable be fixed by making sure that you break the link manually rather than depending on garbage collection. Or maybe weak lists? When you delete a list, scan the subscribers, looking for reverse links, and break them, then you delete the list. Same thing for the deletion of a subscriber. -- | Christopher Petrilli | petrilli@amber.org From petrilli@amber.org Fri Jan 29 19:45:16 1999 From: petrilli@amber.org (Christopher G. Petrilli) Date: Fri, 29 Jan 1999 14:45:16 -0500 Subject: [Mailman-Developers] Limiting copies of cross posts sent In-Reply-To: <36B20B76.9D9955B0@ollie.clive.ia.us>; from Jeffrey C. Ollie on Fri, Jan 29, 1999 at 01:26:46PM -0600 References: <36B20B76.9D9955B0@ollie.clive.ia.us> Message-ID: <19990129144516.52367@amber.org> On Fri, Jan 29, 1999 at 01:26:46PM -0600, Jeffrey C. Ollie wrote: > > Now, if you can get the SMTP daemon to invoke MailMan once and pass all > of the recipients, MailMan could use that information to send one copy > of the message to the union of the set of subscribers for each list. > Having just spent gods know how much time hacking up sendmail, this is a problem... here's why.. * Sendmail only does this under SMTP, not under anything else So, that means that Mailman would have to accept its messages over SMTP, which sin't in itself a problem... the problem is that as far as I've been able to determine, sendmail can't be told to deliver SMTP mail to a different port than 25. Also, you'd end up with mailer re-write rules out the ying-yang :-) Trust me, you never ever ever ever want to do anything that requires someone to add anything bizarre to their sendmail installation. > Of course MailMan would need to be changed significantly to handle this, > but you wouldn't need a database. That's not nearly as ugly as the problems with doing it ... also it'd be different for every mailer, and quite different in many cases I think. -- | Christopher Petrilli | petrilli@amber.org From darren@jasper.somtel.com Fri Jan 29 20:30:51 1999 From: darren@jasper.somtel.com (Darren Henderson) Date: Fri, 29 Jan 1999 15:30:51 -0500 (EST) Subject: [Mailman-Developers] Re: Please stop the cross posting In-Reply-To: <36B20B1F.87887A7F@appliedbiometrics.com> Message-ID: On Fri, 29 Jan 1999, Christian Tismer wrote: > A message appears to have always an ID which is generated by > the email program (not sure if that is guaranteed, but very likely). > That means one could set up the sendmail (qmail, whatever) > configuration in a way that it checks the incoming mail for > duplicate IDs. This would also work for cross-postings to different imo this really isn't something that belongs in mailman, you start getting into all kinds of nasty hueristics ... if you belong to two groups and a message is cross posted which group do you favor and give the message too? It just gets worse as you add groups. Do you addresss that by taking the intersection and making it look like it only comes from one address? Do you let each user decide? It would seem better addressed as another list adminisitrator concern. You could help them I suppose, give them the ability to say, "list a and b will not accept crossposts from one another" but generally its probably enough that they gentley remind their users when it occurs excessively. On the user side procmail makes filtering via msgid quite fiesable. I think http://members.xoom.com/procmail/aks-lib/dupcheck.rc will do what you want. ______________________________________________________________________ Darren Henderson darren@jasper.somtel.com Help fight junk e-mail, visit http://www.cauce.org/ From jeff@ollie.clive.ia.us Fri Jan 29 20:46:59 1999 From: jeff@ollie.clive.ia.us (Jeffrey C. Ollie) Date: Fri, 29 Jan 1999 14:46:59 -0600 Subject: [Mailman-Developers] Limiting copies of cross posts sent References: <36B20B76.9D9955B0@ollie.clive.ia.us> <19990129144516.52367@amber.org> Message-ID: <36B21E43.C8DD3DF6@ollie.clive.ia.us> This is a cryptographically signed message in MIME format. --------------ms4965B7C00B6C64A64D8A6244 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Christopher G. Petrilli" wrote: > > On Fri, Jan 29, 1999 at 01:26:46PM -0600, Jeffrey C. Ollie wrote: > > > > Now, if you can get the SMTP daemon to invoke MailMan once and pass all > > of the recipients, MailMan could use that information to send one copy > > of the message to the union of the set of subscribers for each list. > > Having just spent gods know how much time hacking up sendmail, this is a > problem... here's why.. > > * Sendmail only does this under SMTP, not under anything else Not if you add the 'm' flag to the delivery agent. Then sendmail will invoke the delivery agent with multiple recipients specified on the command line. > So, that means that Mailman would have to accept its messages over SMTP, > which sin't in itself a problem... the problem is that as far as I've > been able to determine, sendmail can't be told to deliver SMTP mail to a > different port than 25. Actually you can, see p522 in the 2nd edition of _Sendmail_ (section 30.4.1.2). > Also, you'd end up with mailer re-write rules > out the ying-yang :-) Trust me, you never ever ever ever want to do > anything that requires someone to add anything bizarre to their sendmail > installation. Yeah, that's for sure. We'd want to keep it simple. > > Of course MailMan would need to be changed significantly to handle this, > > but you wouldn't need a database. > > That's not nearly as ugly as the problems with doing it ... also it'd be > different for every mailer, and quite different in many cases I think. Yes, existence of multiple SMTP daemons is a problem in that we'd have to provide documentation on how to modify the configuration for many different daemons. However doesn't this already happen? Aren't sendmail, exim, qmail, or whatever sufficiently different in their implementation that setup is already problematic? Another, more radical idea would be to completely replace the regular SMTP daemon with a SMTP daemon written in Python that integrates directly with MailMan. I've been considering doing that for another, more radical project that I have in mind. The only problem with this is that you have to dedicate a box to running MailMan and there would be some performace issues, but I guess that this would be offset by the ability to run MailMan on a Windows or Mac OS system. The idea of using a database to filter out multiple copies would be problematic for sites that have high volume lists with a large subscriber base. Just think of all of the storage that you'd need! Jeff --------------ms4965B7C00B6C64A64D8A6244 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIJ6AYJKoZIhvcNAQcCoIIJ2TCCCdUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B3QwggQ+MIIDp6ADAgECAhAH45KMD5ppjHBDd8plU0arMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk4MTAwMjAwMDAw MFoXDTk5MTAwMjIzNTk1OVowggEWMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxFjAUBgNVBAMUDUplZmZyZXkgT2xsaWUxJTAjBgkqhkiG 9w0BCQEWFmplZmZAb2xsaWUuY2xpdmUuaWEudXMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALznR/JfeMFeOL38y5n0N48TKu+pvfHuCa4mNMTl0/Im7S+rqGMc33+8SkjTUAik31nq iCNV2rSkcoegAkl3Ap0R5vEavmBA+v3PKKoDtl4jlhItCUlFxYqTMZ/sv43NbJ7O8EzJNs4s gcG4uqMqLcY4ASjpIdDk+Uy75j7kW+VHAgMBAAGjgdMwgdAwCQYDVR0TBAIwADCBrwYDVR0g BIGnMIAwgAYLYIZIAYb4RQEHAQEwgDAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNp Z24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlT aWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNp Z24AAAAAAAAwEQYJYIZIAYb4QgEBBAQDAgeAMA0GCSqGSIb3DQEBBAUAA4GBAEPk6HE6JHjs dKTRSz5YCSD5mj1zzeTo0MMWPB17NuUvssI6iCndVzzVxgwfsRGymWjTv6wijb0NlZ4HpkKW WY5v34W3775MLT+dO5N854iJJ6l5Ym2RVUPkkwGyCKElMoO6ds67fTIj/2u2ZjURZtzxoMwb ZFA+s6XT1rNEcZRsMIIDLjCCApegAwIBAgIRANJ2Lo0UDD19sqglXa/uDXUwDQYJKoZIhvcN AQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQL Ey5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4 MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNp Z24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgw RgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJz b25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV /QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC 8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+ 78nbN2rISsgJBuSZAgMBAAGjfDB6MBEGCWCGSAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwG C2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEA iLg3O93alDcAraqf4YEBcR6Sam0v9vGd08pkONwbmAwHhluFFWoPuUmFpJXxF31ntH8tLN2a Qp7DPrSOquULBt7yVir6M8e+GddTTMO9yOMXtaRJQmPswqYXD11YGkk8kFxVo2UgAP0YIOVf gqaxqJLFWGrBjQM868PNBaKQrm4xggI8MIICOAIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3 dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFRE KGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3Jp YmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQB+OSjA+aaYxwQ3fKZVNGqzAJBgUrDgMCGgUA oIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk5MDEyOTIw NDcwMVowIwYJKoZIhvcNAQkEMRYEFPB5ZKCJLhxQdTLTBAnKyi5b936YMFIGCSqGSIb3DQEJ DzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAMybxYvKJiN2atwifDL5aZ2rP rj5tax0trzRh1B4/Z96/HY4SL3cf9hFgtTHhE/NvDeFLmliPQK4ah/HEUK7nhAS3UL9OFTka 6BF27oNmdv6YXwfuBUBXKpBHubq2jeq9XD7qCRHjc1ZKDHqh5UxdN4wDQlb0UUFVmzHrUFFD IUU= --------------ms4965B7C00B6C64A64D8A6244-- From petrilli@amber.org Fri Jan 29 20:55:25 1999 From: petrilli@amber.org (Christopher G. Petrilli) Date: Fri, 29 Jan 1999 15:55:25 -0500 Subject: [Mailman-Developers] Duplicate supression idea [was: Re: Please stop the cross posting] In-Reply-To: ; from Darren Henderson on Fri, Jan 29, 1999 at 03:30:51PM -0500 References: <36B20B1F.87887A7F@appliedbiometrics.com> Message-ID: <19990129155525.56617@amber.org> On Fri, Jan 29, 1999 at 03:30:51PM -0500, Darren Henderson wrote: > On Fri, 29 Jan 1999, Christian Tismer wrote: > > > [I propose some nefarious plot to undermine all mail systems :-)] > > imo this really isn't something that belongs in mailman, you start getting > into all kinds of nasty hueristics ... if you belong to two groups and a > message is cross posted which group do you favor and give the message too? > It just gets worse as you add groups. Do you addresss that by taking the > intersection and making it look like it only comes from one address? Do > you let each user decide? Well, I figure this isn't THAT hugely common, which of course asks, why do it, but regardless... anyway, the user gets the copy that first shows up in th mailsystem... which basically would be whichever one is listed first in the recipients list from the MTA's perspective. THat's not relevent, underneith it's the same information. You don't munge anything in the headers, you just adjust the recipient list for the outgoing message (RCPT info), and you deal with it again when 2 copies come in again. I don't see any other way to fdo this. Yes you could decide on a per user basis (make duplicate-supression an option, turned on by default, I suppose). > It would seem better addressed as another list adminisitrator concern. You > could help them I suppose, give them the ability to say, "list a and b > will not accept crossposts from one another" but generally its probably > enough that they gentley remind their users when it occurs excessively. I think this is a seperate issue, though obviously related. Sometimes you do want x-posts... sometimes you don't, that should be an option. Just my handwaving Chris -- | Christopher Petrilli | petrilli@amber.org From petrilli@amber.org Fri Jan 29 21:02:54 1999 From: petrilli@amber.org (Christopher G. Petrilli) Date: Fri, 29 Jan 1999 16:02:54 -0500 Subject: [Mailman-Developers] Limiting copies of cross posts sent In-Reply-To: <36B21E43.C8DD3DF6@ollie.clive.ia.us>; from Jeffrey C. Ollie on Fri, Jan 29, 1999 at 02:46:59PM -0600 References: <36B20B76.9D9955B0@ollie.clive.ia.us> <19990129144516.52367@amber.org> <36B21E43.C8DD3DF6@ollie.clive.ia.us> Message-ID: <19990129160254.59981@amber.org> On Fri, Jan 29, 1999 at 02:46:59PM -0600, Jeffrey C. Ollie wrote: > > * Sendmail only does this under SMTP, not under anything else > > Not if you add the 'm' flag to the delivery agent. Then sendmail will > invoke the delivery agent with multiple recipients specified on the > command line. Interesting, I've never seen this used for mailing lists, so I don't know what to say... obviously this is a sendmail only thing that gets into the whole problem outlined below. > > So, that means that Mailman would have to accept its messages over SMTP, > > which sin't in itself a problem... the problem is that as far as I've > > been able to determine, sendmail can't be told to deliver SMTP mail to a > > different port than 25. > > Actually you can, see p522 in the 2nd edition of _Sendmail_ (section > 30.4.1.2). I stand corrected, although I will point out that this is burried quite late in the sendmail world, and 5 people I know who relaly know sendmail didn't know this :-) Hense, it's obscure at best... Regardless... > > That's not nearly as ugly as the problems with doing it ... also it'd be > > different for every mailer, and quite different in many cases I think. > > Yes, existence of multiple SMTP daemons is a problem in that we'd have > to provide documentation on how to modify the configuration for many > different daemons. However doesn't this already happen? Aren't > sendmail, exim, qmail, or whatever sufficiently different in their > implementation that setup is already problematic? Dunno, at least with sendmail/postfix, it's just trivial additions to the /etc/aliases file. I use the same ones for postfix as you would for sendmail, absolutely, no exceptions. I THINK EXIM behaves the same way, and I think qmail does as well. This is trivially simple, it's also how every other mailer plugs into the MTA world. (Ialso run full blown LISTSERV). > Another, more radical idea would be to completely replace the regular > SMTP daemon with a SMTP daemon written in Python that integrates > directly with MailMan. I've been considering doing that for another, > more radical project that I have in mind. The only problem with this is > that you have to dedicate a box to running MailMan and there would be > some performace issues, but I guess that this would be offset by the > ability to run MailMan on a Windows or Mac OS system. I'm not sure this is a plus, considering I want a REALLY reliable system :-) I don't have a problem with someone writing a Python MTA (I've thought about it many times) BUT... mailman can't use it, at least in my opinion. Period. The MTA has to deal with /etc/aliases files just like everyone else, it's a defacto-standard at this point. > The idea of using a database to filter out multiple copies would be > problematic for sites that have high volume lists with a large > subscriber base. Just think of all of the storage that you'd need! Actually, locality of reference fixes this is MOST cases... that is, it's "safe" to assume for handwaving purposes that email originating from userA will reach mailserverB in x time... that is the same for all the different lists on X. So it's reasonably safe to assume that Mailman will see multiple copies almost simultaneously (i.e. no more than 5 minutes?). What this means is that you only have eto CACHE the Message-Id information, not keep it forever. And you're only keeping it for cross-posted messages also, not everything. I think this is totally doable, with a decent caching mechanism. (probably in C code, added to the normal Python distribution). Chris -- | Christopher Petrilli | petrilli@amber.org From claw@under.engr.sgi.com Fri Jan 29 22:20:03 1999 From: claw@under.engr.sgi.com (J C Lawrence) Date: Fri, 29 Jan 1999 14:20:03 -0800 Subject: [Mailman-Developers] Big lists In-Reply-To: Message from Balazs Nagy of "Fri, 29 Jan 1999 09:57:22 +0100." Message-ID: <199901292220.OAA73122@under.engr.sgi.com> On Fri, 29 Jan 1999 09:57:22 +0100 (CET) Balazs Nagy wrote: > Hiyas, How can I (we) set up mailman to handle big (with 25k or > more subscribers) lists? I'll chime in here with a variation: I'm chartered to start hosting a mailing list with 200K subscribers (yes, that's a fifth of a million) in the next few weeks. I would *like* to do it under Mailman (my current list server doesn't scale *that* well). Traffic will be low, probably under 20 inbound posts per day. My current small scale tests look good so far. Poking about the source looks _fair_, so far. Are there any known concerns? -- J C Lawrence Internet: claw@kanga.nu (Contractor) Internet: coder@kanga.nu ---------(*) Internet: claw@under.engr.sgi.com ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From cklempay@acm.jhu.edu Fri Jan 29 22:20:04 1999 From: cklempay@acm.jhu.edu (Corbett J. Klempay) Date: Fri, 29 Jan 1999 17:20:04 -0500 (EST) Subject: [Mailman-Developers] Big lists In-Reply-To: <199901292220.OAA73122@under.engr.sgi.com> Message-ID: Wow...what MTA are you planning on pairing with whatever list manager you go with? ------------------------------------------------------------------------------ Corbett J. Klempay Quote of the Week: http://www2.acm.jhu.edu/~cklempay "You shall judge of a man by his foes as well as by his friends." ------------------------------------------------------------------------------ On Fri, 29 Jan 1999, J C Lawrence wrote: > On Fri, 29 Jan 1999 09:57:22 +0100 (CET) > Balazs Nagy wrote: > > > Hiyas, How can I (we) set up mailman to handle big (with 25k or > > more subscribers) lists? > > I'll chime in here with a variation: > > I'm chartered to start hosting a mailing list with 200K > subscribers (yes, that's a fifth of a million) in the next few > weeks. I would *like* to do it under Mailman (my current list > server doesn't scale *that* well). Traffic will be low, probably > under 20 inbound posts per day. > > My current small scale tests look good so far. Poking about the > source looks _fair_, so far. Are there any known concerns? > > -- > J C Lawrence Internet: claw@kanga.nu > (Contractor) Internet: coder@kanga.nu > ---------(*) Internet: claw@under.engr.sgi.com > ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers > From claw@under.engr.sgi.com Fri Jan 29 22:40:10 1999 From: claw@under.engr.sgi.com (J C Lawrence) Date: Fri, 29 Jan 1999 14:40:10 -0800 Subject: [Mailman-Developers] Re: Please stop the cross posting In-Reply-To: Message from Ken Manheimer of "Fri, 29 Jan 1999 12:59:02 EST." Message-ID: <199901292240.OAA70390@under.engr.sgi.com> On Fri, 29 Jan 1999 12:59:02 -0500 (EST) Ken Manheimer wrote: > (Proper handling of the subject line prefix was one of the first > things i did - i'm pretty sure it was before 1.0b3, maybe 1.0b1. > If i recall correctly, i implemented a slightly more stringent > strategy, only looking for the prefix early on in the subject > line, after "re:"'s, but before other text. I know it takes care > of the vast majority of cases, and i suspect it's preferable more > of the time in offbeat cases than looking for the prefix anywhere > in the subject line, but i may be wrong. There are three common caxes: 1) User thinks he's being helpful and prepends his own tag. 2) Tag comes at start of Subject: or after some Re: or Fwd variation. 3) Tag occurs one or more times in Subject body due to hand edited subject (eg: Subject: XXX (was [tag] YYY) #1 is ignorable. #2 is slightly painful in the variations. eg Notes uses a "Re: #ddd" where the ddd's are a digital count of the number of replies made from Notes. #3 needs to be checked for and the (potentially multiple) instances of the tag need to be stripped I spent a while writing C code to do all of this (except for the Notes thing -- that's on the bug list), and can provide code samples as needed. -- J C Lawrence Internet: claw@kanga.nu (Contractor) Internet: coder@kanga.nu ---------(*) Internet: claw@under.engr.sgi.com ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From claw@under.engr.sgi.com Fri Jan 29 22:45:02 1999 From: claw@under.engr.sgi.com (J C Lawrence) Date: Fri, 29 Jan 1999 14:45:02 -0800 Subject: [Mailman-Developers] Big lists In-Reply-To: Message from "Corbett J. Klempay" of "Fri, 29 Jan 1999 17:20:04 EST." Message-ID: <199901292245.OAA59453@under.engr.sgi.com> On Fri, 29 Jan 1999 17:20:04 -0500 (EST) Corbett J Klempay wrote: > Wow...what MTA are you planning on pairing with whatever list > manager you go with? Exim -- its what I use already for my other mailing lists (typically half a million deliveries per day). -- J C Lawrence Internet: claw@kanga.nu (Contractor) Internet: coder@kanga.nu ---------(*) Internet: claw@under.engr.sgi.com ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... From markw@tabnet.com Sat Jan 30 00:12:41 1999 From: markw@tabnet.com (Mark Williamson) Date: Fri, 29 Jan 1999 16:12:41 -0800 Subject: [Mailman-Developers] removing entries from aliases References: <199901281700.MAA00373@python.org> Message-ID: <36B24E78.9565F6A7@tabnet.com> How difficult would it be to remove the entries from the /etc/aliases from when a list is removed via the rmlist command? Does anyone have code for this already? regards, Mark From petrilli@amber.org Sat Jan 30 02:32:42 1999 From: petrilli@amber.org (Christopher G. Petrilli) Date: Fri, 29 Jan 1999 21:32:42 -0500 Subject: [Mailman-Developers] removing entries from aliases In-Reply-To: <36B24E78.9565F6A7@tabnet.com>; from Mark Williamson on Fri, Jan 29, 1999 at 04:12:41PM -0800 References: <199901281700.MAA00373@python.org> <36B24E78.9565F6A7@tabnet.com> Message-ID: <19990129213242.08649@amber.org> On Fri, Jan 29, 1999 at 04:12:41PM -0800, Mark Williamson wrote: > How difficult would it be to remove the entries from the /etc/aliases from when a list is > removed via the rmlist command? Does anyone have code for this already? > Technically not that hard, assuming nobody touches the pieces that it inserts (if you copy them in manually)... BUT, it'd have to be really really really sure before I'd trust it. Honestly, I don't remove lists often enough for this to be a problem... but it's certainly something to think about... moreso just the overall add/delete Chris -- | Christopher Petrilli | petrilli@amber.org From gstein@lyra.org Sat Jan 30 02:59:54 1999 From: gstein@lyra.org (Greg Stein) Date: Fri, 29 Jan 1999 18:59:54 -0800 Subject: [Mailman-Developers] ZDNet mentions Mailman! Message-ID: <36B275AA.68472CBC@lyra.org> A little tidbit for your reading pleasure... http://www.zdnet.com/sr/stories/issue/0,4537,387506,00.html The mailman reference is about a third of the way down the article. -g -- Greg Stein, http://www.lyra.org/ From Harald.Meland@usit.uio.no Sun Jan 31 04:54:18 1999 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 31 Jan 1999 05:54:18 +0100 Subject: [Mailman-Developers] Limiting copies of cross posts sent In-Reply-To: "Christopher G. Petrilli"'s message of "Fri, 29 Jan 1999 16:02:54 -0500" References: <36B20B76.9D9955B0@ollie.clive.ia.us> <19990129144516.52367@amber.org> <36B21E43.C8DD3DF6@ollie.clive.ia.us> <19990129160254.59981@amber.org> Message-ID: [Christopher G. Petrilli] > On Fri, Jan 29, 1999 at 02:46:59PM -0600, Jeffrey C. Ollie wrote: > > Yes, existence of multiple SMTP daemons is a problem in that we'd have > > to provide documentation on how to modify the configuration for many > > different daemons. However doesn't this already happen? Aren't > > sendmail, exim, qmail, or whatever sufficiently different in their > > implementation that setup is already problematic? > > Dunno, at least with sendmail/postfix, it's just trivial additions to > the /etc/aliases file. I use the same ones for postfix as you would for > sendmail, absolutely, no exceptions. I THINK EXIM behaves the same > way, Once you've got the basic director and transport set up (in order to pipe things into mailman under the right UID/GID), all you need to do is add to an "aliases" file. However: If we try to communicate envelope recipients to the mailman pipe-alias command, we will have to do so in an MTA-specific way -- i.e. for the Exim case, one might do it in any of these ways: * Mailman can find the envelope recipient from the environment variables LOCAL_PART and DOMAIN. * Exim can invoke the Mailman pipe as /mail/wrapper post test $pipe_addresses * Exim can add an Envelope-To: header to all locally delivered mail, which Mailman then could use. None of these "solutions" would of course work for neither Sendmail, Qmail nor Postfix. IOW, we don't want to do that. Besides, even if a message is delivered in a single SMTP dialog with multiple RCPT To:s, the MTA will split the local deliveries up into one pipe delivery per envelope recipient. Thus Mailman _will_ need to keep some state between deliveries. My current ideas on limiting duplicates are: * Consider message headers unreliable. They are OK for collecting "hints" as to what lists a message _probably_ has been crossposted to, but it really should be the envelope recipients that make the call. * Mailman needs some way (heuristics could probably make do for now) of determining whether some header address does correspond to a (local) mailman list or not. * Whenever a message subject to duplicate removal gets injected into Mailman, register that message for "probable pending delivery" to the header addresses corresponding to local Mailman lists. * As the MTA runs the mailman pipes for the different envelope recipients, Mailman updates the "probable pending delivery" status for that list to say "pending delivery". * Depending on how well we want to utilize the "multiple RCPT To:" SMTP performance gain, Mailman could do either of A. As soon as a list gets status "pending delivery", ship the message off to the members of that list _that hasn't already received it_. Add all new addresses to some message.have_been_sent_to status variable. B. Add all members of the list to some message.to_be_delivered_to status variable, and wait for some time (se below) before starting actual delivery. * When either all the "probably pending delivery" addresses have been converted to "pending delivery" (plus, maybe, some small additional timeout to cater for any Bcc:ed list addresses?), or after some (site-configurable) timeout is reached, do the remaining pending deliveries, and garbage-collect the message status info. The "I don't want to receive multiple copies" option should be an user option, as I, for one, *would* like to receive multiple copies. Some additional features, e.g. "Mailman shouldn't deliver list messages to addresses already in the header" (leading to pretty decent support for the "I want to send a message to this list _minus_ these addresses" case :) could be nice for those that want them. > > Another, more radical idea would be to completely replace the regular > > SMTP daemon with a SMTP daemon written in Python that integrates > > directly with MailMan. I've been considering doing that for another, > > more radical project that I have in mind. The only problem with this is > > that you have to dedicate a box to running MailMan and there would be > > some performace issues, but I guess that this would be offset by the > > ability to run MailMan on a Windows or Mac OS system. > > I'm not sure this is a plus, considering I want a REALLY reliable system > :-) I don't have a problem with someone writing a Python MTA (I've > thought about it many times) BUT... mailman can't use it, at least in my > opinion. Period. The MTA has to deal with /etc/aliases files just like > everyone else, it's a defacto-standard at this point. Huh? Are you saying that there's problems with having the "usual" MTA deal with /etc/aliases, while the "Mailman/Python" MTA keeps its "aliases" elsewhere? This is the modus operandi of at least one other pretty widespread MLM package, namely Lyris (). -- Harald From gorgo@caesar.elte.hu Sun Jan 31 10:45:20 1999 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Sun, 31 Jan 1999 11:45:20 +0100 (MET) Subject: [Mailman-Developers] thousands of subscribers In-Reply-To: Message-ID: On 29 Jan 1999, Janne Sinkkonen wrote: > One thing is the subscriber list, visible for subscribers > themselves. It is linear, everything on one page and doesn't work well > for 25000 members. Another thing is the digest format which triggers a > sendmail MIME bug. Be sure to have sendmail 8.9.1 or newer, otherwise > you site will explode. :) Even if your sendmail works, you're going to > get annoyed messages from administrators of other sites who have an > older sendmail dumping core because of your digests. The sendmail MIME bug triggers only when your sendmail wants to send a 8bitmime mail to a remote smtp server which does not support 8bitmime, so your sendmail has to transform it... And in most cases the other sites sendmail won't dump core because probably it won't need to send them to a third host... Greg, who was bitten by the MIME problem severly... -- 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 stu@ekins.net Sun Jan 31 12:32:04 1999 From: stu@ekins.net (Stu Ekins) Date: Sun, 31 Jan 1999 12:32:04 -0000 Subject: [Mailman-Developers] removing entries from aliases Message-ID: <014201be4d15$b6fdf060$0e45fea9@fred> >On Fri, Jan 29, 1999 at 04:12:41PM -0800, Mark Williamson wrote: >> How difficult would it be to remove the entries from the /etc/aliases from when a list is >> removed via the rmlist command? Does anyone have code for this already? >Technically not that hard, assuming nobody touches the pieces that it >inserts (if you copy them in manually)... BUT, it'd have to be really >really really sure before I'd trust it. Honestly, I don't remove lists >often enough for this to be a problem... but it's certainly something to >think about... moreso just the overall add/delete I agree. Wouldn't it be a better idea to have a second aliases file that only mailman can modify, then have an alternative version of newaliases that concatenates the standard /etc/aliases and the mailman aliases together, before processing. That way, if it all goes pear shaped, your main aliases file is unaffected, only your mailman aliases get screwed, and if you have a backup version, you can recover. I'm sure I read somewhere about being able to do includes in alias files anyway, but I can't find the reference anyway. Or am I missing the point here? Stu. -- http://mobiles.ekins.net - Special offers on Nokia 9000 cases and personal numbers...