[issue6720] multiprocessing logging

Éric Araujo added the comment: This is either out of date (2.5 doesn’t get bugfixes any more) or invalid (concerns a backport of multiprocessing outside of the stdlib). -- nosy: +eric.araujo resolution: -> rejected stage: -> committed/rejected status: open -> closed type: crash -> be

[issue6720] multiprocessing logging

Jesse Noller added the comment: The backport of multiprocessing is currently stale; and there are a few bugs in the tracker assigned to christian or myself in regards to it. If it's not too much trouble, I'd leave this one alone until the exact future of the backport can be resolved. ---

[issue6720] multiprocessing logging

Terry J. Reedy added the comment: As far as I know, the only 2.5 issues that will get fixed are security issues, and this is not marked as such. So the question for Christian is whether this is an exception. Or is this even an issue for this tracker? -- __

[issue6720] multiprocessing logging

Benjamin Liles added the comment: I don't think it has been fixed yet. -- status: pending -> open ___ Python tracker ___ ___ Python-bu

[issue6720] multiprocessing logging

Terry J. Reedy added the comment: May this be closed as out-of-date? -- nosy: +tjreedy status: open -> pending ___ Python tracker ___

[issue6720] multiprocessing logging

Jesse Noller added the comment: Christian is managing the back port. -- assignee: jnoller -> christian.heimes nosy: +christian.heimes ___ Python tracker ___ _

[issue6720] multiprocessing logging

Changes by Vinay Sajip : -- assignee: -> jnoller nosy: +jnoller ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue6720] multiprocessing logging

New submission from Benjamin Liles : In the backport package of the multiprocessing library. A bug was introduced in version 2.6.2.1 when the logging module was modified. If you use logging in the backport, you get the following: Traceback (most recent call last): File "/Library/Frameworks/Pyt