is no longer taken from the 'title' property but from the new 'alt' property. 
        The border="0" attribute is no longer part of the HTML output except specified
        otherwise.

No commit message

Forward port form 2.7 branch.

medusa's class monitor_server derives from asyncore.dispatcher, but
never called the latter's constructor.  As a result, the ._map attribute
set by 2.4's asyncore.dispatcher.__init__() never gets set, and calling
asyncore methods later dies with an AttributeError on ._map.  The fix
is a 1-liner, adding a call to the base-class constructor.

  2.3.4 or later.

of using sys.platform

instead to all network addresses by default.

No commit message

Catalog.__len__ -> Catalog._length

       variable was included into the generated query if the 'optional' flag inside
       dtml-sqltest was set an if the value of the string was empty.

Collector #1350: segfaults under SessionRig stress tester.  Since we perform a unfortunate monkey-patch in here to ZODB's Connection class, and in doing so we override the "close" method of that class, we need to do all of the things that ZODB 3.3's "close" method does, which includes unregistering a synchronizer.

The Python fatal errors occur only in a debug build now.

In a release build, unghostify() raises a Python SystemError
exception if it detects insanity, and ghostify() ignores the
problem (as ZODB 3.2 did, although it looks like 3.2 ignored
the problem by mistake).  This isn't *good*, because the
system is insane.  But it can become insane only by breaking
absolute threading rules, and that "should never happen".
Unfortunately, hundreds of things can go wrong if it does
happen, and we can't detect most of them.

In ghostify() and unghostify(), trigger a fatal error if the
object is insane.  This prevents a segfault (or, worse, arbitrary
memory corruption) later.

The test suite isn't bothered by this, and neither is bringing
up a Zope and playing around with it.  The only known cause
appears to be threading problems related to Transience.py,
partly explained in issue #1350.  It should be impossible for
these fatal errors to trigger via thread-correct use of ZODB.

I don't expect to keep these fatal errors in the code; indeed,
I'm checking this in only in Zope's *copy* of ZODB.  The intent
is to help whoever can make time for 1350 know whether that
problem still exists, until that problem goes away.  Unfortunately,
it's not even possible to raise an exception from ghostify()
(it's a void routine that "can't fail"), so it takes an extreme
measure to catch the problem as soon as it's visible.

Changing to pickle protocol 2 has severe backward compatibility
implications; changes to ZODB should not be made from the Zope
trunk regardless.