graph
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
type
legacy-trunk
Sun, 06 Apr 2008 17:05:57 +0000, by Skip Montanaro
-
-
-
-
-
-
-
-
-
Merged revisions 61440-61441,61443,61445-61448,61451-61452,61455-61457,61459-61464,61466-61467,61469-61470,61476-61477,61479,61481-61482,61485,61487,61490,61493-61494,61497,61499-61502,61505-61506,61508,61511-61514,61519,61521-61522,61530-61531,61533-61537,61541-61555,61557-61558,61561-61562,61566-61569,61572-61574,61578-61579,61583-61584,61588-61589,61592,61594,61598-61601,61603-61604,61607-61612,61617,61619-61620,61624,61626,61628-61630,61635-61638,61640-61643,61645,61648,61653-61655,61659-61662,61664,61666,61668-61671,61673,61675,61679-61680,61682,61685-61686,61689-61695,61697-61699,61701-61703,61706,61710,61713,61717,61723,61726-61730,61736,61738,61740,61742,61745-61752,61754-61760,61762-61764,61768,61770-61772,61774-61775,61784-61787,61789-61792,61794-61795,61797-61806,61808-61809,61811-61812,61814-61819,61824,61826-61833,61835-61840,61843-61845,61848,61850,61854-61862,61865-61866,61868,61872-61873,61876-61877,61883-61888,61890-61891,61893-61899,61901-61903,61905-61912,61914,61917,61920-61921,61927,61930,61932-61934,61939,61941-61942,61944-61951,61955,61960-61963,61980,61982-61983,61991,61994-61996,62001-62003,62008-62010,62016-62017,62022,62024,62027,62031-62034,62041,62045-62046,62055-62058,62060-62066,62068-62074,62076-62079,62081-62083,62086-62089,62092-62094,62098,62101,62104,62106-62109,62115-62122,62124-62125,62128,62130,62132,62134-62135,62137,62139-62140,62144,62146,62151,62155,62157,62162-62174 via svnmerge from
Sat, 05 Apr 2008 18:58:09 +0000, by Martin v. Löwis
-
-
-
-
-
-
-
-
-
-
-
Merged revisions 61440-61441,61443,61445-61448,61451-61452,61455-61457,61459-61464,61466-61467,61469-61470,61476-61477,61479,61481-61482,61485,61487,61490,61493-61494,61497,61499-61502,61505-61506,61508,61511-61514,61519,61521-61522,61530-61531,61533-61537,61541-61555,61557-61558,61561-61562,61566-61569,61572-61574,61578-61579,61583-61584,61588-61589,61592,61594,61598-61601,61603-61604,61607-61612,61617,61619-61620,61624,61626,61628-61630,61635-61638,61640-61643,61645,61648,61653-61655,61659-61662,61664,61666,61668-61671,61673,61675,61679-61680,61682,61685-61686,61689-61695,61697-61699,61701-61703,61706,61710,61713,61717,61723,61726-61730,61736,61738,61740,61742,61745-61752,61754-61760,61762-61764,61768,61770-61772,61774-61775,61784-61787,61789-61792,61794-61795,61797-61806,61808-61809,61811-61812,61814-61819,61824,61826-61833,61835-61840,61843-61845,61848,61850,61854-61862,61865-61866,61868,61872-61873,61876-61877,61883-61888,61890-61891,61893-61899,61901-61903,61905-61912,61914,61917,61920-61921,61927,61930,61932-61934,61939,61941-61942,61944-61951,61955,61960-61963,61980,61982-61983,61991,61994-61996,62001-62003,62008-62010,62016-62017,62022,62024,62027,62031-62034,62041,62045-62046,62055-62058,62060-62066,62068-62074,62076-62079,62081-62083,62086-62089,62092-62094,62098,62101,62104,62106-62109,62115-62122,62124-62125,62127-62128,62130,62132,62134-62137,62139-62142,62144,62146-62148,62150-62152,62155-62161 via svnmerge from
Sat, 05 Apr 2008 04:47:45 +0000, by Neal Norwitz
-
-
Various edits
legacy-trunk
Sat, 05 Apr 2008 03:38:39 +0000, by Andrew M. Kuchling
-
-
Minor edits
legacy-trunk
Sat, 05 Apr 2008 02:42:20 +0000, by Andrew M. Kuchling
-
-
Revert r62152 (Issue #2550). Being able to observe the results of all the buildbots was certainly useful. All of the platforms that have some form of BSD lineage -- FreeBSD, OS X, Solaris and Tru64 -- all pass the test. Windows and Linux, on the other hand, don't. Windows I knew about, Linux was a surprise. Knowing this, I believe a more appropriate fix will revolve around test_support.bind_socket() -- this method needs to return a port that nothing in the system has bound already. The best way to do this may just be to rely on ephemeral ports, rather than having the user specify a desired port, then fall back to four random ports, then try 0.
legacy-trunk
Fri, 04 Apr 2008 20:04:09 +0000, by Trent Nelson
-
-
-
-
Issue 2550: extend test_socket.py to test SO_REUSEADDR semantics when bind() is called on identical (host, port) combinations in two separate sockets. This should raise an EADDRINUSE socket.error in all cases, irrespective of whether or not SO_REUSEADDR is set on the sockets. However, with Windows, when SO_REUSEADDR is set on the sockets, no error is thrown (an error is thrown when the option isn't set), which results in an extremely wedged python process whenever accept() is called on either of the bound sockets. I'm committing this test now to observe if it's only Windows that has this behaviour (via the buildbots). Note: this WILL break all Windows buildbots for now; once I've observed the results on other platforms, I'll revert, then start looking into a patch.
legacy-trunk
Fri, 04 Apr 2008 17:26:21 +0000, by Trent Nelson
-
-
-
-
-
-
-
-
-
-
-
