Release Trac 0.11.6

[cboos]

This task ticket is used to coordinate the finalization and testing of the next stable version of Trac, 0.11.6.

We're entering a one week period of testing for the rc1, tagged in [8845].

If everything goes well, release of 0.11.6 proper will happen right after that.

Testing

People having volunteered to contribute to release testing on TracDev/ReleaseTesting were added to the CC: list.

If you'd like to contribute, please fill an entry in the table you'll find there, detailing the configuration(s) you will test, and report the status of your testing in this ticket.

Status

• issues reported in comment:3 fixed (comment:8)
• issue reported in comment:10:ticket:8240 fixed (comment:11:ticket:8240)

[cboos]

Packages are now available at the usual place, see TracDownload#LatestReleaseCandidate.

[cboos]

mention the TracDev/ReleaseTesting summary page; as you can see there, t.e.o is now running 0.11.6rc1.

[rblank]

All tests pass on 2.3. There's one small issue that has probably gone unnoticed for a long time due to an except: statement: the browser quickjump doesn't work on 2.3, due to a missing import:

trac/versioncontrol/svn_fs.py

@@ -58 +58 @@
 from trac.versioncontrol.cache import CachedRepository
 from trac.versioncontrol.svn_authz import SubversionAuthorizer
 from trac.util import embedded_numbers
+from trac.util.compat import sorted
 from trac.util.text import exception_to_unicode, to_unicode
 from trac.util.translation import _
 from trac.util.datefmt import utc

Another minor issue is that the fix from #8582 and #8357 doesn't work on 2.3 - 2.5, because socket.error is not a subclass of IOError in these versions. This was only done in 2.6. We could handle socket.error as well, and get the error code from e.args[0] instead of e.errno:

trac/web/wsgi.py

@@ -15 +15 @@
 # Author: Christopher Lenz <cmlenz@gmx.de>
 
 import errno
+import socket
 import sys
 from BaseHTTPServer import HTTPServer, BaseHTTPRequestHandler
 from SocketServer import ForkingMixIn, ThreadingMixIn
@@ -181 +182 @@
     def handle_one_request(self):
         try:
             environ = self.setup_environ()
-        except IOError, e:
+        except (IOError, socket.error), e:
             environ = None
-            if e.errno in (errno.EPIPE, errno.ECONNRESET, 10053, 10054):
+            if e.args[0] in (errno.EPIPE, errno.ECONNRESET, 10053, 10054):
                 # client disconnect
                 self.close_connection = 1
             else:
@@ -220 +221 @@
                     self.handler.send_header(name, value)
                 self.handler.end_headers()
             self.handler.wfile.write(data)
-        except IOError, e:
-            if e.errno in (errno.EPIPE, 10053, 10054): # client disconnect
+        except (IOError, socket.error), e:
+            if e.args[0] in (errno.EPIPE, errno.ECONNRESET, 10053, 10054):
+                # client disconnect
                 self.handler.close_connection = 1
             else:
                 raise

(The check for ECONNRESET was also missing in the second block, by bad.)

Other than that, everything runs smoothly on 2.3.

[cboos]

Both patches looks good, you should apply them.

However, I wonder how robust getting socket.error will be, as I've seen some strange exceptions in similar code (see ticket:3957#comment:26).

[rblank]

Replying to cboos:

Both patches looks good, you should apply them.

Actually, it's even a bit more complicated. I can get the same exception even with the patch in tracd, by refreshing very fast in Firefox (keep your finger on F5 to reproduce the issue):

Exception happened during processing of request from ('172.16.30.26', 1748)
Traceback (most recent call last):
  File "/opt/local/lib/python2.3/SocketServer.py", line 463, in process_request_thread
    self.finish_request(request, client_address)
  File "/opt/local/lib/python2.3/SocketServer.py", line 254, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/opt/local/lib/python2.3/SocketServer.py", line 521, in __init__
    self.handle()
  File "/opt/local/lib/python2.3/BaseHTTPServer.py", line 326, in handle
    self.handle_one_request()
  File "/Users/joe/src/trac/0.11.6rc1/trac/web/wsgi.py", line 196, in handle_one_request
    gateway.run(self.server.application)
  File "/Users/joe/src/trac/0.11.6rc1/trac/web/wsgi.py", line 105, in run
    self._write('')
  File "/Users/joe/src/trac/0.11.6rc1/trac/web/wsgi.py", line 221, in _write
    self.handler.send_response(int(status[:3]))
  File "/opt/local/lib/python2.3/BaseHTTPServer.py", line 378, in send_response
    self.send_header('Date', self.date_time_string())
  File "/opt/local/lib/python2.3/BaseHTTPServer.py", line 383, in send_header
    self.wfile.write("%s: %s\r\n" % (keyword, value))
  File "/opt/local/lib/python2.3/socket.py", line 254, in write
    self.flush()
  File "/opt/local/lib/python2.3/socket.py", line 241, in flush
    self._sock.sendall(buffer)
error: (32, 'Broken pipe')

So I wonder (haven't looked at the code yet):

• If there are other locations where these exceptions should be handled, or
• If the exceptions should be handled higher up the stack

However, I wonder how robust getting socket.error will be, as I've seen some strange exceptions in similar code (see ticket:3957#comment:26).

Is it socket.error or select.error that's problematic there?

[cboos]

Replying to rblank:

Replying to cboos:

File "/Users/joe/src/trac/0.11.6rc1/trac/web/wsgi.py", line 221, in _write

...

error: (32, 'Broken pipe')

I don't see how that can happen if you fixed the exception checking as in comment:3?

• If the exceptions should be handled higher up the stack

This not really possible I think, as _write will be called in isolation from req.send, so we need to catch the error directly there.

Example traceback I got after such a refactoring:

Traceback (most recent call last):
  File "C:\Workspace\src\trac\repos\0.11-stable\trac\web\main.py", line 450, in _dispatch_request
    dispatcher.dispatch(req)
  File "C:\Workspace\src\trac\repos\0.11-stable\trac\web\main.py", line 230, in dispatch
    req.send(output, content_type or 'text/html')
  File "C:\Workspace\src\trac\repos\0.11-stable\trac\web\api.py", line 359, in send
    self.write(content)
  File "C:\Workspace\src\trac\repos\0.11-stable\trac\web\api.py", line 463, in write
    self._write(data)
  File "C:\Workspace\src\trac\repos\0.11-stable\trac\web\wsgi.py", line 218, in _write
    self.handler.send_response(int(status[:3]))
...

However, I wonder how robust getting socket.error will be, as I've seen some strange exceptions in similar code (see ticket:3957#comment:26).

Is it socket.error or select.error that's problematic there?

No idea yet, and of course, no idea why this could even happen.
The only difference between the two is that select is directly a C extension and that socket.py does a from _socket import * in order to get the error.

[rblank]

Replying to cboos:

I don't see how that can happen if you fixed the exception checking as in comment:3?

You are right, of course, I missed something. But I could bet that I saw a similar exception yesterday, thrown in BaseHTTPServer. I'll try again tonight.

[rblank]

Finally, I'm not able to reproduce the issue with both patches applied, so I guess they fix it for good. Applied in [8849].

[rblank]

The issue resulting in failing tests on Tim's buildbot have been fixed.

[cboos]

t.e.o is running [8857]. I'm not sure it's worth creating a rc2, the diffs are quite small and we could specifically test for the changes made since 0.11.6rc1, while testers at large hopefully continue to test the rest.

[ecarter]

Fedora 11: All tests passed

CentOS5: SKIPPED reST tests, remaining tests passed

[rblank]

OS X 10.5.6, Python 2.3.7, SQLite 3.6.20: all tests pass, except:

SKIP: validation of XHTML output in functional tests (no lxml installed)
SKIP: RegressionTestTicket5819 (python 2.3 issue)

• Environment creation ok
• General usage ok
• Revision log RSS and changelog formats ok
• Creating tickets and adding attachments with only TICKET_CREATE and TICKET_APPEND ok
• mailto: link visibility ok
• No more ECONNRESET exceptions
• I'm able to trigger the "TimeoutError: Unable to get database connection within 20 seconds" by loading WikiStart in a tab and keeping my finger on F5 for 30 seconds. When that happens, a simple refresh loads the page correctly (i.e. the error is not permanent).

I'd say this is a "pass".

[rblank]

Gentoo x86, Python 2.6.2, SQLite 3.6.19:

• Update of two installation successful

[rblank]

OS X 10.5.6, Python 2.6.4, SQLite 3.6.20: all tests pass, except:

SKIP: reST wiki tests (no docutils)

(That one is due to the module roman missing on OS X.)

• Environment creation ok
• General usage ok
• Same "Unable to get database connection" errors in the same conditions as above

OS X 10.5.6, Python 2.6.4, MySQL 5.1.40: all tests pass, with the same SKIP.

OS X 10.5.6, Python 2.6.4, PostgreSQL 8.3.8: all tests pass, with the same SKIP.

[cboos]

Ok, too bad for the few "Unable to get database connection" errors. Even if it occurs only in "extreme" conditions, this means we still have some work ahead of us on this topic, but probably for 0.12.x only ;-)

Other than that, the release seems quite robust.

The Latest Stable Release is now 0.11.6,
as tagged in tags/trac-0.11.6​.

A big Thank you to all the people who helped test this release!