[issue7240] subprocess.Popen.stdout.flush fails os OS-X 10.6.1
Philip Jenvey pjen...@underboss.org added the comment: Why are you flushing stdout? It's read-only and flush is for writing. This behavior is dependent on the underlying platform's fflush, which really *should* be raising EBADF when fflushing a read only file, anyway -- nosy: +pjenvey ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7240 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7240] subprocess.Popen.stdout.flush fails os OS-X 10.6.1
Ned Deily n...@acm.org added the comment:
Philip is correct:
p.stdout.flush()
Traceback (most recent call last):
File stdin, line 1, in module
IOError: [Errno 9] Bad file descriptor
p.stdout
open file 'fdopen', mode 'rb' at 0x100527470
You'll get the same error on OS X (at least as far back as Python 2.3.5
on OS X 10.4) if you try to flush a disk read-only file:
f = open('a.txt', 'rb')
f.flush()
Traceback (most recent call last):
File stdin, line 1, in ?
IOError: [Errno 9] Bad file descriptor
Note, both the OS X and Linux 2.6 fflush(3) man pages clearly state that
EBADF can be returned if the stream is not open for writing but there
seems to be a difference in behavior between the two OS's.
As this doesn't seem to be a new issue and can easily be avoided (don't
flush a read-only file), I suggest closing the issue.
--
assignee: - ronaldoussoren
components: +Macintosh
nosy: +ned.deily, ronaldoussoren
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7240
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7241] tkinter fails to import
New submission from Jebagnanadasa jebagnana...@gmail.com: import _tkinter # If this fails your Python may not be configured for Tk I'm using python3 in linux. In windows tkinter is working fine but in mandriva linux spring 2009 it fails to import. Can you please tell me step-by-step on how to fix this issue? In python3.1 home page the description is not clear or it can't be understood by the beginner. As i'm a beginner for programming python in linux please help me out. I want to know what is the thing i missed during installation. I've done the things correctly as mentioned in the python readme text inside the python3.1 tarball file. While searching the net i found out that if i want to fix this issue i've to uninstall and install it again. what should i do now? -- components: Tkinter messages: 94697 nosy: python.noob severity: normal status: open title: tkinter fails to import type: resource usage versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7241 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Martin v. Löwis mar...@v.loewis.de added the comment: [...] As second step, I think that the CFLAGS environment variable passed to configure should be made to init the BASECFLAGS Makefile variable, since that's what the user would expect (if he knew how the system works). I still think that such a patch would be flawed, because it *still* wouldn't follow the standards used in other OSS software, where setting CFLAGS overrides *ALL* settings that configure may have come up with. So if a CFLAGS environment variables is to be considered, it needs to be considered correctly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1628484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7241] tkinter fails to import
Changes by Jebagnanadasa jebagnana...@gmail.com: -- status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7241 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7241] tkinter fails to import
Changes by Jebagnanadasa jebagnana...@gmail.com: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7241 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Marc-Andre Lemburg m...@egenix.com added the comment: Martin v. Löwis wrote: Martin v. Löwis mar...@v.loewis.de added the comment: [...] As second step, I think that the CFLAGS environment variable passed to configure should be made to init the BASECFLAGS Makefile variable, since that's what the user would expect (if he knew how the system works). I still think that such a patch would be flawed, because it *still* wouldn't follow the standards used in other OSS software, where setting CFLAGS overrides *ALL* settings that configure may have come up with. So if a CFLAGS environment variables is to be considered, it needs to be considered correctly. Fair enough, then let's do that. If we go down that road, we'd have to remove BASECFLAGS, OPT and EXTRA_CFLAGS and replace it with the single standard CFLAGS variable, or use an approach similar to the one taken for CPPFLAGS (ie. we allow these extra variables to further customize a CFLAGS setting): CPPFLAGS= @BASECFLAGS@ @OPT@ @EXTRA_CFLAGS@ @CFLAGS@ FWIW, the reason behind the extra variables is not really clear. They only appear to factor out different aspects of the same thing: r38847 | bcannon | 2005-04-25 00:26:38 +0200 (Mon, 25 Apr 2005) | 6 lines Introduced EXTRA_CFLAGS as an environment variable used by the Makefile. Meant to be used for flags that change binary compatibility. r30490 | montanaro | 2003-01-01 21:07:49 +0100 (Wed, 01 Jan 2003) | 10 lines Split OPT make variable into OPT and BASECFLAGS. The latter contains those compiler flags which are necessary to get a clean compile. The former is for user-specified optimizer, debug, trace fiddling. See patch 640843. BTW: I've checked the use of LDFLAGS - this is added to LDSHARED on Mac OS X, FreeBSD, OpenBSD and NetBSD. Perhaps this is something special needed on BSDish system ?! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1628484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7242] Forking in a thread raises RuntimeError
New submission from Zsolt Cserna zsolt.cse...@morganstanley.com: Python 2.6.4 (r264:75706, Oct 29 2009, 12:00:12) [C] on sunos5 On my sunos5 system if I call os.fork() in a thread created by thread.start_new_thread(), it raises RuntimeError with the message 'not holding the import lock'. It's a vanilla python compiled on sunos5 with suncc. In 2.6.3 it's ok, I think this issue is caused by patch located at http://codereview.appspot.com/96125/show. The problem can be re-produced by running the script attached. I've looked into the source and it seems to me the following: Based on the the change above, it calls fork1() system call between a lock-release calls: 3635 » _PyImport_AcquireLock(); 3636 » pid = fork1(); 3637 » result = _PyImport_ReleaseLock(); _PyImport_ReleaseLock is called in both the child and parent. Digging more into the code, _PyImport_ReleaseLock starts with the following: long me = PyThread_get_thread_ident(); if (me == -1 || import_lock == NULL) return 0; /* Too bad */ if (import_lock_thread != me) return -1; In the above code, if I interpret correctly, it compares the result of the current thread id returned by PyThread_get_thread_ident call with the thread id of the thread holding the lock - if it's different then the current thread cannot release the lock because it's not owned by it. Based on my results on solaris the 'me' variable will be different in the parent and in the child (in parent it remains the same) - resulting that the child thinks that it's not holding the release lock. I'm using pthreads on both linux and solaris. On linux the code above is working fine, but on solaris it behaves differently. -- components: Library (Lib) files: thread_test.py messages: 94701 nosy: csernazs severity: normal status: open title: Forking in a thread raises RuntimeError type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file15232/thread_test.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7242 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7242] Forking in a thread raises RuntimeError
Antoine Pitrou pit...@free.fr added the comment: Well, there has been no such change between 2.6.3 and 2.6.4. -- nosy: +gregory.p.smith, pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7242 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Marc-Andre Lemburg m...@egenix.com added the comment: [Adding Jack Jansen to the nosy list, since he added the LDFLAGS parts for Mac OS X] Jack, could you please comment on why the LDFLAGS are added to LDSHARED by configure, rather than using LDFLAGS as extra argument to LDSHARED ? Thanks. -- nosy: +jackjansen ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1628484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7242] Forking in a thread raises RuntimeError
Zsolt Cserna zsolt.cse...@morganstanley.com added the comment: Sorry, the working version is not 2.6.3 (I mistyped the version), it's 2.6.1 (I've no info about 2.6.2). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7242 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7240] subprocess.Popen.stdout.flush fails os OS-X 10.6.1
Peter Gibson peteh...@gmail.com added the comment: Not my code, but as it's using a pipe to communicate with another process, I assume that the flush call is intended to discard any unwanted output prior to sending a command and processing the result. Is there another way to achieve the same effect, such as reading and remaining characters in the buffer? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7240 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7228] %lld for PyErr_Format (Modules/_io/bufferedio.c)
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp added the comment: No, I don't have it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7228 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7243] mac binary download link for 2.6.4 broken
New submission from Jonathan Beard jt.be...@gmail.com: the mac binary download link for python 2.6.4 is broken: http://python.org/ftp/python/2.6.4/python-2.6.4-macosx.dmg -- components: Installation messages: 94708 nosy: beard severity: normal status: open title: mac binary download link for 2.6.4 broken type: resource usage versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5582] Incorrect DST transition
acummings acummi...@aperiogroup.com added the comment: OK, it works correctly on 2.6.4: time.localtime(time.mktime(datetime(2009, 10, 30).timetuple())) time.struct_time(tm_year=2009, tm_mon=10, tm_mday=30, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=4, tm_yday=303, tm_isdst=1) I'll close it. Thanks! -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5582 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Bob Atkins b...@digilink.net added the comment: I see that Martin's broken record still hasn't changed. I had warm, nostalgic feelings as I re-read this thread. It is so sad to see that this matter remains unresolved almost 3 years after I filed this bug. As usual Martin is just flat wrong in his insistence that a defined CFLAGS must overide any generated CFLAGS by configure to be consistent with other OSS. But of course that is just his excuse for not accepting this bug and fix. If it wasn't this assertion then he would find something else equally absurd. Does anyone know the meaning of NIH? I'll bet that this matter will never be resolved until the Python community simply takes Python and re-hosts it somewhere else as OpenPython. As long as Martin is the gatekeeper you can be assured that this bug (or any bug) that he doesn't agree with will never be accepted or fixed and if he does accept this bug - he will insist on doing it the wrong way (by overriding CFLAGS) to prove he was 'right' all along - that this bug fix will break more than it fixes. Keep up the good work Martin. I am expecting that this bug will continue to provide me with nostalgic memories well into my retirement... ;-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1628484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4359] at runtime, distutils uses buildtime files
Dave Malcolm dmalc...@redhat.com added the comment:
For Fedora, I've fixed this (I hope) by special-casing those two files:
%{_libdir}/python%{pybasever}/config/Makefile
/usr/include/python2.6/pyconfig-{32|64}.h
making them part of the core python package.
See downstream bug here:
https://bugzilla.redhat.com/show_bug.cgi?id=531901
(BTW, downstream, we rename pyconfig.h and generate a stub that #includes
either pyconfig-
32/64 so that both 32 and 64-bit devel packages can be installed on 32-bit
hosts; we patch
distutils so that it parses the wordlength-specific file)
--
nosy: +dmalcolm
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4359
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4359] at runtime, distutils uses buildtime files
Dave Malcolm dmalc...@redhat.com added the comment: For Fedora, I've fixed this (I hope) by special-casing those two files: Sorry; for fixed, read addressed; this covers part 1 of the issue, but not part 2. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4359 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Antoine Pitrou pit...@free.fr added the comment: Martin isn't the gatekeeper, it's just that few people are really motivated in solving tedious configuration-related problems, especially when there are diverging concerns (legacy, habits, compatibility, etc.) to take into account. That said, I think the current CFLAGS situation is counter-intuitive and would deserve being fixed. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1628484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Jörg Prante joergpra...@gmx.de added the comment: [...] because it *still* wouldn't follow the standards used in other OSS software, where setting CFLAGS overrides *ALL* settings that configure may have come up with. Martin, can you please elaborate on this? I never heard of such standards in OSS. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1628484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Marc-Andre Lemburg m...@egenix.com added the comment: Bob Atkins wrote: As usual Martin is just flat wrong in his insistence that a defined CFLAGS must overide any generated CFLAGS by configure to be consistent with other OSS. But of course that is just his excuse for not accepting this bug and fix. If it wasn't this assertion then he would find something else equally absurd. I don't think so... we have to support multiple platforms and doing so is rather difficult in the light of different requirements and often missing ability to actually test on the various platforms. The configure/make system we have in Python has grown a lot over the years and many people have contributed to it. As a result, it's not as clean as it could be and there are many aspects that require inside knowledge about the platforms. Martin is right in saying that a CFLAGS environment variable has to override the value determined by configure... see e.g. http://www.gnu.org/software/hello/manual/autoconf/Preset-Output-Variables.html However, the situation is a little more complex: CFLAGS should normally *not* be used by the Makefile for things that configure finds or regards as not user customizable. Unfortunately, Python's Makefile does not work that way. It builds its own CFLAGS value out of a combination of other variables. It should really be building a new variable based on CFLAGS and the other variables and then use that in the build process. The PY_CFLAGS variable appears to be a start in that direction, though it's not being followed through. What makes the situation even more complex is that C extensions built with distutils will also use these variables for compilation, so any changes to the way the variables work will have direct effect on whether or not extensions build out of the box. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1628484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7222] thread reaping is imperfect
Antoine Pitrou pit...@free.fr added the comment: Committed in r75958, r75959. -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7222 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7243] mac binary download link for 2.6.4 broken
Changes by Ned Deily n...@acm.org: -- nosy: +barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7243] mac binary download link for 2.6.4 broken
Changes by Barry A. Warsaw ba...@python.org: -- assignee: - barry priority: - high resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7243] mac binary download link for 2.6.4 broken
Jonathan Beard jt.be...@gmail.com added the comment: Link still broken? see screenshot http://www.python.org/ftp/python/2.6.4/python-2.6.4-macosx.dmg -- status: closed - open Added file: http://bugs.python.org/file15233/python mac binary url 404.png ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7243] mac binary download link for 2.6.4 broken
Jonathan Beard jt.be...@gmail.com added the comment: Included screenshot of page which has the bad url: http://www.python.org/download/ -- Added file: http://bugs.python.org/file15234/download page.png ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7243] mac binary download link for 2.6.4 broken
R. David Murray rdmur...@bitdance.com added the comment: You probably just need to force your browser to refresh the web page. The link works for me (but does not point to the ftp url you specify). -- nosy: +r.david.murray status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7243] mac binary download link for 2.6.4 broken
Changes by R. David Murray rdmur...@bitdance.com: -- stage: - committed/rejected type: resource usage - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7243] mac binary download link for 2.6.4 broken
Jonathan Beard jt.be...@gmail.com added the comment: might have been upstream cache. works for me now. thanks! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32
Changes by R. David Murray rdmur...@bitdance.com: -- keywords: +buildbot ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4970 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6462] bsddb3 intermittent test failures
Changes by R. David Murray rdmur...@bitdance.com: -- keywords: +buildbot ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6462 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3892] bsddb: test01_basic_replication fails on Windows sometimes
Changes by R. David Murray rdmur...@bitdance.com: -- keywords: +buildbot ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3892 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4698] Solaris buildbot failure on trunk in test_hostshot
Changes by R. David Murray rdmur...@bitdance.com: -- keywords: +buildbot ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4698 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
R. David Murray rdmur...@bitdance.com added the comment: Does anyone know what version of FreeBSD the FreeBSD buildslave is running? This problem is affecting most of its runs. -- keywords: +buildbot nosy: +r.david.murray versions: +Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3864 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
Eric Smith e...@trueblade.com added the comment: http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%20trunk reports: FreeBSD 6.2-RELEASE (VMWare Image, 256MB, 10GB on P4/1.8GHz Host) -- nosy: +eric.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3864 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Bob Atkins b...@digilink.net added the comment: 3 years and counting while everyone rings their hands and debates this trivial issue. 3 years and counting while hundreds of builders encounter this problem wasting countless of hours troubleshooting, possibly re-reporting the problem. Software is not a religion - but many software developers believe it is. This issue could have been solved 3 years ago and more time spent on other issues that really matter. Or you can spend the next 3 years debating the fanatically correct way to solve this problem. My money is that the fanatically 'correct' method will be implemented that will require hundreds of lines of code, possibly re-engineering the entire build process, introducing more problems and take a few more years to implement and release. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1628484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
R. David Murray rdmur...@bitdance.com added the comment: Since this is apparently a known FreeBSD bug, we should put a conditional skip into test_signal. -- components: +Tests stage: - needs patch type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3864 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Marc-Andre Lemburg m...@egenix.com added the comment: Bob Atkins wrote: My money is that the fanatically 'correct' method will be implemented that will require hundreds of lines of code, possibly re-engineering the entire build process, introducing more problems and take a few more years to implement and release. Well, I guess that's not your problem anymore... you have your patch and it works for you and perhaps a few others as well. That's fine for the time being. Without knowing the impact of the generic approach you've taken in your patch we simply cannot just apply it. If you can prove that the patch doesn't break other platforms or configuration setups, that would help a lot. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1628484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7230] test_hotshot fails on solaris
Antoine Pitrou pit...@free.fr added the comment: Duplicate of #4698. -- nosy: +pitrou resolution: - duplicate status: open - closed superseder: - Solaris buildbot failure on trunk in test_hostshot ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7230 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Jack Jansen jackjan...@users.sourceforge.net added the comment: Jack, could you please comment on why the LDFLAGS are added to LDSHARED by configure, rather than using LDFLAGS as extra argument to LDSHARED ? Because this worked, no deep reason. The initial framework builds were a big hack, because they were neither static nor shared builds (because the extensions were linked against the framework), so I had to find something that worked while hoping I wouldn't break too much on other platforms. In case anyone is interested in my opinion: I would scratch the whole configure/make suite and rebuild it from scratch. As others here have noticed, the OPT/EXTRA_CFLAGS pattern that Python adhered to has lost out the the CFLAGS/LDFLAGS pattern, and more such things. And this is important if people want to do recursive builds. But: it's a major undertaking to get this working, especially if you don't want to pull in libtool:-( -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1628484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Jörg Prante joergpra...@gmx.de added the comment: Without knowing the impact of the generic approach you've taken in your patch we simply cannot just apply it. If you can prove that the patch doesn't break other platforms or configuration setups, that would help a lot. I was able to build Python 2.5 on Solaris 10 Sparc, Mac OS X PPC, Linux PPC/Intel, all 32bit and 64bit, shared and static, only with Bob's help. It's not a proof. It's not mathematical correct. But it works. Grab all your avalaible test platforms and try for yourself what Bob's patch will 'break', and report it. Sorry, but that meta discussions about correct builds are not what a bug report should be used for. Such improvements are up to developer forums where you can design correct Python build scripts and discuss them over and over again. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1628484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5510] patches for Modules/socketmodule.c for NetBSD
Thomas Klausner t...@giga.or.at added the comment: Attached is the patch fixing this problem from pkgsrc; it was written by Iain Hibbert plu...@netbsd.org who also maintains BlueTooth in NetBSD, so I'm very confident it's right :) Please include it! -- nosy: +wiz Added file: http://bugs.python.org/file15235/patch-ap ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5510 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Peter N spacey-bugs.python@ssr.com added the comment: On Fri, Oct 30, 2009 at 09:31:38PM +, J??rg Prante wrote: J??rg Prante joergpra...@gmx.de added the comment: Without knowing the impact of the generic approach you've taken in your patch we simply cannot just apply it. If you can prove that the patch doesn't break other platforms or configuration setups, that would help a lot. I was able to build Python 2.5 on Solaris 10 Sparc, Mac OS X PPC, Linux PPC/Intel, all 32bit and 64bit, shared and static, only with Bob's help. Ditto for python 2.5 on Solaris 10 x86 64-bit. It was simply impossible without these patches. It's not a proof. It's not mathematical correct. But it works. Grab all your avalaible test platforms and try for yourself what Bob's patch will 'break', and report it. Sorry, but that meta discussions about correct builds are not what a bug report should be used for. Such improvements are up to developer forums where you can design correct Python build scripts and discuss them over and over again. Agreed. +1 from me if it counts for anything (which it probably doesn't). -Peter -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1628484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Antoine Pitrou pit...@free.fr added the comment: First, the current patch doesn't apply cleanly to trunk. The following patch should be ok (some of the changes of the original patch apparently have been committed separately in the meantime). Second, the patch allows me to do a 32-bit build (under 64-bit Linux) by doing: CFLAGS=-m32 LDFLAGS=-m32 ./configure rather than: CC=gcc -m32 ./configure However, if I omit LDFLAGS it doesn't work, I don't know if it's intended. Third, while the 32-bit build does work, the shared objects are still placed in a directory called lib.linux-x86_64-2.7, which I suppose is wrong: $ ./python Python 2.7a0 (trunk:75966:75967M, Oct 30 2009, 22:55:18) [GCC 4.3.2] on linux2 Type help, copyright, credits or license for more information. import _socket _socket.__file__ '/home/antoine/cpython/__svn__/build/lib.linux-x86_64-2.7/_socket.so' $ file /home/antoine/cpython/__svn__/build/lib.linux-x86_64-2.7/_socket.so /home/antoine/cpython/__svn__/build/lib.linux-x86_64-2.7/_socket.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped -- keywords: +patch Added file: http://bugs.python.org/file15236/Makefile.pre.in.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1628484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7210] Proposed Syntax Checks in Test Suite
Benjamin Peterson benja...@python.org added the comment: See how all the other tests in test_grammar are written in a unittest style? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Roumen Petrov bugtr...@roumenpetrov.info added the comment: Marc-Andre, Thanks for the reference but what about to open manual for AC_PROG_CC ? Antoine, please don't mess kind of cross compilation into this thread. About patches: Change of libdir are subject to other requests - require changes in distutils - out of scope. About CFLAGS : To ignore options like -g -O2 set by AC_PROG_CC just enclose macro in py_save_CFLAGS ... CFLAGS=$py_save_CFLAGS. Тhe python build system use own options OPT to set -g -O3 and etc. Please see comments in configure for OPT. About LDFLAGS with passing to setup.py (last place without it) is good to remove all other references as I do in other issue . I won't update my patch to apply cleanly to trunk if there is no interest. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1628484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Marc-Andre Lemburg m...@egenix.com added the comment:
Antoine Pitrou wrote:
Second, the patch allows me to do a 32-bit build (under 64-bit Linux) by
doing:
CFLAGS=-m32 LDFLAGS=-m32 ./configure
rather than:
CC=gcc -m32 ./configure
However, if I omit LDFLAGS it doesn't work, I don't know if it's intended.
Without the patch,
BASECFLAGS=-m32 LDFLAGS=-m32 ./configure
should work the same way.
LDFLAGS defines the linker options, CFLAGS the compiler options,
and since both tools have to know that you're generating 32-bit code,
you have to pass the option to both env vars.
Third, while the 32-bit build does work, the shared objects are still
placed in a directory called lib.linux-x86_64-2.7, which I suppose is
wrong:
That's a side-effect of distutils using os.uname() for determining
the platform. It doesn't know that you're actually telling the
compiler to build a 32-bit binary.
On some platforms you can use these commands to emulate 32- or
64-bit environments:
$ linux32 python -c 'import os; print os.uname()'
('Linux', 'newton', '2.6.22.19-0.4-default', '#1 SMP 2009-08-14 02:09:16
+0200', 'i686')
$ linux64 python -c 'import os; print os.uname()'
('Linux', 'newton', '2.6.22.19-0.4-default', '#1 SMP 2009-08-14 02:09:16
+0200', 'x86_64')
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1628484
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Antoine Pitrou pit...@free.fr added the comment: Antoine, please don't mess kind of cross compilation into this thread. This is not cross-compilation, a 32-bit binary will run fine on a x86-64 system. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1628484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Marc-Andre Lemburg m...@egenix.com added the comment: Roumen Petrov wrote: Roumen Petrov bugtr...@roumenpetrov.info added the comment: Marc-Andre, Thanks for the reference but what about to open manual for AC_PROG_CC ? Could you please elaborate a bit ? Antoine, please don't mess kind of cross compilation into this thread. That was just an example of how CFLAGS can be used. However, with the patch you still don't get complete control of the C compiler flags - which is what the env var should be all about. The reason is that the actually used CFLAGS argument then becomes a combination of these env vars/settings: CFLAGS= $(BASECFLAGS) @CFLAGS@ $(OPT) $(EXTRA_CFLAGS) To regain control over CFLAGS, you'd have to define these env vars: CFLAGS, BASECFLAGS, OPT, EXTRA_CFLAGS That's not really how it should be... (see the autoconf reference URL I posted). About patches: Change of libdir are subject to other requests - require changes in distutils - out of scope. True. About CFLAGS : To ignore options like -g -O2 set by AC_PROG_CC just enclose macro in py_save_CFLAGS ... CFLAGS=$py_save_CFLAGS. Тhe python build system use own options OPT to set -g -O3 and etc. Please see comments in configure for OPT. In the early days we only allowed customization of the optimization settings when compiling Python, nothing more. That's where OPT originated. Things started to get complicated when the recursive make process was flattened starting in Python 2.1. About LDFLAGS with passing to setup.py (last place without it) is good to remove all other references as I do in other issue . I won't update my patch to apply cleanly to trunk if there is no interest. Could you provide an issue number ? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1628484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Marc-Andre Lemburg m...@egenix.com added the comment: Jack Jansen wrote: Jack Jansen jackjan...@users.sourceforge.net added the comment: Jack, could you please comment on why the LDFLAGS are added to LDSHARED by configure, rather than using LDFLAGS as extra argument to LDSHARED ? Because this worked, no deep reason. The initial framework builds were a big hack, because they were neither static nor shared builds (because the extensions were linked against the framework), so I had to find something that worked while hoping I wouldn't break too much on other platforms. Well, it does break on Mac OS X (and only there) now, since for universal builds, the Mac gcc complains if you pass in the -sysroot option more than once :-) I was under the impression that the -bundle option was needed as last linker option and that this was the reason for adding LDFLAGS directly into LDSHARED. But if there are no deep reasons, then I'd suggest to not add LDFLAGS to LDSHARED anymore and instead just use it normally. In case anyone is interested in my opinion: I would scratch the whole configure/make suite and rebuild it from scratch. As others here have noticed, the OPT/EXTRA_CFLAGS pattern that Python adhered to has lost out the the CFLAGS/LDFLAGS pattern, and more such things. And this is important if people want to do recursive builds. Even though we do have a flat Makefile now, there still is some recursion left: Python uses distutils to build most of the included C extension modules. Part of the patch targets exactly this recursion: LDFLAGS is currently not being passed on to the shared mod build sub-process. But: it's a major undertaking to get this working, especially if you don't want to pull in libtool:-( What if we just remove all the extra cruft and just use CFLAGS ? LDFLAGS is not such a mess. It just needs to be propagated to all parts of the process. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1628484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Roumen Petrov bugtr...@roumenpetrov.info added the comment: Mark issue is 4010 (see message #msg94686 above) . About the control of the flags :) ... the Bob's post ... method will be implemented that will require hundreds of lines of code ... is true. Order $(BASECFLAGS) @CFLAGS@ $(OPT) $(EXTRA_CFLAGS) look good as first start with project CFLAGS followed by env. CFLAGS and why will read README file for OPT and EXTRA_CFLAGS ? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1628484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5596] memory leaks in py3k
Antoine Pitrou pit...@free.fr added the comment: After quite a bit of work, here is the new status as of r75970: test_textwrap leaked [0, -206] references, sum=-206 test_urllib leaked [2, 0] references, sum=2 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5596 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5596] memory leaks in py3k
R. David Murray rdmur...@bitdance.com added the comment: And there was much rejoicing :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5596 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1739118] Investigated ref leak report related to thread regrtest.py
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp added the comment: This issue seems to be fixed in r75958. -- resolution: - duplicate status: open - closed superseder: - memory leaks in py3k ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1739118 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7210] Proposed Syntax Checks in Test Suite
Changes by Chuck Rhode crh...@lacusveris.com: Removed file: http://bugs.python.org/file15231/test_grammar.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7210] Proposed Syntax Checks in Test Suite
Chuck Rhode crh...@lacusveris.com added the comment: Oh! That's very different. :-) I can do that. -- Added file: http://bugs.python.org/file15237/test_grammar_trunk.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7210] Proposed Syntax Checks in Test Suite
Benjamin Peterson benja...@python.org added the comment: Applied with some changes in r75971. -- resolution: - accepted status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7195] Value error 'path is on drive c: start on drive d:' in os.path.relpath
Nick Coghlan ncogh...@gmail.com added the comment: It's not the current directory that's the problem, it's the current drive. Windows has no absolute root directory - instead, it has a root directory for each drive. That means that \\dir is a path relative to the current drive rather than an absolute path. You need to put the drive letter in there to make it an absolute path. That's just a fact of life when working with the windows file system, rather than anything specific to Python or os.path.relpath. -- nosy: +ncoghlan resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7195 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
