Deploying Plone 2 with a ZEO Server

At Mooball, there are still instances running with a CMFPlone v. 2. Very, very old. Back in the days when Plone v2 was shipped, Python 2.3 was hip and zc.buildout was never heard of.
One motivation I have to deploy with a ZEO is the possibility to pack your database from a simple cron script (which you configure in your buildout too). If you’re still one of them who has to deal with these old instances, here is what you do:

Use Python 2.3

I’ve always compiled my own python 2.3 to avoid any side effects introduced by python installations from the distribution. Version 1.2.1 of zc.buildout works fine for me, the only missing thing is the subprocess module introduced in python 2.4. To get buildout running, I’ve copied subprocess.py from python 2.4 into the python 2.3 installation. After that is done, run the bootstrap with (the -v pins the zc.buildout version to 1.2.1):

/path/to/python2.3/bin/python bootstrap.py -v1.2.1

Run with zc.buildout

I’ve created a sample buildout.cfg and put it up on gist. The important part is the ‘fixup’ which simply comments out 3 keys in the generated config files, which are not supported by the Zope/ZEO version. Depending how much time you have available, play with the options to pin eggs instead of dropping the whole CMFPlone tarball in the products directory. Running the buildout from the products directory is the quickest way tho.

GIMP plug-in debugging

I’m working now and then on the metadata browser for GIMP. This now and then can mean a serious gap where I don’t have time to contribute, which means I forget most of the commands for debugging.

The whole debugging story for plug-ins is very well documented in debug-plug-ins.txt. A quick debugging session goes like this:

Start GIMP with an environment variable which is set to the plugin name. After GIMP starts up and calls your plug-in, it stops and waits for the debugger:

GIMP_PLUGIN_DEBUG=metadata,run ~/gimpdev/bin/gimp-2.9 /tmp/hintergrund.jpg
This is a development version of GIMP.  Debug messages may appear here.
jpeg-load: found EXIF block (7686 bytes)

One thing I stumbled over today was the missing PID output (last line). Mitch mitchus figured out the problem. Depending on your version of libglib, you need to provide another environment variable since the logging handler changed:

G_MESSAGES_DEBUG=LibGimp GIMP_PLUGIN_DEBUG=metadata,run ~/gimpdev/bin/gimp-2.9 /tmp/hintergrund.jpg
This is a development version of GIMP.  Debug messages may appear here.
jpeg-load: found EXIF block (7686 bytes)
(metadata:14783): LibGimp-DEBUG: Waiting for debugger...

Now you can use the gdb to attach to the running process (14783) and debug it.

ZODB/ZEO Error Masking Wrong Filesystem Permissions

One of the clients staging instances showed quite a few tracebacks of that type:

Traceback (innermost last):
  ...
  Module zope.contentprovider.tales, line 77, in __call__
  Module zope.viewlet.manager, line 112, in update
  Module zope.viewlet.manager, line 118, in _updateViewlets
  Module my.product.viewlets.industry, line 29, in update
  Module Products.ZCatalog.Lazy, line 190, in __getitem__
  Module Products.ZCatalog.Catalog, line 121, in __getitem__
  Module ZODB.Connection, line 860, in setstate
  Module ZODB.Connection, line 901, in _setstate
  Module ZEO.ClientStorage, line 815, in load
  Module ZEO.cache, line 143, in call
  Module ZEO.cache, line 494, in load
  Module ZODB.fsIndex, line 125, in get
TypeError: mybrains.__cmp__(x,y) requires y to be a 'mybrains', not a 'NoneType'

I’m getting to the point, since it had something to do with the deployment. Some packages were deployed as develop eggs on the instance. Only a few files were created with the wrong filesystem permissions, so neither Zope nor ZEO were able to access them. After changing the permissions the errors were gone. So be sure to check all filesystem permissions and if the processes have access to them. If that doesn’t solve it, be sure to also check if not your database is corrupt.

z3c.autoinclude does not automatically include a plone package

Something I stumbled over just recently and is a PEBKAC again. What happens if you create a plone package and you always need to explicitly specify the zcml slot for that package? Check the namespace declaration in the setup.py. That means, what I had configured:

 namespace_packages=['mooball'],
 entry_points="""
 # -*- Entry points: -*-
 [z3c.autoinclude.plugin]
 target = plone
 """,

But the packages layout was “mooball.portlets.latestcontent”. After digging, I found out that simply the namespace_package is incorrectly declared. Changing it to:

 namespace_packages=['mooball', 'mooball.portlets'],
 entry_points="""
 # -*- Entry points: -*-
 [z3c.autoinclude.plugin]
 target = plone
 """,

… got it correctly included via z3c.autoinclude.

No such file or directory FakePlugin.egg-info

In case you run into a similar issue which ends up in a traceback like this:

ZopeXMLConfigurationError: File "/opt/works/projects/plone4/nuw.types/nuw/types/configure.zcml", line 12.2-12.37
ZopeXMLConfigurationError: File "/home/roman/.buildout/eggs/mooball.plone.activecampaign-0.2-py2.7.egg/mooball/plone/activecampaign/configure.zcml", line 10.2-10.37
OSError: [Errno 2] No such file or directory: '/home/roman/tools/python2.7/lib/python2.7/site-packages/tests/fake_packages/FakePlugin.egg/FakePlugin.egg-info'

you might have made the same mistake then I did: install ZopeSkel in your (system-) python installation. Never do this. Mikko explains on his blog why.

So, check your python installation and uninstall/remove the PasteScript.

GIMP for Absolute Beginners

“Write a book” was always on my list to do. Well, here it is:

The book focuses primarily on people who have no understanding of GIMP and digital image manipulation. That said, a few chapters also help you getting your graphics tablet setup and painting with GIMP. Most of the examples have been written with a MS Windows installation of GIMP. Don’t worry though, I was testing most of the examples under my GNU/Linux (Ubuntu) installation as well.

Jan Smith is the main author of the book. I like to thank Jan again for her countless effort to get this book published.
You can order the book from Apress or your favorite book dealer.

Could not initialize Opera

Just ran into a problem this morning since opera has been working up to Opera v. 12.

On start-up you get something like this:

captainmoonlite :: ~ » opera
Could not initialize Opera.

Running the startup script with strace reveals the culprit:

captainmoonlite :: ~ » strace opera
execve("/usr/bin/opera", ["opera"], [/* 71 vars */]) = 0
[...]
lstat("/home/roman/.kde/share/config/kcmnspluginrc", 0x7fffbd443080) = -1 EACCES (Permission denied)
write(2, "Could not initialize Opera.\n", 28Could not initialize Opera.

After fixing the permissions of .kde/share/config, opera started just fine. Opera v.11 must have not accessed this directory or file. strace FTW!