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

• 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!

    raise ConfigurationError("Unknown directive", ns, n)
zope.configuration.xmlconfig.ZopeXMLConfigurationError: File "/opt/works/projects/plone4/apf.buildout/parts/instance/etc/site.zcml", line 16.2-16.23
ZopeXMLConfigurationError: File "/home/roman/.buildout/eggs/Products.CMFPlone-4.1-py2.6.egg/Products/CMFPlone/configure.zcml", line 99.4-103.10
ZopeXMLConfigurationError: File "/home/roman/.buildout/eggs/plone.app.dexterity-1.0.3-py2.6.egg/plone/app/dexterity/configure.zcml", line 16.4-16.52
ZopeXMLConfigurationError: File "/home/roman/.buildout/eggs/plone.directives.dexterity-1.0.2-py2.6.egg/plone/directives/dexterity/configure.zcml", line 3.4-3.35
ZopeXMLConfigurationError: File "/home/roman/.buildout/eggs/five.grok-1.2.0-py2.6.egg/five/grok/configure.zcml", line 15.2-15.40
ZopeXMLConfigurationError: File "/home/roman/.buildout/eggs/grokcore.viewlet-1.8-py2.6.egg/grokcore/viewlet/configure.zcml", line 7.2-7.44
ZopeXMLConfigurationError: File "/home/roman/.buildout/eggs/zope.contentprovider-3.7.2-py2.6.egg/zope/contentprovider/configure.zcml", line 12.4
ConfigurationError: ('Unknown directive', u'http://namespaces.zope.org/tales', u'expressiontype')

… and you are using plone.app.theming and dexterity you will want to
check your buildout configuration file.
Make sure you have the dependent configuration files included:

extends =

http://dist.plone.org/release/4.1/versions.cfg

http://good-py.appspot.com/release/dexterity/1.0

http://good-py.appspot.com/release/plone.app.theming/1.0b8

The above configurations can change with future plone releases.

Lets say you’ve reset your repository to specific commit in the past:

$ git reset --hard b0f7f7e600b1add7d27cc6794c68ec332a8eb90e

Now the latest commit is obviously b0f7f7e600b1add7d27cc6794c68ec332a8eb90e and all newer commits seem to be gone. You can figure out the SHA id of your previous HEAD with the reflog:

$ git reflog
c8b2660 HEAD@{0}: commit (amend): Bla foobar
780cd51 HEAD@{1}: commit: updated HEAD
...

Your previous HEAD should be among those entries in the reflog. Look for the ‘updated HEAD’ commit. In my example it’s HEAD@{1}. Pick the SHA of the commit you think was the previous HEAD and reset the repository again:

$ git reset --hard 780cd51

References:

• How to delete the old history after running git filter-branch? (Stack Overflow)
• Detach subdirectory into separate Git repository
  

In case you’re running in an error on your Plone site which looks similar to this:

File "[...]/eggs/Products.ResourceRegistries-2.0.3-py2.6.egg/Products/ResourceRegistries/browser/scripts.py", line 27, in scripts
 content = registry.getInlineResource(script.getId(), context)
 File "[...]/eggs/Products.ResourceRegistries-2.0.3-py2.6.egg/Products/ResourceRegistries/tools/BaseRegistry.py", line 840, in getInlineResource
 output = self.getResourceContent(item, context)
 File "[...]/eggs/Products.ResourceRegistries-2.0.3-py2.6.egg/Products/ResourceRegistries/tools/JSRegistry.py", line 246, in getResourceContent
 output = BaseRegistryTool.getResourceContent(self, item, context, original)
 File "[...]/eggs/Products.ResourceRegistries-2.0.3-py2.6.egg/Products/ResourceRegistries/tools/BaseRegistry.py", line 589, in getResourceContent
 method = obj.browserDefault(self.REQUEST)[0].__name__
 File "[...]/eggs/zope.browserresource-3.10.3-py2.6.egg/zope/browserresource/file.py", line 94, in browserDefault
 return getattr(self, request.method), ()
 AttributeError: 'DirContainedFileResource7' object has no attribute 'POST'

Check if some of your javascripts have inline rendering enabled and obviously disable it. This seems to be more like a work around rather than a fix. Haven’t had time to investigate what was really going wrong there. Any additional pointers welcome!

While:
  Installing.
  Getting section instance.
  Initializing section instance.
  Loading zc.buildout recipe entry plone.recipe.zope2instance:default.

An internal error occured due to a bug in
either zc.buildout or in a recipe being used:
Traceback (most recent call last):
  [...]
  File "/home/roman/.buildout/eggs/
        zc.buildout-1.4.3-py2.4.egg/zc/buildout/buildout.py",
        line 1009, in _install_and_load
    return pkg_resources.load_entry_point(
  File "build/bdist.linux-x86_64/egg/pkg_resources.py",
        line 305, in load_entry_point
  File "build/bdist.linux-x86_64/egg/pkg_resources.py",
        line 2243, in load_entry_point
ImportError: Entry point ('zc.buildout', 'default') not found

I tried to recompile my python 2.4 (because the OS was just newly installed and my lack on a few dev libraries), pin to different buildout versions but couldn’t figure out what was wrong in the finish.

What I ended up doing in the finish, was:

1. remove my shared buildout directory (e.g. $HOME/.buildout)
2. rerun a buildout, which created the eggs directory in the buildout directory which seem to work fine
3. canceled the local buildout run,
4. recreated the shared buildout directory with my default configuration (e.g. $HOME/.buildout, $HOME/.buildout/default.cfg and $HOME/.buildout/eggs)
5. rerun the buildout now using the global eggs directory (e.g. $HOME/.buildout/eggs)

Another thing which I’ve noticed, is that zc.buildout does not have a ‘default’ entry point. I checked releases of zc.buildout back to 1.0. I wonder why it seems to be so arbitrarily being loaded that it works sometimes and sometimes not.

Ah … and btw. always a good one: Sometimes removing the .installed.cfg (it’s hidden with a dot in front!) helps as well.

Now, I remember having used Selenium before, but

• it was a nuissance to setup, esp to work nicely with a Plone TestCase
• getting it setup in a continous integration environment was quite some work too.

Motivation

With Plone 4, a new testcase component is implemented which made it much, much, much easier to write tests for Plone packages. The gocept.selenium packages wraps Selenium in a nice compatible package and provides test classes for Zope2, Plone and Zope3 tests. The result is, that the setup and maintainance of tests with selenium became much, much easier as well.

The only missing piece was the continious integration (CI) environment. I’m running all tests of the packages I develop at Mooball in Hudson continously. Being also able to run all Selenium tests would be a big, big plus. But without an X server, you can’t run a browser, which is essential to run the tests.

I didn’t like the idea of installing a complete X environment on my CI server, so I searched around and found these articles to run Selenium tests without requiring a complete X server installed:

• Hudson and SeleniumTest Suite
• How To: Run Selenium Tests with Hudson on a Headless Linux Server, Part One–Xvfb

There are more around, but they helped me getting started.

Problem

My main questions were:

1. How to run the selenium server? Start the server for each build or leave it running as a daemon in the background?
2. Run an X server (e.g. Xvfb) or an X server with a VNC server, because Hudson already provides plug-ins for the VNC server?
3. Run the X server per build or leave it running in the background?

My Solution

1. Selenium Server

I configured the selenium server to run as a daemon. Starting/Stopping the server per test would be too resource intensive and perhaps unreliable. So I came up with a small init script. It allows me to start the selenium server at boot time and keep it running.

2. + 3. The X Server

I opted for installing Xvfb and thought first about starting/stopping it per build, but here again, I think it becomes a nuisance and too unreliable if the server for whatever reason doesn’t start up or crashes. I created another init script to keep the Xvfb running. Note though, I don’t disable the access permissions to connect to Xvfb as most of the other blog articles do.

Installation

The installation is actually pretty much straight forward:

1. Install java and selenium-server (I preferred /opt)
2. Configure the init script variables (port, paths, browser, etc). I for one prefer to run firefoxchrome, which works fine for me.
3. Install Xvfb and adjust the init script variables.
4. Start both servers. If you’re running your tests with gocept.selenium, follow the installation instructions on the packages pypi page.

That’s it. Any suggestions and updates are welcome

Byobu runs custom commands

I’ve converted my former screen script to run as a custom script in byobu, but it suddenly stopped working. I was wondering why and found a way to see what the problem was.

What you need

My script scans my mail directory and checks for new mail. I placed it in my home directory under:

$ ls /home/roman/.byobu/bin
3_maildircheck

Debugging

The following points should give you a clue why your custom script won’t work with byobu:

1. Check if you have enabled custom scripts in byobu (press F9 in a byobu session).
2. Run the custom command by itself from the plugins directory, not from your home directory. The plugins directory is located under Ubuntu in /usr/lib/byobu/custom.
3. The output of custom scripts are written to a cache file under /var/run/screen. Check what the cache files tell you.

The problem

I had a custom content-type which was partly indexed. When viewing the content type, parts of the edit form showed raw HTML code instead of widgets:

What was going on?

The solution

I hunted around for a while but checked the contents of the index. Strangely, it had a whole page indexed. After investigating further: it’s another object in the portal with the same id as the attribute on the content-type. The error happens only, if the attribute is missing on the content-type and an object in the hirarchy above has the name id.

So – if you encounter a problem like this, check if the portal_catalog may grab a different object for indexing with the same name of your attribute.

The Problem

Nevertheless, I still had troubles with ImageMagick. If you want to convert PDFs to images for example, the installed ghostscript version was unable to lookup certain font files resulting in an error similar to this one:

Error: /invalidfont in findfont
Operand stack:
   Arial-ISO   Arial-ISO   Arial   Font   Arial
Execution stack:
   [...]
Dictionary stack:
  [...]
Current allocation mode is local
Last OS error: 2
Current file position is 279
GNU Ghostscript 7.05: Unrecoverable error, exit code 1

The Solution

I hunted around in the system. Apparently ghostscript still uses a fontmap to lookup fonts. The question is which fontmap was in use. I tried to change the fontmap in /etc/ghostscript which had no affect.

I finally found a bogus fontmap under

/usr/share/ghostscript/8.70/Resource/Init

which provided all font entries and aliases, but none of the aliases had a font file associated with it. For example, Helvetica-Bold pointed to NimbusSanL-BoldCond, but NimbusSanL-BoldCond had no pointer to an existing font file in the file system. It was simply missing.

The Fix

I got it now working with this in /usr/share/ghostscript/8.70/Resource/Init:

%!
% See Fontmap.GS for the syntax of real Fontmap files.
%% Replace 1 (Fontmap.GS)
/NimbusSanL-Regu        (n019003l.pfb)  ;
/NimbusSanL-ReguItal    (n019023l.pfb)  ;
/NimbusSanL-Bold        (n019004l.pfb)  ;
/NimbusSanL-BoldItal    (n019024l.pfb)  ;

/NimbusSanL-ReguCond    (n019043l.pfb)  ;
/NimbusSanL-ReguCondItal        (n019063l.pfb)  ;
/NimbusSanL-BoldCond    (n019044l.pfb)  ;
/NimbusSanL-BoldCondItal        (n019064l.pfb)  ;

(Fontmap.GS) .runlibfile

References:

• Scribus: http://docs.scribus.net/index.php?lang=en&page=gsfont