[issue6546] [Distutils][PATCH] Add bdist_rpm option to select the name of the resulting package
OG7 ony...@users.sourceforge.net added the comment: In most cases, a distribution named foo becomes and rpm named python-foo, so it can't be the same name for both. I'm using bdist_rpm to generate rpms from eggs I didn't write myself, so an option to give external control works best. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6546 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6615] multiprocessing logging support test
New submission from OG7 ony...@users.sourceforge.net: There is an additional test for multiprocessing's logging support here: http://code.google.com/p/python-multiprocessing/issues/detail?id=18 (disregard the fix, it is only needed for the backport). -- components: Library (Lib) messages: 91163 nosy: OG7, jnoller severity: normal status: open title: multiprocessing logging support test type: behavior versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6615 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6546] [Distutils][PATCH] Add bdist_rpm option to select the name of the resulting package
New submission from OG7 ony...@users.sourceforge.net: This simple Distutils patch allows choosing the name of the rpm built by bdist_rpm. It leaves the name of the source tarball alone, and changes the name of the resulting spec file and rpm. It was tested with distutils nightlies, and applies to at least python 2.5 through 2.7dev . -- assignee: tarek components: Distutils files: 0001-Add-bdist_rpm-option-to-select-the-name-of-the-resul.patch keywords: patch messages: 90814 nosy: OG7, tarek severity: normal status: open title: [Distutils][PATCH] Add bdist_rpm option to select the name of the resulting package type: feature request versions: Python 2.7 Added file: http://bugs.python.org/file14537/0001-Add-bdist_rpm-option-to-select-the-name-of-the-resul.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6546 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5870] subprocess.DEVNULL
Changes by OG7 ony...@users.sourceforge.net: -- nosy: +OG7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5870 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6445] Add check parameter to subprocess.Popen.communicate
New submission from OG7 ony...@users.sourceforge.net: communicate is often used in one-liners, but becomes a four-liner if you want to check the process exit status. Adding a check parameter would make it more convenient to get things right and write non-buggy code. The CalledProcessError requires a cmd argument, which means also adding a cmd member to Popen objects. -- messages: 90318 nosy: OG7 severity: normal status: open title: Add check parameter to subprocess.Popen.communicate ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6445 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5313] multiprocessing.process using os.close(sys.stdin.fileno) instead of sys.stdin.close()
OG7 ony...@users.sourceforge.net added the comment: Please do this: --- a/multiprocessing/process.py +++ b/multiprocessing/process.py @@ -225,7 +225,8 @@ class Process(object): self._children = set() self._counter = itertools.count(1) try: -os.close(sys.stdin.fileno()) +sys.stdin.close() +sys.stdin = open(os.devnull) except (OSError, ValueError): pass _current_process = self One shouldn't close the fileno after the file has been closed. The stdlib raises an error, and the open(os.devnull) won't be reached. If no error was thrown, it would be worse. This would be closing a fileno that doesn't belong to sys.stdin anymore and may be used somewhere else. The open(os.devnull) bit is both so that no one tries to do anything with the old stdin anymore, and to let applications attempt to read from stdin without an IOError. -- Added file: http://bugs.python.org/file14320/0001-Fix-issue-5313.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5313 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5331] multiprocessing hangs when Pool used within Process
OG7 ony...@users.sourceforge.net added the comment: It seems the root cause is at http://bugs.python.org/issue5155 . A workaround is to use a duplex Pipe in SimpleQueue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5331 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5313] multiprocessing.process using os.close(sys.stdin.fileno) instead of sys.stdin.close()
OG7 ony...@users.sourceforge.net added the comment: Using sys.stdin.close() fixes issues 5155 and 5331. -- nosy: +OG7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5313 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5155] Multiprocessing.Queue created by sub-process fails when used in sub-sub-process (bad file descriptor in q.get())
OG7 ony...@users.sourceforge.net added the comment: Issue 5313 seems to be the culprit. -- nosy: +OG7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5155 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5313] multiprocessing.process using os.close(sys.stdin.fileno) instead of sys.stdin.close()
OG7 ony...@users.sourceforge.net added the comment:
Closing the stdin fd without closing the stdin file is very dangerous.
It means that stdin will now access some random resource, for example, a
pipe created with os.pipe().
Closing stdin is useful to let the parent be alone in reading from it.
It can be achieved by replacing stdin by open('/dev/null'). The original
stdin can be closed or left to be garbage collected.
The double flush case is impossible to handle in general. It's the
libc's responsibility for standard file objects and sockets. But it
can't be helped (except by putting a warning in the documentation) if
someone combines multiprocessing with non-fork-safe code that keeps its
own buffers and doesn't check for a pid change.
So that code in _bootstrap should be:
sys.stdin.close()
sys.stdin = open(os.devnull)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5313
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
