[ python-Bugs-764493 ] test test_nis crashed -- nis.error: no such key in map
Bugs item #764493, was opened at 2003-07-02 12:09 Message generated for change (Comment added) made by mmokrejs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764493&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Demos and Tools Group: Python 2.3 Status: Closed Resolution: None Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Nobody/Anonymous (nobody) Summary: test test_nis crashed -- nis.error: no such key in map Initial Comment: I always ignored this test error, but maybe you want to fix this: test test_nis crashed -- nis.error: no such key in map $ ./python Lib/test/test_nis.py nis.maps() group.bygid.tmp mail.aliases n.strack strack Traceback (most recent call last): File "Lib/test/test_nis.py", line 24, in ? if nis.match(k, nismap) != v: nis.error: no such key in map $ I believe this might be some misconfiguration of NIS on thsi host(we use it on other machines, but it should not be enabled on this particular machine). But, when I do "ypcat mail.aliases", I do not see a line with "n.strack strack". Maybe more debug trace would help to find what's going on. -- >Comment By: Martin Mokrejs (mmokrejs) Date: 2006-03-06 10:21 Message: Logged In: YES user_id=696559 Unfortunately I do not have an access to that machine running Tru64Unix 5.1. I tried to reproduce on Linux i686 with python-2.4.2 with no luck (that means NIS is not set up and the test correctly complains there is no NIS configured): $ ./python Lib/test/test_nis.py nis.maps() Traceback (most recent call last): File "Lib/test/test_nis.py", line 10, in ? raise TestFailed, msg test.test_support.TestFailed: No NIS master found for any map $ -- Comment By: SourceForge Robot (sf-robot) Date: 2006-03-06 04:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-19 16:10 Message: Logged In: YES user_id=1188172 Does this error persist in Python 2.4? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764493&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1444104 ] os.open() Documentation
Bugs item #1444104, was opened at 2006-03-06 13:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1444104&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Thomas Guettler (guettli) Assigned to: Nobody/Anonymous (nobody) Summary: os.open() Documentation Initial Comment: Hi, I think the note in the docu could be improved: """To read a ``file object'' returned by the built-in function open() or by popen() or fdopen(), or sys.stdin, use its read() or readline() methods.""" (I think) a better note: """To read a ``file object'' returned by the built-in function open(), popen(), fdopen() or sys.stdin, use its read() or readline() methods. You can convert the file descriptor returned by os.open() to a file object with [LINK os.fdopen()]""" The same note is used for os.write(). At os.open() there should be a link to os.fdopen(), too. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1444104&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1439659 ] file to store pickled object should be opened in binary mode
Bugs item #1439659, was opened at 2006-02-27 09:51 Message generated for change (Comment added) made by draghuram You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1439659&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Raghuram Devarakonda (draghuram) Assigned to: Nobody/Anonymous (nobody) Summary: file to store pickled object should be opened in binary mode Initial Comment: Hi, To unpickle objects on UNIX that were pickled on windows, the file should be opened in binary mode for read and write on windows. It will be nice to have this mentioned in the doc. Something along these lines will be good enough: "Please note that if you are writing the pickled object to a file on windows, make sure it is opened in binary mode. Otherwise, the file may not be able to be used to unpickle on other non-windows platforms". Thanks, Raghu. -- >Comment By: Raghuram Devarakonda (draghuram) Date: 2006-03-06 10:11 Message: Logged In: YES user_id=984087 Hi, The point is that even if ASCII protocol is used on windows(as I was), the unpickling process would fail on windows. So the pickle file should be opened in binary mode on windows even for ASCII protocol. This may make reading the file in notepad difficult but then, cross platform support should take precedence, I suppose. Another option would be for python to do line end translations for ASCII pickle files. Raghu. -- Comment By: Terry J. Reedy (tjreedy) Date: 2006-03-05 22:36 Message: Logged In: YES user_id=593130 For ASCII protocol pickles, intended for human readability, one should use text mode to be able to read the file, for instance, in Notepad. For either binary protocol, I would think binary mode should be best even to reread on Windows. If anything is added, I would put "On Windows, open files in a mode (text/binary) that matches the protocol." at the bottom of http://docs.python.org/lib/node64.html Looking forward to 3.0, when file mode might be more significant (text/binary corresponding to unicode/bytes), the "for windoews' qualifier might be omitted, but this might be premature. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1439659&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1439659 ] file to store pickled object should be opened in binary mode
Bugs item #1439659, was opened at 2006-02-27 09:51 Message generated for change (Comment added) made by draghuram You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1439659&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Raghuram Devarakonda (draghuram) Assigned to: Nobody/Anonymous (nobody) Summary: file to store pickled object should be opened in binary mode Initial Comment: Hi, To unpickle objects on UNIX that were pickled on windows, the file should be opened in binary mode for read and write on windows. It will be nice to have this mentioned in the doc. Something along these lines will be good enough: "Please note that if you are writing the pickled object to a file on windows, make sure it is opened in binary mode. Otherwise, the file may not be able to be used to unpickle on other non-windows platforms". Thanks, Raghu. -- >Comment By: Raghuram Devarakonda (draghuram) Date: 2006-03-06 10:12 Message: Logged In: YES user_id=984087 There seems to be a mistane in my earlier comment. I meant the unpickling on *UNIX* fails even if ASCII was used on windows. Raghu. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2006-03-06 10:11 Message: Logged In: YES user_id=984087 Hi, The point is that even if ASCII protocol is used on windows(as I was), the unpickling process would fail on windows. So the pickle file should be opened in binary mode on windows even for ASCII protocol. This may make reading the file in notepad difficult but then, cross platform support should take precedence, I suppose. Another option would be for python to do line end translations for ASCII pickle files. Raghu. -- Comment By: Terry J. Reedy (tjreedy) Date: 2006-03-05 22:36 Message: Logged In: YES user_id=593130 For ASCII protocol pickles, intended for human readability, one should use text mode to be able to read the file, for instance, in Notepad. For either binary protocol, I would think binary mode should be best even to reread on Windows. If anything is added, I would put "On Windows, open files in a mode (text/binary) that matches the protocol." at the bottom of http://docs.python.org/lib/node64.html Looking forward to 3.0, when file mode might be more significant (text/binary corresponding to unicode/bytes), the "for windoews' qualifier might be omitted, but this might be premature. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1439659&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1439659 ] file to store pickled object should be opened in binary mode
Bugs item #1439659, was opened at 2006-02-27 09:51 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1439659&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Raghuram Devarakonda (draghuram) Assigned to: Nobody/Anonymous (nobody) Summary: file to store pickled object should be opened in binary mode Initial Comment: Hi, To unpickle objects on UNIX that were pickled on windows, the file should be opened in binary mode for read and write on windows. It will be nice to have this mentioned in the doc. Something along these lines will be good enough: "Please note that if you are writing the pickled object to a file on windows, make sure it is opened in binary mode. Otherwise, the file may not be able to be used to unpickle on other non-windows platforms". Thanks, Raghu. -- >Comment By: Terry J. Reedy (tjreedy) Date: 2006-03-06 14:03 Message: Logged In: YES user_id=593130 Any text file written with /r/n in Windows can have problems when read on *nix or Mac or ???, so this problem is not specific to pickle or even to Python. I am under the impression that the new universal newline support was intended to fix such problems (when used). But as a Win- only user (currently) I have no experience with it. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2006-03-06 10:12 Message: Logged In: YES user_id=984087 There seems to be a mistane in my earlier comment. I meant the unpickling on *UNIX* fails even if ASCII was used on windows. Raghu. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2006-03-06 10:11 Message: Logged In: YES user_id=984087 Hi, The point is that even if ASCII protocol is used on windows(as I was), the unpickling process would fail on windows. So the pickle file should be opened in binary mode on windows even for ASCII protocol. This may make reading the file in notepad difficult but then, cross platform support should take precedence, I suppose. Another option would be for python to do line end translations for ASCII pickle files. Raghu. -- Comment By: Terry J. Reedy (tjreedy) Date: 2006-03-05 22:36 Message: Logged In: YES user_id=593130 For ASCII protocol pickles, intended for human readability, one should use text mode to be able to read the file, for instance, in Notepad. For either binary protocol, I would think binary mode should be best even to reread on Windows. If anything is added, I would put "On Windows, open files in a mode (text/binary) that matches the protocol." at the bottom of http://docs.python.org/lib/node64.html Looking forward to 3.0, when file mode might be more significant (text/binary corresponding to unicode/bytes), the "for windoews' qualifier might be omitted, but this might be premature. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1439659&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1423082 ] lib-deprecated
Feature Requests item #1423082, was opened at 2006-02-02 19:20 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1423082&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Closed Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: lib-deprecated Initial Comment: obsolete modules are moved to lib-old. deprecated modules remain in the library. This makes the search for a relevant library more difficult. People browsing the code may not realize that they are deprecated. (Example, I found no notice of deprecation within the code for rfc822.) Even when the notice is there, the modules add to the number of alternatives, which hurts One-Obvious-Way-To-Do-It. If these modules were moved to a deprecated directory, these problems would be greatly reduced. (Ensure backwards compatibility by leaving the deprecated directory on the search path.) -- >Comment By: Jim Jewett (jimjjewett) Date: 2006-03-06 14:26 Message: Logged In: YES user_id=764593 Reading the docs is not a bad thing, but they aren't always convenient when developing, and the code itself should be correct too. Moving them out of the standard library (and possibly the idlelib module search) will make them less of an attractive nuisance; at the least, it will save people the effort of looking them up and then backing out. -- Comment By: SourceForge Robot (sf-robot) Date: 2006-03-03 22:23 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-17 07:03 Message: Logged In: YES user_id=1188172 I think it's common practise to add a DeprecationWarning to those modules which are deprecated since one or two releases. That should be enough reminder. You should be reading the docs anyway :) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1423082&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1439659 ] file to store pickled object should be opened in binary mode
Bugs item #1439659, was opened at 2006-02-27 09:51 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1439659&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Raghuram Devarakonda (draghuram) Assigned to: Nobody/Anonymous (nobody) Summary: file to store pickled object should be opened in binary mode Initial Comment: Hi, To unpickle objects on UNIX that were pickled on windows, the file should be opened in binary mode for read and write on windows. It will be nice to have this mentioned in the doc. Something along these lines will be good enough: "Please note that if you are writing the pickled object to a file on windows, make sure it is opened in binary mode. Otherwise, the file may not be able to be used to unpickle on other non-windows platforms". Thanks, Raghu. -- >Comment By: Tim Peters (tim_one) Date: 2006-03-06 14:48 Message: Logged In: YES user_id=31435 Pickle files should be opened in binary mode, regardless of pickle protocol, regardless of platform, and regardless of whether reading or writing. That protocol 0 used to be called "text mode" was an historic mistake, and was given that name by a Unix-head who wouldn't know the difference between text and binary mode if it suck its teeth in their posterior and tore off an entire bloody buttock :-) -- Comment By: Terry J. Reedy (tjreedy) Date: 2006-03-06 14:03 Message: Logged In: YES user_id=593130 Any text file written with /r/n in Windows can have problems when read on *nix or Mac or ???, so this problem is not specific to pickle or even to Python. I am under the impression that the new universal newline support was intended to fix such problems (when used). But as a Win- only user (currently) I have no experience with it. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2006-03-06 10:12 Message: Logged In: YES user_id=984087 There seems to be a mistane in my earlier comment. I meant the unpickling on *UNIX* fails even if ASCII was used on windows. Raghu. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2006-03-06 10:11 Message: Logged In: YES user_id=984087 Hi, The point is that even if ASCII protocol is used on windows(as I was), the unpickling process would fail on windows. So the pickle file should be opened in binary mode on windows even for ASCII protocol. This may make reading the file in notepad difficult but then, cross platform support should take precedence, I suppose. Another option would be for python to do line end translations for ASCII pickle files. Raghu. -- Comment By: Terry J. Reedy (tjreedy) Date: 2006-03-05 22:36 Message: Logged In: YES user_id=593130 For ASCII protocol pickles, intended for human readability, one should use text mode to be able to read the file, for instance, in Notepad. For either binary protocol, I would think binary mode should be best even to reread on Windows. If anything is added, I would put "On Windows, open files in a mode (text/binary) that matches the protocol." at the bottom of http://docs.python.org/lib/node64.html Looking forward to 3.0, when file mode might be more significant (text/binary corresponding to unicode/bytes), the "for windoews' qualifier might be omitted, but this might be premature. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1439659&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1442874 ] handling comments with markupbase and HTMLParser
Bugs item #1442874, was opened at 2006-03-03 22:15 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1442874&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 3 Submitted By: Daniel (danielx_) Assigned to: Nobody/Anonymous (nobody) Summary: handling comments with markupbase and HTMLParser Initial Comment: If the following webpage is correct about the definition of a comment, HTMLParser.HTMLParser reports valid (albiet strange) comments as being erroenous: http://www.htmlhelp.com/reference/wilbur/misc/comment.html This site gives '' as an example of a valid html comment. See attachment for what happens at the console. A similar thing happens with other (pathalogical) form of comments. -- Comment By: Jim Jewett (jimjjewett) Date: 2006-03-06 15:41 Message: Logged In: YES user_id=764593 I recommend this as a wontfix. As the page itself notes, browsers generally got this wrong, and existing webpages rely on this buggy behavior. Even today, Opera is going back and forth on how right they can afford to be without breaking too many pages. The suggestion at the bottom of the page notes that if you keep your comments sane, you won't have problems on your own pages. Realistically, anything not following that rule (no embedded -- or >) is effectively buggy, and HTMLParser can only guess at the real intention. -- Comment By: Daniel (danielx_) Date: 2006-03-03 22:17 Message: Logged In: YES user_id=1383230 Sorry, I'm unfamiliar with the bug reporting system and my attachment doesn't seem to have attached. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1442874&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1444408 ] subprocess test cases fail with noexec-mounted /tmp
Bugs item #108, was opened at 2006-03-06 21:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=108&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess test cases fail with noexec-mounted /tmp Initial Comment: Hi, on my Linux box two subprocess tests always fail (see below for a log output). The reason is those two tests try to execute files created with tempfile.mkstemp(), which generates files in /tmp. And my /tmp directory forbids to execute files, it is mounted with the "noexec" option. What I expected from the tests is to either find a temporary directory where execution is allowed (eg. the directory where sys.executable lies), or simply skip those tests. Test output: [...] == ERROR: test_args_string (test.test_subprocess.ProcessTestCase) -- Traceback (most recent call last): File "/home/calvin/src/python-svn/Lib/test/test_subprocess.py", line 490, in test_args_string p = subprocess.Popen(fname) File "/home/calvin/src/python-svn/Lib/subprocess.py", line 580, in __init__ errread, errwrite) File "/home/calvin/src/python-svn/Lib/subprocess.py", line 1033, in _execute_child raise child_exception OSError: [Errno 13] Permission denied == ERROR: test_call_string (test.test_subprocess.ProcessTestCase) -- Traceback (most recent call last): File "/home/calvin/src/python-svn/Lib/test/test_subprocess.py", line 532, in test_call_string rc = subprocess.call(fname) File "/home/calvin/src/python-svn/Lib/subprocess.py", line 431, in call return Popen(*popenargs, **kwargs).wait() File "/home/calvin/src/python-svn/Lib/subprocess.py", line 580, in __init__ errread, errwrite) File "/home/calvin/src/python-svn/Lib/subprocess.py", line 1033, in _execute_child raise child_exception OSError: [Errno 13] Permission denied -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=108&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1441486 ] yet another svn head compiler change
Bugs item #1441486, was opened at 2006-03-02 00:39 Message generated for change (Comment added) made by logistix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441486&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: yet another svn head compiler change Initial Comment: This one seems stangely familiar: $ python2.4 Python 2.4.1 (#2, Mar 31 2005, 00:05:10) [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> -2147483648 -2147483648 >>> $ ~/Source/python/build/python.exe Python 2.5a0 (trunk:42764M, Mar 1 2006, 18:21:57) [GCC 4.0.1 (Apple Computer, Inc. build 5247)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> -2147483648 -2147483648L -- Comment By: Grant Olson (logistix) Date: 2006-03-06 17:47 Message: Logged In: YES user_id=699438 It looks like the parser is seeing this as unary minus applied to 2147483648 instead of the literal "-2147483648" -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441486&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1389157 ] test_tarfile fails with readonly source dir for Python 2.4.2
Bugs item #1389157, was opened at 12/23/05 13:29 Message generated for change (Settings changed) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1389157&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Langly (langly) Assigned to: Nobody/Anonymous (nobody) Summary: test_tarfile fails with readonly source dir for Python 2.4.2 Initial Comment: When compiling Python-2.4.2 and using separate source and build directories, the test_tarfile test fails if the source directory is read-only. -- >Comment By: SourceForge Robot (sf-robot) Date: 03/06/06 19:24 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Georg Brandl (birkenfeld) Date: 01/05/06 05:54 Message: Logged In: YES user_id=1188172 How do you compile Python using separate source and build directories? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1389157&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1393109 ] cannot build SVN trunk on old systems
Bugs item #1393109, was opened at 12/29/05 12:25 Message generated for change (Settings changed) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1393109&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 >Status: Closed Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: cannot build SVN trunk on old systems Initial Comment: Parser/asdl_c.py uses "/usr/bin/env python" to find a proper python, but the script don't work on old Pythons (at least it fails on 2.1 and older). iirc, various solutions to this were discussed on python-dev, but nobody seems to have done anything about it. -- >Comment By: SourceForge Robot (sf-robot) Date: 03/06/06 19:24 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Martin v. Löwis (loewis) Date: 01/11/06 14:47 Message: Logged In: YES user_id=21627 Is this still a problem? Parser/asdl_c.py should not normally be invoked, unless you edit the grammar -- Comment By: Neal Norwitz (nnorwitz) Date: 01/01/06 20:31 Message: Logged In: YES user_id=33168 One issue I see in asdl.py is that new-style classes are used. I don't know if they are really necessary. You could try adding something like this to the top of asdl.py and see if that fixes things: try: object except NameError: class object: pass Or maybe we just shouldn't make them new-style if that does fix things. I don't have an old version of python around. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1393109&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-729236 ] building readline module fails on Irix 6.5
Bugs item #729236, was opened at 04/28/03 16:03
Message generated for change (Settings changed) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729236&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: alexandre gillet (gillet)
Assigned to: Nobody/Anonymous (nobody)
Summary: building readline module fails on Irix 6.5
Initial Comment:
I am trying to build Python2.3b1 on a sgi Irix 6.5 using
MIPSpro Compilers: Version 7.30
I can't get the readline module to build. I get the
following error:
cc -OPT:Olimit=0 -DNDEBUG -O -I. -I../Include
-I/mgl/prog/share/include/ -c ../Modules/readline.c -o
Modules/readline.o
cc-1119 cc: ERROR File = ../Modules/readline.c, Line = 587
The "return" expression type differs from the
function return type.
return completion_matches(text, *on_completion);
^
cc-1552 cc: WARNING File = ../Modules/readline.c, Line
= 732
The variable "m" is set but never used.
PyObject *m;
^
1 error detected in the compilation of
"../Modules/readline.c".
gmake: *** [Modules/readline.o] Error 2
--
>Comment By: SourceForge Robot (sf-robot)
Date: 03/06/06 19:24
Message:
Logged In: YES
user_id=1312539
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
--
Comment By: Georg Brandl (birkenfeld)
Date: 02/20/06 01:15
Message:
Logged In: YES
user_id=1188172
Is this still the case with Python 2.4?
--
Comment By: Neal Norwitz (nnorwitz)
Date: 05/21/03 16:49
Message:
Logged In: YES
user_id=33168
Is HAVE_RL_COMPLETION_MATCHES defined? If so is
rl_completion_matches() defined to return char ** in
readline.h? If HAVE_* is not defined, where is
completion_matches() defined and what does it return?
--
Comment By: alexandre gillet (gillet)
Date: 05/12/03 11:02
Message:
Logged In: YES
user_id=150999
I was able to compile readline on Irix after changing the
function flex_complete. the function prototyte say it should
return a char** .So we did put the following change and it
works. Is it a right way to do it?
** readline.c 2003-05-09 13:45:38.0 -0700
--- readline.c~ 2003-03-01 07:19:41.0 -0800
***
*** 577,589
/* A more flexible constructor that saves the "begidx" and
"endidx"
* before calling the normal completer */
! static char ** flex_complete(char *text, int start, int end)
{
Py_XDECREF(begidx);
Py_XDECREF(endidx);
begidx = PyInt_FromLong((long) start);
endidx = PyInt_FromLong((long) end);
! return (char **)completion_matches(text,
*on_completion);
}
--- 577,590
/* A more flexible constructor that saves the "begidx" and
"endidx"
* before calling the normal completer */
! static char **
! flex_complete(char *text, int start, int end)
{
Py_XDECREF(begidx);
Py_XDECREF(endidx);
begidx = PyInt_FromLong((long) start);
endidx = PyInt_FromLong((long) end);
! return completion_matches(text, *on_completion);
}
--
Comment By: alexandre gillet (gillet)
Date: 05/12/03 10:44
Message:
Logged In: YES
user_id=150999
My readline version is 4.3
--
Comment By: Martin v. Löwis (loewis)
Date: 04/29/03 04:44
Message:
Logged In: YES
user_id=21627
What is your readline version?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729236&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1212703 ] Python 2.5 CVS broken for HP-UX platform?
Bugs item #1212703, was opened at 06/01/05 06:05
Message generated for change (Settings changed) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212703&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Platform-specific
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Vincent Jamart (ranma)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.5 CVS broken for HP-UX platform?
Initial Comment:
While trying to compile Python 2.5 from the nighlty CVS
image, it raises the following errors on HP-UX. (OS
version= HP-UX 11.22 on ia64, compiler= aCC: HP
aC++/ANSI C B3910B A.06.00 [Aug 25 2004])
Compilation flags:
export CC=aCC
export CFLAGS="-Ae +DD64"
export LDFLAGS="+DD64"
make clean
./configure --prefix=/usr/local/python_cvs --with-cxx=aCC
(...)
creating Makefile
aCC -c -DNDEBUG -O -I. -I./Include
-DPy_BUILD_CORE -o
Modules/ccpython.o ./Modules/ccpython.cc
"/usr/include/sys/unistd.h", line 594: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline truncate(const char *a, off_t b) { return
__truncate64(a,b); }
^
"/usr/include/sys/unistd.h", line 595: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline prealloc(int a, off_t b) { return
__prealloc64(a,b); }
^
"/usr/include/sys/unistd.h", line 596: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline lockf(int a, int b, off_t c) { return
__lockf64(a,b,c); }
^
"/usr/include/sys/unistd.h", line 597: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline ftruncate(int a, off_t b) { return
__ftruncate64(a,b); }
^
"/usr/include/sys/stat.h", line 173: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline lstat __((const char *, struct stat *));
^
"./Include/pyport.h", line 612: error #2035: #error
directive: "LONG_BIT
definition appears wrong for platform (bad
gcc/glibc
config?)."
#error "LONG_BIT definition appears wrong for
platform (bad gcc/glibc
config?)."
^
1 error detected in the compilation of
"./Modules/ccpython.cc".
*** Error exit code 2
Stop.
aCC -c -DNDEBUG -O -I. -I./Include
-DPy_BUILD_CORE -o
Modules/ccpython.o ./Modules/ccpython.cc
"/usr/include/sys/unistd.h", line 594: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline truncate(const char *a, off_t b) { return
__truncate64(a,b); }
^
"/usr/include/sys/unistd.h", line 595: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline prealloc(int a, off_t b) { return
__prealloc64(a,b); }
^
"/usr/include/sys/unistd.h", line 596: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline lockf(int a, int b, off_t c) { return
__lockf64(a,b,c); }
^
"/usr/include/sys/unistd.h", line 597: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline ftruncate(int a, off_t b) { return
__ftruncate64(a,b); }
^
"/usr/include/sys/stat.h", line 173: warning #2837-D:
omission of
explicit
type is nonstandard ("int" assumed)
inline lstat __((const char *, struct stat *));
^
"./Include/pyport.h", line 612: error #2035: #error
directive: "LONG_BIT
definition appears wrong for platform (bad
gcc/glibc
config?)."
#error "LONG_BIT definition appears wrong for
platform (bad gcc/glibc
config?)."
^
1 error detected in the compilation of
"./Modules/ccpython.cc".
*** Error exit code 2
Stop.
--
>Comment By: SourceForge Robot (sf-robot)
Date: 03/06/06 19:24
Message:
Logged In: YES
user_id=1312539
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
--
Comment By: Anthony Baxter (anthonybaxter)
Date: 09/19/05 23:32
Message:
Logged In: YES
user_id=29957
As far as I know, the patches contributed by Elemental
Security make current CVS HEAD work fine on ia64 HP/UX.
Please do test them, though - I think Guido put some notes
in the toplevel README about how to get the build to work.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 09/19/05 23:21
Message:
Logged In: YES
user_id=33168
I think there was a fix checked in recent
[ python-Bugs-1002465 ] MemoryError on AIX52
Bugs item #1002465, was opened at 08/03/04 01:04 Message generated for change (Settings changed) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002465&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Datranet (richardjmason) Assigned to: Nobody/Anonymous (nobody) Summary: MemoryError on AIX52 Initial Comment: I found the orginal problem when trying to send large email attachments on AIX 5.2. I tracked the issue down to the fact that a string can only grow to a very restricted size on AIX 5.2. bin2ascii fails at the pint the function tries to join the list togther to form 1 string. I wrote the following test program to prove the issue: a = '' cnt = 0 while cnt < 1024: a = a + 'x' cnt += 1 c = '' cnt = 0 while cnt < 1024: c = c + a cnt += 1 b = '' cnt2 = 0 while 1: b = b + c cnt2 += 1 print cnt2 On AIX 5.2 you get a MemoryError with a cnt2 value of 42. I can run the test program on all other platforms and get a cnt2 value over 150 before stopping to program myself. I have tried the binary python 2.2 from the IBM site and building python 2.3.4 myself using the gcc from the IBM site. Both fail with a cnt2 value of 42. Can anyone please advise on how to get AIX 5.2 to allow single objects to have more memory allocated. -- >Comment By: SourceForge Robot (sf-robot) Date: 03/06/06 19:25 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Neal Norwitz (nnorwitz) Date: 10/02/05 22:23 Message: Logged In: YES user_id=33168 richardjmason, are you still having this problem? -- Comment By: Michael Hudson (mwh) Date: 08/05/04 04:59 Message: Logged In: YES user_id=6656 A way this has happened in the past is calling "malloc(0)", which is entitled to return NULL and Python then thinks this is a memory error. This doesn't seeme especially likely here, though. Agree with Martin that you're probably going to need to use a debugger. -- Comment By: Martin v. Löwis (loewis) Date: 08/04/04 11:09 Message: Logged In: YES user_id=21627 You need to use a debugger to find the cause of the problem. What is the string parameter of the MemoryError? This might give a clue where precisely it is raised. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002465&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-962918 ] 2.3.4 can not be installed over 2.3.3
Bugs item #962918, was opened at 05/29/04 14:54 Message generated for change (Settings changed) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=962918&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Jarek Zgoda (zgoda) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3.4 can not be installed over 2.3.3 Initial Comment: When trying to install newly-compiled 2.3.4 over existing 2.3.3 I ran into "libinstall error" on zipfile.py. After removing whole /usr/lib/python2.3 and installing from scratch the installation was succesful. I think it's some omission from installer script, since I didn't have any problem when I upgraded 2.3.0 to 2.3.2 ant thet to 2.3.3. -- >Comment By: SourceForge Robot (sf-robot) Date: 03/06/06 19:25 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Georg Brandl (birkenfeld) Date: 02/20/06 02:18 Message: Logged In: YES user_id=1188172 Are you still having problems with 2.4? -- Comment By: Jarek Zgoda (zgoda) Date: 05/31/04 23:59 Message: Logged In: YES user_id=9 System is Slackware Linux 9.1/2.6.6, Python 2.3.3 (version that I tried to overwrite) was compiled by me on the same machine. Error message was as I wrote: "libinstall error". Command chain was very usual: ./configure --prefix=/usr --disable-ipv6 make make test make install Error was raised during last step, the very last entry before error occured on the list of installed libraries was zipfile.py. -- Comment By: Martin v. Löwis (loewis) Date: 05/31/04 14:09 Message: Logged In: YES user_id=21627 What operating system are you using? Can you report the precise wording of the error that you get, and the command that you have invoked to trigger this error? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=962918&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1188231 ] Rebuilding from source on RH9 fails (_tkinter.so missing)
Bugs item #1188231, was opened at 04/22/05 11:21 Message generated for change (Settings changed) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1188231&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Marty Heyman (mheyman) Assigned to: Nobody/Anonymous (nobody) Summary: Rebuilding from source on RH9 fails (_tkinter.so missing) Initial Comment: On a Red Hat 9 system, I downloaded the python2.4-2.4. 1-1pydotorg.src.rpm and, following the web page ran "rpm --rebuild . ..". It went a long for a good long while with no apparent errors and then said: --- RPM build errors: File not found by glob: /var/tmp/python2.4-2.4. 1-root/usr/lib/python2.4/lib-dynload/_tkinter.so* --- I looked in the directory and there is, in fact, no _tkinter.so file(s) there. -- Marty Heyman -- >Comment By: SourceForge Robot (sf-robot) Date: 03/06/06 19:25 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Georg Brandl (birkenfeld) Date: 02/20/06 02:25 Message: Logged In: YES user_id=1188172 This looks like it is not Python's fault. -- Comment By: green-ghost (green-ghost) Date: 07/30/05 08:35 Message: Logged In: YES user_id=1321225 I had a similar problem compiling python from source on a (nominally) redhat8 system. For whatever reason, X11 headers were not installed (probably because it's a server I only use from an ssh console). YMMV Try: apt-get install XFree86-devel or: rpm -i XFree86-devel-.rpm -- Comment By: Martin v. Löwis (loewis) Date: 05/02/05 14:16 Message: Logged In: YES user_id=21627 Ah, so it seems you are lacking the X11 header files. They should have been installed as a dependency on the Tk headers. So this is either a Redhat bug (for not including a dependency of the -dev packages) or a local misconfiguration of some kind (e.g. forcefully installing Tk headers without all prerequisites present). -- Comment By: Marty Heyman (mheyman) Date: 04/22/05 11:42 Message: Logged In: YES user_id=421967 APOLOGIES: ADDITIONAL INFO FOLLOWS ---Snip from rebuild output follows In file included from /usr/src/redhat/BUILD/Python-2.4.1/Modules/_tkinter.c:67: /usr/include/tk.h:83:29: X11/Xlib.h: No such file or directory In file included from /usr/src/redhat/BUILD/Python-2.4.1/Modules/_tkinter.c:67: /usr/include/tk.h:581: parse error before "Bool" /usr/include/tk.h:583: parse error before "event" /usr/include/tk.h:584: parse error before "root" /usr/include/tk.h:585: parse error before "subwindow" /usr/include/tk.h:586: parse error before "time" /usr/include/tk.h:586: `time' redeclared as different kind of symbol /usr/include/time.h:184: previous declaration of `time' /usr/include/tk.h:591: parse error before "same_screen" --- snip ends many more "parse error lines occurred after this. I doubt they're interesting . A bit later, another group of failures begins --Snip starts In file included from /usr/include/tk.h:1361, from /usr/src/redhat/BUILD/Python-2.4.1/Modules/_tkinter.c:67: /usr/include/tkDecls.h:37: parse error before '*' token /usr/include/tkDecls.h:39: parse error before "Tk_3DBorderGC" /usr/include/tkDecls.h:45: parse error before "Drawable" /usr/include/tkDecls.h:50: parse error before "Drawable" /usr/include/tkDecls.h:58: parse error before "XEvent" --Snip ends Again, there are many more similar messages following those and then: --Snip starts /usr/include/tkDecls.h:843: `GC' declared as function returning a function ... [parse errors] /usr/include/tkDecls.h:906: `Font' declared as function returning a function --Snip ends There are many such embedded in that group. Then the messages stop followed by a line that says: "running build_scripts" ... and things proceed as if all was OK for hundreds more lines of output before the failure copied into the original report. I captured the complete log and can upload it if needed on request. I'd need to trim it and it doesn't look all that interesting otherwise but then, what do I know :-) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1188231&group_id=5470 _
[ python-Bugs-1071597 ] configure problem on HP-UX 11.11
Bugs item #1071597, was opened at 11/23/04 02:30 Message generated for change (Settings changed) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071597&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Platform-specific >Status: Closed Resolution: None Priority: 5 Submitted By: Harri Pasanen (harripasanen) Assigned to: Nobody/Anonymous (nobody) Summary: configure problem on HP-UX 11.11 Initial Comment: Python 2.4c1 has this problem (but if I recall, so did 2.3.3)_ Using gcc 3.3.3 to build on HP-UX 11.11, the configure out of the box is a bit off, resulting in a failed build, due to missing thread symbols: /usr/ccs/bin/ld: Unsatisfied symbols: PyThread_acquire_lock (first referenced in libpython2.4.a(import.o)) (code) PyThread_exit_thread (first referenced in libpython2.4.a(threadmodule.o)) (code) PyThread_allocate_lock (first referenced in libpython2.4.a(import.o)) (code) PyThread_free_lock (first referenced in libpython2.4.a(threadmodule.o)) (code) PyThread_start_new_thread (first referenced in libpython2.4.a(threadmodule.o)) (code) PyThread_release_lock (first referenced in libpython2.4.a(import.o)) (code) PyThread_get_thread_ident (first referenced in libpython2.4.a(import.o)) (code) PyThread__init_thread (first referenced in libpython2.4.a(thread.o)) (code) collect2: ld returned 1 exit status A workaround is to manually edit pyconfig.h, adding #define _POSIX_THREADS (The reason it is not picked up is that unistd.h on HP-UX has this comment: / * The following defines are specified in the standard, but are not yet * implemented: * *_POSIX_THREADS can't be defined until all * features are implemented ) The implementation seems however to be sufficiently complete to permit compiling and running Python with _POSIX_THREADS. While I'm editing pyconfig.h, I also comment out _POSIX_C_SOURCE definition, as it will result in lots of compilation warnings, of the style: gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I../Python-2.4c1/Include -DPy_BUILD_CORE -o Objects/frameobject.o ../Python-2.4c1/Objects/frameobject.c In file included from ../Python-2.4c1/Include/Python.h:8, from ../Python-2.4c1/Objects/frameobject.c:4: pyconfig.h:835:1: warning: "_POSIX_C_SOURCE" redefined :6:1: warning: this is the location of the previous definition So, to recapitulate: After configure, add #define _POSIX_THREADS and comment out #define _POSIX_C_SOURCE 200112L That will give you a Python working rather well, with "make test" producing: 251 tests OK. 1 test failed: test_pty 38 tests skipped: test_aepack test_al test_applesingle test_bsddb test_bsddb185 test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dl test_gdbm test_gl test_imgfile test_largefile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_tcl test_timeout test_urllib2net test_urllibnet test_winreg test_winsound 1 skip unexpected on hp-ux11: test_tcl -- >Comment By: SourceForge Robot (sf-robot) Date: 03/06/06 19:25 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Georg Brandl (birkenfeld) Date: 02/20/06 02:27 Message: Logged In: YES user_id=1188172 cbeatley: your problem should be fixed as the pwd module is now builtin. OP: do you still have problems with recent releases? -- Comment By: Cameron Beatley (cbeatley) Date: 06/15/05 13:18 Message: Logged In: YES user_id=991535 I have the same problems. When I edit the pyconfig.h file as described and run Make again, I get the following Traceback (most recent call last): File "./setup.py", line 1184, in ? main() File "./setup.py", line 1178, in main scripts = ['Tools/scripts/pydoc', 'Tools/scripts/idle', File "/CVS/apps/Python-2.4.1/Lib/distutils/core.py", line 123, in setup dist.parse_config_files() File "/CVS/apps/Python-2.4.1/Lib
[ python-Bugs-820953 ] dbm Error
Bugs item #820953, was opened at 10/09/03 16:13 Message generated for change (Settings changed) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820953&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Jim Gifford (giffordj) Assigned to: Nobody/Anonymous (nobody) Summary: dbm Error Initial Comment: Receive the following error during make install of python 2.3.2. Any suggestions or is it safe to ignore. building 'dbm' extension gcc -pthread -DNDEBUG -g -march=pentium2 -mmmx - O2 -pipe -Wall -Wstrict-prototypes -fPIC -fno-strict- aliasing -DHAVE_NDBM_H -I. -I/usr/src/Python- 2.3.2/./Include -I/usr/local/include -I/usr/src/Python- 2.3.2/Include -I/usr/src/Python-2.3.2 - c /usr/src/Python-2.3.2/Modules/dbmmodule.c -o build/temp.linux-i686-2.3/dbmmodule.o gcc -pthread -shared build/temp.linux-i686- 2.3/dbmmodule.o -L/usr/local/lib -o build/lib.linux-i686- 2.3/dbm.so *** WARNING: renaming "dbm" since importing it failed: build/lib.linux-i686-2.3/dbm.so: undefined symbol: dbm_firstkey running build_scripts -- >Comment By: SourceForge Robot (sf-robot) Date: 03/06/06 19:28 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Georg Brandl (gbrandl) Date: 02/20/06 07:30 Message: Logged In: YES user_id=849994 Do you still have problems with 2.4? -- Comment By: Jim Gifford (giffordj) Date: 10/12/03 00:42 Message: Logged In: YES user_id=492775 Upon further research, when this error occurs installation does continue, but libpython2.3.a is never created. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820953&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-675187 ] bsddb hangs with recno/source sync
Bugs item #675187, was opened at 01/26/03 16:01
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675187&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Magnus Lie Hetland (mlh)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddb hangs with recno/source sync
Initial Comment:
I just tried to use bsddb with the source argument to have
flat
backing file. Creating a database with such a backing
file as
source was not problematic, but after I had modified
it, the
sync() and close() method would hang.
For
example:
from bsddb import rnopen
r =
rnopen('test.dat', source='test.txt')
r[1] = 'foobar'
r.sync()
# Hangs here...
After running this, test.txt will be empty
(even though it
wasn't before). Running the code above without
the source
argument works just fine.
I'm running
Python 2.3 cvs version (slightly earlier than the
first alpha) on
SunOS 5.9.
--
>Comment By: SourceForge Robot (sf-robot)
Date: 03/06/06 19:28
Message:
Logged In: YES
user_id=1312539
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
--
Comment By: Georg Brandl (gbrandl)
Date: 02/20/06 09:43
Message:
Logged In: YES
user_id=849994
Cannot reproduce with Python 2.4.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675187&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-872736 ] Python 2.3.3 urllib proxy support fails
Bugs item #872736, was opened at 01/07/04 16:20 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=872736&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Eric Johnson (eggsy) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.3.3 urllib proxy support fails Initial Comment: Using Python 2.3.3 on Win2K and Win98 the urllib module does not seem to support proxies as described in the documentation. I have the http_proxy environment variable set and urllib2.urlopen can successfully access the web via the proxy. Trying urllib.urlopen results in a IOError: [Errno socket error] (7, 'getaddrinfo failed') exception which suggests that it is not using the proxy. This occurs both with an explicit proxy defined and when using the environment variable. See attached file for an example script. I could not see any reference to proxies in the urllib test script so I wonder whether this has been tested. I have not (yet) tried to investigate why this does not work. -- >Comment By: SourceForge Robot (sf-robot) Date: 03/06/06 19:28 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Georg Brandl (gbrandl) Date: 02/20/06 12:03 Message: Logged In: YES user_id=849994 Proxy support has recently been improved in urllib. Can you test whether it works now? -- Comment By: Jim Jewett (jimjjewett) Date: 01/08/04 07:33 Message: Logged In: YES user_id=764593 Do you need to authenticate to your proxy? The default getpass will fail instead of asking for a password if it thinks there is an eavesdropper - and idle counts as an eavesdropper. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=872736&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-815999 ] ImportError: No module named _socket
Bugs item #815999, was opened at 10/01/03 10:21 Message generated for change (Settings changed) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815999&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Peter Stauffert (stauffert) Assigned to: Nobody/Anonymous (nobody) Summary: ImportError: No module named _socket Initial Comment: Hi There is a problem during the installation of python 2.3.1: I used configure with the following options: ./configure --enable-shared=yes --with-signal- module=yes --with-cxx=/usr/freeware/bin/c++ make runs to the end, only warning messages are displayed. Running "make test" on a SGI Origin200, IRIX 6.5-18 I got the following error message: test test___all__ failed -- Traceback (most recent call last): File "/install/fw/Python-2.3.1/Lib/test/test___all__.py", line 54, in test_all import _socket ImportError: No module named _socket This looks like the python bug 565710 reported for python 2.2.1 which was solved by modifications of setup.py in the top level directory. But setup.py was modified in python 2.3.1 and I could not apply the old patch to the new version. Could you help me with this problem? Thanks a lot Peter Stauffert -- >Comment By: SourceForge Robot (sf-robot) Date: 03/06/06 19:28 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Georg Brandl (gbrandl) Date: 02/20/06 11:33 Message: Logged In: YES user_id=849994 OP: Do you still experience problems with 2.4? -- Comment By: Martin v. Löwis (loewis) Date: 10/13/03 14:27 Message: Logged In: YES user_id=21627 jemfinch, I very much doubt that you have the same problem as the submitter of this report, and your Usenet message gives hardly enough detail to analyse the problem; for example, the linker error you report has a truncated error message. Please submit a separate report, and report precisely what you did, the complete output that you got, and what exactly isn't working the way you expect it to work. -- Comment By: Jeremy Fincher (jemfinch) Date: 10/13/03 07:33 Message: Logged In: YES user_id=99508 If you don't mind, I'll just link you to my comp.lang.python post about it: http://groups.google.com/groups?q=group:comp.lang.python+solaris+7&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=698f09f8.0310100915.359b2e09%40posting.google.com&rnum=9 That has the exact compilation error. I've tried passing the --disable-IPV6 option to configure (as MvL mentioned) and it seemed to compile, but I still don't have access to the _socket library, probably due to the second error I mentioned. I tried the fix in the bug #565710 (adding runtime_library_dirs to setup.py) but to no avail. -- Comment By: Anthony Baxter (anthonybaxter) Date: 10/12/03 22:51 Message: Logged In: YES user_id=29957 Works for me on Solaris 2.6, 7 and 8. What compiler, what version, what error did you get during the build of socketmodule? -- Comment By: Jeremy Fincher (jemfinch) Date: 10/11/03 04:35 Message: Logged In: YES user_id=99508 I have this same bug on Solaris 7 with 2.3.2. -- Comment By: Anthony Baxter (anthonybaxter) Date: 10/03/03 17:24 Message: Logged In: YES user_id=29957 Does the patch available from www.python.org/bugs.html fix this problem? Which compiler did you use? From the configure line, above, it looks like you might be using gcc? -- Comment By: Martin v. Löwis (loewis) Date: 10/03/03 06:28 Message: Logged In: YES user_id=21627 Can you please attach the build log? In particular, it would be importing to see whether building _socket was attempted, and failed. Maybe your compiler just doesn't work??? -- Comment By: casey dunn (caseyd) Date: 10/01/03 12:53 Message: Logged In: YES user_id=878394 I have seen this on Solaris as well, recent and old vintages. Casey Dunn -- You can respond by visiting: https://sourc
