upgrading results in duplicate Python files ?
I recently upgraded both Python (1.52 -> 2.0) and Mailman (2.0b5 -> 2.0) and now appear to have duplicate python files in the 'Mailman' directory. (Mac OSXS 1.2)
ex: aliases.py aliases.pyc Bouncer.py Bouncer.pyc etc.
Does anyone know what the '.pyc' files are and if it is safe to simply remove them? THanks for any suggestions.
. . . . . . . . . . . Michael Dunston Music and Technology http://www.music.vt.edu Virginia Tech School of the Arts
Dear Everyone: I installed mailman in one computer, and using the MTA(qmail) which runs on another computer, after I created a new list,how to add the list of aliases generated? for example: I add one line into the /etc/aliases of MTA server spt: "|/home/mailman/mail/wrapper post spt" but how can MTA find "|/home/mailman/mail/wrapper "?
thanks in advance.
Tonny.
Tonny Liu wrote:
Dear Everyone: I installed mailman in one computer, and using the MTA(qmail) which runs on another computer, after I created a new list,how to add the list of aliases generated? for example: I add one line into the /etc/aliases of MTA server spt: "|/home/mailman/mail/wrapper post spt" but how can MTA find "|/home/mailman/mail/wrapper "?
Well, pretty obviously, the MTA has to be able to forward to the host actually running Mailman. How about making the aliases say "spt: spt@mailman-host", and then have mailman-host run an incoming MTA only?
Thank you, Dan Mick. I encountered another problem: It looks to me that /home/mailman/mail/wrapper didn't run well in my server.
I excute the following command:
"/home/mailman/mail/wrapper mailowner first"
I found a message in mail log file:
"Mailman mail-wrapper: Failure to exec script. WANTED gid 12, GOT gid 508. (Reconfigure to take 508?)."
In my server, gid of group "mail" is 12.
and the usr executed the above command is a member of the group whose id is 508.
BTW, the mode of wrapper is "-rwxr-sr-x".
could you or any one else tell me why? thanks very much...
----- Original Message ----- From: "Dan Mick" <Dan.Mick@west.sun.com> To: "Tonny Liu" <liu.dongsheng@etang.net>; <mailman-users@python.org> Sent: Saturday, December 30, 2000 3:16 AM Subject: Re: [Mailman-Users] how to configure aliases in two server?
Tonny Liu wrote:
Dear Everyone: I installed mailman in one computer, and using the MTA(qmail) which runs on another computer, after I created a new list,how to add the list of aliases generated? for example: I add one line into the /etc/aliases of MTA server spt: "|/home/mailman/mail/wrapper post spt" but how can MTA find "|/home/mailman/mail/wrapper "?
Well, pretty obviously, the MTA has to be able to forward to the host actually running Mailman. How about making the aliases say "spt: spt@mailman-host", and then have mailman-host run an incoming MTA only?
Michael Dunston wrote:
I recently upgraded both Python (1.52 -> 2.0) and Mailman (2.0b5 -> 2.0) and now appear to have duplicate python files in the 'Mailman' directory. (Mac OSXS 1.2)
ex: aliases.py aliases.pyc Bouncer.py Bouncer.pyc etc.
?? They're not duplicates at all; both their names and contents (and sizes, and creation times) are different. Why would you think they're "duplicate"?
The .pyc files are compiled versions of Python code, and have existed in every Mailman and Python version you've used; you just haven't noticed them until now. They're created by the "compile all files" step of "make install", and recreated automagically by the Python interpreter if they don't exist when you run the code in a .py file.
"MD" == Michael Dunston <mdunston@music.vt.edu> writes:
MD> I recently upgraded both Python (1.52 -> 2.0) and Mailman
MD> (2.0b5 -> 2.0) and now appear to have duplicate python files
MD> in the 'Mailman' directory. (Mac OSXS 1.2)
MD> ex: aliases.py
| aliases.pyc
| Bouncer.py
| Bouncer.pyc
| etc.
MD> Does anyone know what the '.pyc' files are and if it is safe
MD> to simply remove them? THanks for any suggestions.Sorry if someone else has already answered this (my email is still in a pitiful state).
Short answer: leave them alone, they're normal for Python.
.pyc' files contain the Python bytecodes compiled from a corresponding .py' Python source file. When Python imports a module,
and it finds the module in a .py file that is newer than the
corresponding .pyc file (or if the .pyc file doesn't exist yet), it
byte-compiles the code, and caches the bytecodes in the .pyc file.
That way, subsequent imports of that module are much faster -- they
don't have to run through the compiler. All this happens
automatically so you don't have to worry about it.
Removing them won't help you because Python will just regenerate them.
Little known fact 1: .pyc files are actually Python marshals of code objects, plus 8 bytes of leading magic (version numbers, magic numbers, etc.).
Little known fact 2: There are also .pyo files which are optimized bytecode caches, generated when Python is run with the -O option.
ain't-guido-clever?-ly y'rs, -Barry
Cron question...why would I need for cron to retry failed deliveries once per minute? Do any of you keep this setting as is? It's filling up my cron log big time.
Thanks for the input.
-Matt
Matt Thoene wrote:
Cron question...why would I need for cron to retry failed deliveries once per minute?
Well, to answer the question you asked explicitly: so the failed deliveries get changed into successful deliveries. For the question you didn't ask: virtually all mail is sent by qrunner from cron, so cron is a necessary part of sending mail at all, much less failed deliveries.
Do any of you keep this setting as is? It's filling up my cron log big time.
Ah, so *maybe* you're asking "why does it need to be so frequent"? See above: any list mail will wait until qrunner sends it. Doesn't need to be "each minute" if you don't mind delays on list posts. Note that I often run qrunner by hand, too, to flush something out immediately; perhaps that model is more appropriate for some announce-only lists or the like.
As for "cron logs"...is this really a worry? I've got about a megabyte in log and olog on Solaris. A megabyte is ignorable in these days of "20GB is entry-level" disks.
Anyway, if it's a problem, you can turn off cron logging, too.
participants (5)
-
barry＠digicool.com -
Dan Mick -
Matt Thoene -
Michael Dunston -
Tonny Liu