[ python-Bugs-1738559 ] Python-2.5.1.tar.bz2 build failed at Centos-4.5 server
Bugs item #1738559, was opened at 2007-06-17 09:29 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738559&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: Open Resolution: None Priority: 5 Private: No Submitted By: shuvo (shuvo1470) Assigned to: Nobody/Anonymous (nobody) Summary: Python-2.5.1.tar.bz2 build failed at Centos-4.5 server Initial Comment: I tried to build Python-2.5.1.tar.bz2 at my Centos-4.5 server but unable to build it. there is the error i am getting File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/ChipViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/TypeinViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/pyColorChooser.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/Main.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/TextViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/ColorDB.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/StripViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/DetailsViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/ListViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/PyncheWidget.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/Switchboard.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/__init__.pyo -- >Comment By: Martin v. Löwis (loewis) Date: 2007-06-23 13:37 Message: Logged In: YES user_id=21627 Originator: NO Please report the first errors; the errors you show are likely follow-up errors. If possible, attach the entire build output as a compressed file to this report. -- Comment By: shuvo (shuvo1470) Date: 2007-06-20 15:02 Message: Logged In: YES user_id=1819895 Originator: YES No. These are last error messages while exiting build process. -- Comment By: Georg Brandl (gbrandl) Date: 2007-06-19 14:41 Message: Logged In: YES user_id=849994 Originator: NO Are these the first error messages in the build process? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738559&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1740572 ] asynchat should call "handle_close"
Bugs item #1740572, was opened at 2007-06-20 13:19 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1740572&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 Private: No Submitted By: billiejoex (billiejoex) Assigned to: Josiah Carlson (josiahcarlson) Summary: asynchat should call "handle_close" Initial Comment: When 'close_when_done' is used and the producer is consumed 'close' method is called. IMO a better delegation design would be calling handle_close instead, just like recv already does. -- >Comment By: Josiah Carlson (josiahcarlson) Date: 2007-06-23 07:07 Message: Logged In: YES user_id=341410 Originator: NO Indeed, asynchat.async_chat.refill_buffer() should call handle_close() rather than close(). In the patch I recently provided, it calls handle_close() in the equivalent method. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1740572&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1741898 ] Odd UDP problems in socket library
Bugs item #1741898, was opened at 2007-06-22 15:30 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1741898&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jay Sherby (bluej774) Assigned to: Nobody/Anonymous (nobody) Summary: Odd UDP problems in socket library Initial Comment: I've been noticing a bug specifically in Python 2.5 concerning the socket library when using SOCK_DGRAM. I was trying to use python as an SNTP client. I used several implementations including the Python cookbook version (http://www.google.com/url?sa=t&ct=res&cd=2&url=http%3A%2F%2Faspn.activestate.com%2FASPN%2FCookbook%2FPython%2FRecipe%2F117211&ei=6kp8RvyPMsLAiwGr6fzdDg&usg=AFQjCNHaRhf2_o5Si1SIqeQue1_aylJxsA&sig2=DzpLAKAFiol-b_sc0HAc5A) and this other version (http://ntrg.cs.tcd.ie/~argp/software/attic/ntpdate.py). They each exhibited a strange problem where the first info received is not what is expected. This subsequently causes an error when the struct.unpack function is used because python for some reason receives much more than 48 bytes of info. Here is an example of the erroneous info received: http://stashbox.org/25082/output.pdf I've discovered a workaround for this bug. It only works in Python 2.5. In earlier versions, it causes the script to hang. If one calls the function client.recvfrom(1024) twice and ignores the data received first, the second time it is called, it'll have the expected info. I've also devised a way that the bug can be avoided in version 2.5 while not causing earlier versions to hang. for i in range(2): client.sendto(data, (sys.argv[1], 123)) data, address = client.recvfrom(1024) Anyway, I believe this is a problem in the socket library that only manifests itself when using UDP. Thanks for looking into it. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-06-23 08:10 Message: Logged In: YES user_id=341410 Originator: NO Could you produce a small runnable sample, describe what it should produce, and what it actually produces? That would make it much easier for us to help you. Thank you. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1741898&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1742164 ] Incorrect docs for optparse OptionParser add_help_option
Bugs item #1742164, was opened at 2007-06-23 11:16 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=1742164&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Forest Wilkinson (forest) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect docs for optparse OptionParser add_help_option Initial Comment: http://www.python.org/doc/2.5/lib/optparse-creating-parser.html The docs say: "add_help_option (default: True) If true, optparse will add a help option (with option strings "-h" and "-help") to the parser." In fact, it adds option strings "-h" and "--help". Note the additional '-' character as compared to the documentation. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1742164&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1742205 ] ZipFile.writestr writes incorrect extended local headers
Bugs item #1742205, was opened at 2007-06-23 16:07 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=1742205&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: Open Resolution: None Priority: 5 Private: No Submitted By: alexis (asak) Assigned to: Nobody/Anonymous (nobody) Summary: ZipFile.writestr writes incorrect extended local headers Initial Comment: According to http://www.onicos.com/staff/iz/formats/zip.html the format of an optional extended local header is: Extended local header: Offset Length Contents 0 4 bytes Extended Local file header signature (0x08074b50) 4 4 bytes CRC-32 8 4 bytes Compressed size 12 4 bytes Uncompressed size If you call ZipFile.writestr passing a ZipInfo where flag_bits & 0x08 is true, it will try to write an extended local header, but it won't write the header signature. Even though (on Linux) unzip doesn't complain about it, a zip -T file.zip tells me: $ zip -T file.zip zip warning: extended local header not found for filename zip error: Zip file structure invalid (file.zip) Tested on a debian unstable system, with Python 2.3.5, 2.4.4 and 2.5.1. I'm attaching a simple test case. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1742205&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1741898 ] Odd UDP problems in socket library
Bugs item #1741898, was opened at 2007-06-22 17:30 Message generated for change (Settings changed) made by bluej774 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1741898&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.5 >Status: Deleted Resolution: None Priority: 5 Private: No Submitted By: Jay Sherby (bluej774) Assigned to: Nobody/Anonymous (nobody) Summary: Odd UDP problems in socket library Initial Comment: I've been noticing a bug specifically in Python 2.5 concerning the socket library when using SOCK_DGRAM. I was trying to use python as an SNTP client. I used several implementations including the Python cookbook version (http://www.google.com/url?sa=t&ct=res&cd=2&url=http%3A%2F%2Faspn.activestate.com%2FASPN%2FCookbook%2FPython%2FRecipe%2F117211&ei=6kp8RvyPMsLAiwGr6fzdDg&usg=AFQjCNHaRhf2_o5Si1SIqeQue1_aylJxsA&sig2=DzpLAKAFiol-b_sc0HAc5A) and this other version (http://ntrg.cs.tcd.ie/~argp/software/attic/ntpdate.py). They each exhibited a strange problem where the first info received is not what is expected. This subsequently causes an error when the struct.unpack function is used because python for some reason receives much more than 48 bytes of info. Here is an example of the erroneous info received: http://stashbox.org/25082/output.pdf I've discovered a workaround for this bug. It only works in Python 2.5. In earlier versions, it causes the script to hang. If one calls the function client.recvfrom(1024) twice and ignores the data received first, the second time it is called, it'll have the expected info. I've also devised a way that the bug can be avoided in version 2.5 while not causing earlier versions to hang. for i in range(2): client.sendto(data, (sys.argv[1], 123)) data, address = client.recvfrom(1024) Anyway, I believe this is a problem in the socket library that only manifests itself when using UDP. Thanks for looking into it. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-06-23 10:10 Message: Logged In: YES user_id=341410 Originator: NO Could you produce a small runnable sample, describe what it should produce, and what it actually produces? That would make it much easier for us to help you. Thank you. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1741898&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
