Recently in debian Category

I am using zc.buildout together with a virtualenv to generate my Plone instances. It turns out that Zope requires the Python Profile be installed. However, under Debian, the relevant package, python-profiler has made it to non-free instead of main, due to the licensing of that package. As a result, you only discover that testing doesn’t work until Zope tries to import the profiler, and falls over.

In order to get things to run, you need to do the following:

# Add non-free to the set of repositories that you want to use. Eg.:

  deb http://ftp.debian.org/debian stable main

would have to become

  deb http://ftp.de.debian.org/debian stable main non-free

# Run apt-get update (obviously). # Now you can apt-get install python-profiler, and you should be all set.

As per the author’s statement, using ZopeProfiler together with Plone4 is unsupported. It really is. First, get a current version of ZopeProfiler instead. Implement in your buildout as usual and run buildout. In the relevant instance’s (eg. secondary) zope.conf, one has to enable it, too:

enable-product-installation on

You also need to fix the output from the pstats module. In Debian, this is located at /usr/lib/python2.6/pstats.py. Copy to your virtualenv’s lib/python2.6 and manually apply the patch mentioned here: http://bugs.python.org/issue7372

After that, following the instructions generally works, except for that the site now runs orders of magnitudes slower, and (at least) I get this error when trying to view the stats (sample traceback):

2011-05-04 13:47:56 ERROR Zope.SiteErrorLog 1304509676.940.218731970327 http://localhost:9082/Control_Panel/ZopeProfiler/showHigh
Traceback (innermost last):
  Module ZPublisher.Publish, line 127, in publish
  Module ZPublisher.mapply, line 77, in mapply
  Module ZPublisher.Publish, line 47, in call_object
  Module Shared.DC.Scripts.Bindings, line 324, in __call__
  Module Shared.DC.Scripts.Bindings, line 361, in _bindAndExec
  Module App.special_dtml, line 185, in _exec
  Module DocumentTemplate.DT_Let, line 76, in render
  Module DocumentTemplate.DT_Util, line 202, in eval
   - __traceback_info__: stdnameRe
  Module <string>, line 1, in <module>
  Module Products.ZopeProfiler.ZopeProfiler, line 237, in getStatistics
  Module pstats, line 353, in print_stats
ValueError: I/O operation on closed file

I’ve seen the latter error on various other occasions as well, esp. when a long time has passed between the original activity and the display of results (eg. when running ExternalMethods). If someone has a fix for that, I’d highly appreciate it!

After writing how to Install Plone4 on Debian/Lenny, I thought I’d follow up with an update for Debian Squeeze (please look into the upper right cornder), which is what I’m currently using.

The good news: After having many software packages updated on Squeeze, You basically don’t need much extra software to run Plone4. Install some required packages. using apt-get or aptitude. The following set should get you started, although it will pull in a significant number of dependencies:

# aptitude install python2.6-dev python-virtualenv python-setuptools build-essentials

After that, you simply create your virtualenv, like before:

$ virtualenv --no-site-packages vplone

and populate that:

$ source vplone/bin/activate
(vplone)$ easy_install PIL paste lxml ZopeSkel

Now you create your Plone buildout directory along the lines outlined on plone.org, but you can, of course, substitute plone4_buildout for the plone3_buildout (both should work).

I personally prefer to have a local versions.cfg, too, so I change my buildout.cfg to read eg.

extends = 
    base.cfg
    versions.cfg

and fetch an appropriate versions.cfg from http://dist.plone.org/release/. After that, you should be ready to run your buildout and get the ball rolling, like eg.

(vplone)$ buildout
... lots and lots of output clipped...

Watch out for any error messages which might be flushed out of the terminal window by the dumping of the eggs list.

At my workplace, there are two options to host applications like Plone: One is OpenBSD, and the other is Debian. In a commercial hosting setup, you may prefer to use stable and supported systems over running your business-critical machines on software in various states of ‘unstable’ and ‘unsupported’, or whatever the respective lingo for systems with state_in_flux and we_wont_really_help_you is. For this project, the decision was to host the application on a Debian system.

After unsuccessfully trying the Unified Installer packages several times and subsequently receiving unanimous advice from seasoned members of the Plone community against using them, I decided to try to install Plone4 the old-fashioned way, using a system Python and a conventional buildout. But there would be little point in this writing if Lenny would support that out of the box.

Reading the documentation for Plone4 and skimming through the appropriate versions.cfg file, the following core requirements surface:

• Python 2.6
• setuptools 0.6.11
• virtualenv

Since we want to be able to upgrade our system later, having these things in the form of Debian packages should be the preferred situation. For Python2.6, I used the backport packages I created. These also require libdb4.7, which is not in Lenny as well, and so also requires a backport.

To be able to properly create backports and install them in a way that Python2.6 can see them, one needs to edit the file

/usr/share/python/debian_defaults

to supplement the list of python versions with ‘python2.6’. I didn’t discover this by myself, but lost the link to the article which explained this. It is also required to change the file

/usr/lib/python-support/private/pysupport.py

to include python2.6 there, too.

The prerequisite Zope 2.12.10 requires the package ‘python-profiler’ to be present as well, as otherwise, an import statement fails. I didn’t investigate how strong this dependency really is, but simply provided a backport for python-profiler. So, creating all the backports, also for python-imaging 1.1.6, requires that one wades through all the files under ./debian and manipulate the dependencies to claim compatibility also with Python2.6. The software itself seems to be mostly suitable for this, but many packages explicitly, and imho wrongly, state that they are not compatible with Python2.6. If you don’t do this, packages will not include any Python2.6 versions of their libraries and what-not, and thus not function in a Python2.6 environment. To a very large extent, this package-rebuilding is only required to make them Python2.6-aware.

I fudged and installed the virtualenv and setuptools package under /usr/local after getting the basic Python2.6 packages installed, but I consider undoing the damage with additonal, to-be-created, backports.

After getting all the required packages installed, I created a virtualenv before doing anything else. Inside that, I then installed the remaining packages like eg. zc.buildout and ZopeSkel, using easy_install . After that, you are ready to create a new standard Plone3 project using the familiar paster invocation, but then replace the ‘versions.cfg’ with the one fetched from http://dist.plone.org before running buildout.

[Update 2011-02-17]
If you are also going to run tests under roadrunner, you need the python-profiler package. Don’t forget to update your virtualenv to point to these files, too, otherwise roadrunner will complain.

[Update 2011-04-20]
There is an update for Squeeze.