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.

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!

handleUidAnnotationEvent from Products.CMFUID throws AttributeError

I stumbled over a weird error during a package setup, which turned out a PEBCAC error. The full traceback:

[...]
File "/home/roman/.buildout/eggs/zope.interface-3.6.3-py2.6-linux-x86_64.egg/zope/interface/adapter.py", line 583, in subscribers
    subscription(*objects)
File "/home/roman/.buildout/eggs/Products.CMFUid-2.2.1-py2.6.egg/Products/CMFUid/UniqueIdAnnotationTool.py", line 86, in handleUidAnnotationEvent
    uid_handler.unregister(ob)
AttributeError: 'NoneType' object has no attribute 'unregister'

I went throught my whole code and type setup unable to find the mistake I’ve made unless I saw the problem. I imported a configuration module for an ArcheTypes content type declaration from a separate package which was not declared in the setup.py of my new package, e.g.:

$ cat my.package.event.py
from separate.package.config import PROJECTNAME
from plone.directives.form import Schema

class IMyType(Schema): ...

If you stumble over this error, make sure your imports are sane.

How *not* to calculate a future date

This mail was in my Inbox today and I was puzzled at first:

When I tried to start Zope it returned an error:

DateError: Invalid date: (2022, 2, 29)


Apparently it only happend on a leap year and exactly on the 29th of
February. Checking the old code base (Python 2.4, Plone 3) revealed this:

DateTime.DateTime(
     DateTime.DateTime().year() + 10,
    DateTime.DateTime().month(),
    DateTime.DateTime().day())

*Doh!*. Python provides a timedelta (Python 2.4 Library reference) module which would be better for calculating future dates.

Update: Apparently others writing similar mistakes 😉 Microsoft’s Azure cloud down and out for 8 hours (via fefe)

Broken (Arche-)Type Installation in Tests

I’ve recently run into this issue, migrating some of the Plone 3 product code to Plone 4. Installing some of the old types in my tests ended in a


File "/projects/plone3/my.product/my/product/tests/test_users.py", line 19, in test_mycontent
self.portal.invokeFactory('GalleryFolder', 'spam', title='eggs')
[...]
File "/home/roman/.buildout/eggs/Products.CMFCore-2.2.4-py2.6.egg/Products/CMFCore/TypesTool.py", line 311, in constructInstance
raise AccessControl_Unauthorized('Cannot create %s' % self.getId())
Unauthorized: Cannot create GalleryFolder


Digging deeper I found out, that all of the product factories were gone. Any debugging finding the cause of this ended up in a nowhere, until I stumbled over some odd behavior. All my imports in the testing.py are sorted, e.g.:


from Products.CMFPlone.tests.utils import MockMailHost
from Products.MailHost.interfaces import IMailHost
from Products.SiteErrorLog.SiteErrorLog import SiteErrorLog
[...]
import zope.component


What I now found out by accident is, if you move the import of the MockMailHost to the end of the import block, your Archetypes types are installable again:


from Products.MailHost.interfaces import IMailHost
from Products.SiteErrorLog.SiteErrorLog import SiteErrorLog
[...]
import zope.component
from Products.CMFPlone.tests.utils import MockMailHost


I currently don’t know why, but if anyone had the time to check, I’d be happy to know.

AttributeError when Installing Custom Theme Package

If you’re creating a new Plone theme package based on plone.app.theming and run into the following error:

Traceback (innermost last):
  Module ZPublisher.Publish, line 126, in publish
  Module ZPublisher.mapply, line 77, in mapply
  Module ZPublisher.Publish, line 46, in call_object
  Module Products.CMFQuickInstallerTool.QuickInstallerTool, line 575, in installProducts
  Module Products.CMFQuickInstallerTool.QuickInstallerTool, line 512, in installProduct
   - __traceback_info__: ('my.skin',)
  Module Products.GenericSetup.tool, line 323, in runAllImportStepsFromProfile
   - __traceback_info__: profile-my.skin:default
  Module Products.GenericSetup.tool, line 1080, in _runImportStepsFromContext
  Module Products.GenericSetup.tool, line 994, in _doRunImportStep
   - __traceback_info__: plone.app.theming
  Module plone.app.theming.exportimport.handler, line 40, in importTheme
  Module plone.app.theming.utils, line 427, in applyTheme
  Module plone.registry.recordsproxy, line 43, in __setattr__
AttributeError: currentTheme

This will probably have nothing to do with a wrong setup in your theme, but simply a dependency issue to diazo.
Just make sure you install “Diazo theme support” before your theme is installed.

Reference: http://plone.293351.n2.nabble.com/plone-app-theming-1-0b5-and-Plone-4-1rc2-Plone-4106-td6418670.html

Debugging PosKey Errors in ZODB

I ran into a KeyError while packing a ZODB database in production. It lead me to a PosKey error while loading objects which did not exist anymore. For those of you in a similar situation here is what I found very helpful:

• Using zc.zodbdgc (fix PosKeyError’s)
• Fixing Broken ZODB Object references

Packages I’ve found useful:

• ZODB3 and it’s provided scripts (fsrefs, fsoids)
• zc.zodbdgc
• eye – a ZODB browser

Happy debugging!