Mailman 3 December 2002 - Mailman-Developers

[ mailman-Patches-651406 ] MM 2.0.13 to 2.1b5 upgrade fails
by noreply＠sourceforge.net 10 Dec '02

10 Dec '02

Patches item #651406, was opened at 2002-12-10 12:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=651406&group_i… Category: None Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Richard Barrett (ppsys) Assigned to: Nobody/Anonymous (nobody) Summary: MM 2.0.13 to 2.1b5 upgrade fails Initial Comment: make install when updating a MM 2.0.13 installation to 2.1b5 initally produced the following exception: Updating mailing list: mailman Traceback (most recent call last): File "bin/update", line 569, in ? errors = main() File "bin/update", line 446, in main errors = errors + dolist(listname) File "bin/update", line 186, in dolist mlist = MailList.MailList(listname, lock=0) File "/mailman/run/Mailman/MailList.py", line 101, in __init__ self.Load() File "/mailman/run/Mailman/MailList.py", line 600, in Load self.CheckValues() File "/mailman/run/Mailman/MailList.py", line 650, in CheckValues for name, pattern, desc, emptyflag in self.topics: File "/mailman/run/Mailman/MailList.py", line 130, in __getattr__ raise AttributeError, name AttributeError: topics make: *** [update] Error 1 Having corrected the cause of this first exception the following exception was then encountered: Upgrading from version 0x2000df0 to 0x20100b5 getting rid of old source files Updating mailing list: mailman Traceback (most recent call last): File "bin/update", line 569, in ? errors = main() File "bin/update", line 446, in main errors = errors + dolist(listname) File "bin/update", line 200, in dolist for addr, (reason, when) in mlist.delivery_status.items (): File "/mailman/run/Mailman/MailList.py", line 130, in __getattr__ raise AttributeError, name AttributeError: delivery_status make: *** [update] Error 1 These problems both seem to arise because of the following: 1. The MailList class is derived from the classes TopicMgr and Bouncer (amongst others). 2. The MailList __init__ function calls the __init__ functions of its superclasses if they have that function; which they do not in the case of the of TopicMgr and Bouncer classes 3. The MailList __init__ function calls its own InitTempVars function which in turn calls the InitTempVars functions of MailList's superclasses if they have that function; which they do not in the case of the of class TopicMgr and Bouncer classes 4. The MailList __init__ function does not call the InitVars functions of the TopicMgr and Bouncer classes which is why self.topics and self.delivery_status are undefined attributes of the MailList instance being created; these being instance variables introduced by MM 2.1b5 and missing from MM 2.0.13 instance of the MailList class which is what is being dealt with at the time the update is being done. Adding the following definition to the TopicMgr and Bouncer class definitions seem to clear the problem although whether this is the best log-tem solution is questionable: InitTempVars = InitVars ---------------------------------------------------------------------- >Comment By: Richard Barrett (ppsys) Date: 2002-12-10 14:19 Message: Logged In: YES user_id=75166 The problem is a by product of the 413752 (coerce to plaintext) patch for MM 2.0.13 (mailman-2.0.13-plaintext- 0.17.patch) which had been applied to the existing system Patch 413752 for MM 2.0.13 changes Version.py as follows: # config.db schema version number -DATA_FILE_VERSION = 21 +DATA_FILE_VERSION = (21, 'plaintext_patch') In MM 2.1b5 Version.py DATA_FILE_VERSION = 88 In the CheckVersion member function of the MailList class the following comparison succeeds, i.e. the existing data structure is seen as being a later revision than MM 2.1b5, when patch 413752 has been applied: if self.data_version >= mm_cfg.DATA_FILE_VERSION: and the CheckVersion function returns without calling the InitVars function to preset the instance variables to the defaults before loading the pickled data values for an existing list. Changing the comparisom to this solves the problem: if (type(self.data_version) is type (mm_cfg.DATA_FILE_VERSION) and \ self.data_version >= mm_cfg.DATA_FILE_VERSION) or \ (type(self.data_version) is type(()) and \ self.data_version[0] >= mm_cfg.DATA_FILE_VERSION): ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-12-10 13:13 Message: Logged In: YES user_id=75166 I was wrong about my hack working because on using the web admin GUI to update lists I got the error feedback given below. The problem seems to be more deep seated in that the InitVars function of the MailList class does not seem to get called to initialse the MailList instance variables when loading an existing list via the __init__ function but only through the Create member function called from newlist and cgi create.py. At first blush I would think that MailList InitVars function should be called from the class' __init__ function before loading an existing instance's data into the instance variables; but with three functions initialisation functions, __init__, InitTempVars and InitVars, I'm getting confused as to which are supposed to do what and when. Bug in Mailman version 2.1b5 We're sorry, we hit a bug! If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks! Traceback: Traceback (most recent call last): File "/mailman/run/scripts/driver", line 87, in run_main main() File "/mailman/run/Mailman/Cgi/admin.py", line 76, in main i18n.set_language(mlist.preferred_language) File "/mailman/run/Mailman/MailList.py", line 130, in __getattr__ raise AttributeError, name AttributeError: preferred_language ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=651406&group_i…

1 0

[ mailman-Patches-651406 ] MM 2.0.13 to 2.1b5 upgrade fails
by noreply＠sourceforge.net 10 Dec '02

10 Dec '02

Patches item #651406, was opened at 2002-12-10 12:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=651406&group_i… Category: None Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Richard Barrett (ppsys) Assigned to: Nobody/Anonymous (nobody) Summary: MM 2.0.13 to 2.1b5 upgrade fails Initial Comment: make install when updating a MM 2.0.13 installation to 2.1b5 initally produced the following exception: Updating mailing list: mailman Traceback (most recent call last): File "bin/update", line 569, in ? errors = main() File "bin/update", line 446, in main errors = errors + dolist(listname) File "bin/update", line 186, in dolist mlist = MailList.MailList(listname, lock=0) File "/mailman/run/Mailman/MailList.py", line 101, in __init__ self.Load() File "/mailman/run/Mailman/MailList.py", line 600, in Load self.CheckValues() File "/mailman/run/Mailman/MailList.py", line 650, in CheckValues for name, pattern, desc, emptyflag in self.topics: File "/mailman/run/Mailman/MailList.py", line 130, in __getattr__ raise AttributeError, name AttributeError: topics make: *** [update] Error 1 Having corrected the cause of this first exception the following exception was then encountered: Upgrading from version 0x2000df0 to 0x20100b5 getting rid of old source files Updating mailing list: mailman Traceback (most recent call last): File "bin/update", line 569, in ? errors = main() File "bin/update", line 446, in main errors = errors + dolist(listname) File "bin/update", line 200, in dolist for addr, (reason, when) in mlist.delivery_status.items (): File "/mailman/run/Mailman/MailList.py", line 130, in __getattr__ raise AttributeError, name AttributeError: delivery_status make: *** [update] Error 1 These problems both seem to arise because of the following: 1. The MailList class is derived from the classes TopicMgr and Bouncer (amongst others). 2. The MailList __init__ function calls the __init__ functions of its superclasses if they have that function; which they do not in the case of the of TopicMgr and Bouncer classes 3. The MailList __init__ function calls its own InitTempVars function which in turn calls the InitTempVars functions of MailList's superclasses if they have that function; which they do not in the case of the of class TopicMgr and Bouncer classes 4. The MailList __init__ function does not call the InitVars functions of the TopicMgr and Bouncer classes which is why self.topics and self.delivery_status are undefined attributes of the MailList instance being created; these being instance variables introduced by MM 2.1b5 and missing from MM 2.0.13 instance of the MailList class which is what is being dealt with at the time the update is being done. Adding the following definition to the TopicMgr and Bouncer class definitions seem to clear the problem although whether this is the best log-tem solution is questionable: InitTempVars = InitVars ---------------------------------------------------------------------- >Comment By: Richard Barrett (ppsys) Date: 2002-12-10 13:13 Message: Logged In: YES user_id=75166 I was wrong about my hack working because on using the web admin GUI to update lists I got the error feedback given below. The problem seems to be more deep seated in that the InitVars function of the MailList class does not seem to get called to initialse the MailList instance variables when loading an existing list via the __init__ function but only through the Create member function called from newlist and cgi create.py. At first blush I would think that MailList InitVars function should be called from the class' __init__ function before loading an existing instance's data into the instance variables; but with three functions initialisation functions, __init__, InitTempVars and InitVars, I'm getting confused as to which are supposed to do what and when. Bug in Mailman version 2.1b5 We're sorry, we hit a bug! If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks! Traceback: Traceback (most recent call last): File "/mailman/run/scripts/driver", line 87, in run_main main() File "/mailman/run/Mailman/Cgi/admin.py", line 76, in main i18n.set_language(mlist.preferred_language) File "/mailman/run/Mailman/MailList.py", line 130, in __getattr__ raise AttributeError, name AttributeError: preferred_language ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=651406&group_i…

1 0

[ mailman-Patches-651406 ] MM 2.0.13 to 2.1b5 upgrade fails
by noreply＠sourceforge.net 10 Dec '02

10 Dec '02

Patches item #651406, was opened at 2002-12-10 12:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=651406&group_i… Category: None Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Richard Barrett (ppsys) Assigned to: Nobody/Anonymous (nobody) Summary: MM 2.0.13 to 2.1b5 upgrade fails Initial Comment: make install when updating a MM 2.0.13 installation to 2.1b5 initally produced the following exception: Updating mailing list: mailman Traceback (most recent call last): File "bin/update", line 569, in ? errors = main() File "bin/update", line 446, in main errors = errors + dolist(listname) File "bin/update", line 186, in dolist mlist = MailList.MailList(listname, lock=0) File "/mailman/run/Mailman/MailList.py", line 101, in __init__ self.Load() File "/mailman/run/Mailman/MailList.py", line 600, in Load self.CheckValues() File "/mailman/run/Mailman/MailList.py", line 650, in CheckValues for name, pattern, desc, emptyflag in self.topics: File "/mailman/run/Mailman/MailList.py", line 130, in __getattr__ raise AttributeError, name AttributeError: topics make: *** [update] Error 1 Having corrected the cause of this first exception the following exception was then encountered: Upgrading from version 0x2000df0 to 0x20100b5 getting rid of old source files Updating mailing list: mailman Traceback (most recent call last): File "bin/update", line 569, in ? errors = main() File "bin/update", line 446, in main errors = errors + dolist(listname) File "bin/update", line 200, in dolist for addr, (reason, when) in mlist.delivery_status.items (): File "/mailman/run/Mailman/MailList.py", line 130, in __getattr__ raise AttributeError, name AttributeError: delivery_status make: *** [update] Error 1 These problems both seem to arise because of the following: 1. The MailList class is derived from the classes TopicMgr and Bouncer (amongst others). 2. The MailList __init__ function calls the __init__ functions of its superclasses if they have that function; which they do not in the case of the of TopicMgr and Bouncer classes 3. The MailList __init__ function calls its own InitTempVars function which in turn calls the InitTempVars functions of MailList's superclasses if they have that function; which they do not in the case of the of class TopicMgr and Bouncer classes 4. The MailList __init__ function does not call the InitVars functions of the TopicMgr and Bouncer classes which is why self.topics and self.delivery_status are undefined attributes of the MailList instance being created; these being instance variables introduced by MM 2.1b5 and missing from MM 2.0.13 instance of the MailList class which is what is being dealt with at the time the update is being done. Adding the following definition to the TopicMgr and Bouncer class definitions seem to clear the problem although whether this is the best log-tem solution is questionable: InitTempVars = InitVars ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=651406&group_i…

1 0

Re: [Mailman-Developers] Exim tweak
by J C Lawrence 10 Dec '02

10 Dec '02

On Mon, 9 Dec 2002 23:36:47 -0800 Marc MERLIN <marc_news(a)merlins.org> wrote: > On Mon, Dec 09, 2002 at 08:00:25PM -0800, J C Lawrence wrote: >> Not a bad side effect for a little idle poking about. > Indeed, it will increase overall throughput. However, you are > sacrificing turnaround time to several minutes or more as a result, > and this from mere seconds with mm 2.1 (for that matter, with some of > my lists, when I save my message in vim, by the time I get back to the > mutt index, the message has been sent, processed by the MTA, handed > out to mailman, which exploded it and sent it back to my mailbox, so > my message shows up in my index in the half second that it took mutt > to come back from vim and rescan my mailbox Yup. > If you ask me, that's pretty cool :-) I can stand that pain, easily, especially as I generally moderate only once or twice a day. Adding a few minutes to a process which averages a more than 6 hour latency is hardly expensive. > Now, I'm curious: In your case, you get bursts of messages with lots > of subscribers on your list. Yup, the largest burst I've played with to day this way was 20,000 spool entries in one slam (I killed SMTP deliveries until qrunner had finished injecting into the MTA). It didn't quite drain proportionally to the number of subscribers, but it wasn't a long way off either. > How about a list server with many lists so that you always have 50 to > 100 exims running and trying to clean the queue, deliver mail, or > talking to mailman... In that case (i.e. really loaded server), I'm > not convinced that spooling everything to disk and having exim process > the message on the next queue run is going to be that much more > effective. Is it? I expect that the efficiency *could* be maintained. There are quite a few variables. (I've spent a lot more time tuning Postfix than I have Exim) It depends on the distribution of the destination MX's (how much repetition across your lists thus incurring parallel delivery), how much of the default state of the "loaded mail server" is really repetitious delivery attempts to slow MX'es (which defines your background sustained load), the size of the message bursts (in terms of number of messages prior to moderation, thus defining known parallel delivery opportunities), the rate of MTA queue runner passes (defining windows of opportunity for parallel deliveries), and the time required to inject a burst into the MTA (which thus has a defined intersection rate with the MTA queue runners). The ___apparent___ critical bit is to get all (or most/much of) the burst injected into the MTA before it starts delivering it and then having a large number of moderated messages thus being able to take advantage of parallel delivery and reduce the total delivery time down to (optimally) linearly proportional to the number of subscribers. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

1 0

Exim tweak
by J C Lawrence 10 Dec '02

10 Dec '02

As an experiment in analysing my system loads I added the following to my exim.conf: # When this option is set, a delivery process is started whenever a # message is received, directing and routing is performed, and local # deliveries take place. However, if any SMTP deliveries are # required for domains that match queue_smtp_domains, they are not # immediately delivered, but instead the message waits on the queue # for the next queue run. Since routing of the message has taken # place, Exim knows to which remote hosts it must be delivered, and # so when the queue run happens, multiple messages for the same host # are delivered over a single SMTP connection. This option is # checked against the domains supplied in the incoming addresses, # before any widening is done (because that is part of routing). The # -odqs command line option causes all SMTP deliveries to be queued # in this way, and is equivalent to setting queue_smtp_domains to # *'. See also queue_remote_domains, which is subtly different. queue_smtp_domains = "*" Note that all of my lists are hand moderated resulting in outbound mail occurring in batches, typically in the range of 5K - 10K MTA spool entries per batch. The primary effect of adding this config item is that (in general) a compleat moderation batch is enqueued by the MTA before delivery attempts start on any of the component messages. This turns out to have a significant effect on delivery time performance. Loosely what seems to be happening is that without the above config Exim and Mailman's qrunner end up competing for CPU resources, with system loads climbing into the 30's and 40's with parallel deliveries to the same MX being infrequent to the point of nonexistence. [1] However with the above config Exim has the opportunity to batch all mail targeted to a given MX and parallel deliveries are the default. [2] This shows clearly in the logs with blocks of deliveries to the same MX all together. The apparent result of this batching is that the total delivery time [3] for a moderation batch is now reduced by a factor of almost 5. [3] Not a bad side effect for a little idle poking about. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. 1) I use 20 queue runners with up to 10 parallel deliveries per MX. 2) I have low rates of duplicate MX use in my subscriber base. AOL + MSN + Hotmail together form less than 3% of my subscriber base. Outside of resource contention this low collision rate is the prime factor in parallel deliveries not happening. 3) Loosely defining total delivery time as the taken to handle all deliveries to all fast MX'es (no errors, warnings, or responses taking more than a second). 4) This depends heavily on whether Mailman's qrunner can get the compleat moderation queue dumped to the MTA before it starts another queue run. Typically for my setup I can get ~4K spool entries queued between MTA queue runs. I *should* be able to get at least an order of magnitude more, and almost two (as determined by trivial test code doing a canned loop). I haven't yet analysed why the qrunner path is so slow and am unlikely to before I deploy v2.1. However as a general observation Mailman v2.0's qrunner seems absurdly slow in iterating across the membership roster and dumping RCPT TO bundles to the MTA.

3 2

[ mailman-Bugs-651146 ] make distclean forgets some Makefiles
by noreply＠sourceforge.net 09 Dec '02

09 Dec '02

Bugs item #651146, was opened at 2002-12-09 23:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=651146&group_i… Category: configuring/installing Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Matthias Juchem (brightice) Assigned to: Nobody/Anonymous (nobody) Summary: make distclean forgets some Makefiles Initial Comment: Hi. mailman/messages/Makefile and mailman/tests/*/Makefile do not get cleaned up when doing a 'make distclean'. Patch 645421 should fix this, see patch description. Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=651146&group_i…

1 0

[ mailman-Bugs-650932 ] 'Administator' typos
by noreply＠sourceforge.net 09 Dec '02

09 Dec '02

Bugs item #650932, was opened at 2002-12-09 10:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=650932&group_i… Category: Web/CGI Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: 'Administator' typos Initial Comment: 'rgrep -i administator' (missing the R after the first T) turns up a number of places where this typo occurs; some of them are still present in the 2.1b6 running on python.org. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=650932&group_i…

1 0

Unable to install 2.1b5 on RedHat 7.3
by Liam Routt 09 Dec '02

09 Dec '02

I'm new to the list (although I've been using 2.0x for a while now). I'm trying to install 2.1b5 on a RedHat 7.3 system, and having no luck. Some pertinent info: RedHat 7.3 i386 Comes with python 1.5.2 installed also installed python2 (python 2.2) Have qmail installed in place of sendmail (although sendmail rpm is in place) The error I'm getting is one I have seen mention of before in the archives: Compiling /home/mailman/Mailman/versions.py ... Traceback (most recent call last): File "bin/update", line 44, in ? import paths File "bin/paths.py", line 55, in ? import japanese ImportError: No module named japanese The solution was supposed to have to do with setting the permissions pythonlib and its contents, I believe. I fiddled around trying to make sure that was being done, but noticed that pythonlib was empty. That ends up being the actual problem I'm having. The packages which are supposed to be in pythonlib are not put there. The reason is buried back in the earlier part of the installation (and I don't have the output to hand at the moment). In short, the misc/Makefile.in (where the packages are to be installed and the permissons set correctly) is unable to recognize my python installation. At first I was leaving things as they installed on my machine, with python 1.5.2 in the path as "python" and using the --with-python directive to point to "python2". When I worked out what was going wrong I mv'd python out of the way and put a link to "python2" from "python" and tried again, but it had the same effect (ie it was unable to recognize the python 2.2 installation). After that I put python 1.5.2 back where it belonged and tried the installation without the --with-python, and that had the same results. What I recall is that it was looking for a particular file (a config file of some sort) in a directory that does exist. The file is not there, although a lot of other python packages and files are. Things to consider: 1. The failure did not halt the install, although it did make it impossible for it to complete. But the relevant messages were *way* back, and probably meaningless to a non-technical person, at a guess. 2. How should mailman recognize this python 2.2 installation as used in RedHat 7.3 (and earlier, at least). Without removing my older python (which there are a lot of apparent dependencies on) and installing from the src, I can't see any other way to get python 2.2 easily installed. 3. Any suggestions what I should try? Take care, Liam -- Liam Routt liam(a)routt.net Darcsyde Productions http://www.routt.net/Caligari/ -- still waiting for the Absolute Destiny Apocalypse --

1 1

[ mailman-Bugs-650711 ] add_members fails with specific address
by noreply＠sourceforge.net 09 Dec '02

09 Dec '02

Bugs item #650711, was opened at 2002-12-09 06:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=650711&group_i… Category: command line scripts Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Cabel Sasser (cabelsa) Assigned to: Nobody/Anonymous (nobody) Summary: add_members fails with specific address Initial Comment: I am migrating from one list system to another, and in the process of doing so I'm importing tens of thousands of addresses using the command-line add_members utility. Bug: add_members reproducibly crashes when it gets to the following obviously invalid e-mail address in the text file I'm importing from: ----(a)---.--- Here is the error message: [...] Traceback (most recent call last): File "/usr/local/mailman/bin/add_members", line 297, in ? main() File "/usr/local/mailman/bin/add_members", line 274, in main addall(mlist, nmembers, 0, send_welcome_msg, s) File "/usr/local/mailman/bin/add_members", line 173, in addall except MMHostileAddress: NameError: global name 'MMHostileAddress' is not defined If I remove the above dash-tastic address, the add_members import succeeds. I hope this helps! Mailman totally rocks! :) ---------------------------------------------------------------------- >Comment By: Cabel Sasser (cabelsa) Date: 2002-12-09 06:24 Message: Logged In: YES user_id=665207 BTW, this is 2.0b5. Sorry for not mentioning that above. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=650711&group_i…

1 0

[ mailman-Bugs-650711 ] add_members fails with specific address
by noreply＠sourceforge.net 09 Dec '02

09 Dec '02

Bugs item #650711, was opened at 2002-12-09 06:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=650711&group_i… Category: command line scripts Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Cabel Sasser (cabelsa) Assigned to: Nobody/Anonymous (nobody) Summary: add_members fails with specific address Initial Comment: I am migrating from one list system to another, and in the process of doing so I'm importing tens of thousands of addresses using the command-line add_members utility. Bug: add_members reproducibly crashes when it gets to the following obviously invalid e-mail address in the text file I'm importing from: ----(a)---.--- Here is the error message: [...] Traceback (most recent call last): File "/usr/local/mailman/bin/add_members", line 297, in ? main() File "/usr/local/mailman/bin/add_members", line 274, in main addall(mlist, nmembers, 0, send_welcome_msg, s) File "/usr/local/mailman/bin/add_members", line 173, in addall except MMHostileAddress: NameError: global name 'MMHostileAddress' is not defined If I remove the above dash-tastic address, the add_members import succeeds. I hope this helps! Mailman totally rocks! :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=650711&group_i…

1 0