Propfind 302 found error in Subversion

I just found a very ugly problem that appears in Subversion when ErrorDocument 404 handler is enabled in Apache like this:

ErrorDocument 404

Basically what it adds up to is that Subversion refuses to add any new files to a repository and shows propfind 302 found error if ErrorDocument 404 handler is enabled.

The solution is to disable special 404 error handling for Subversion directories with ErrorDocument 404 default:

<Location /repos>
DAV svn
SVNParentPath /var/www/svn
SVNIndexXSLT /svnindex.xsl
# Limit access to list of valid users.
# Require SSL connection for password protection.
# SSLRequireSSL
AuthType Basic
AuthName "Multiplex Systems Subversion Repository"
AuthUserFile /var/www/auth-file
Require valid-user
ErrorDocument 404 default

Linux PPC64 regression tests of Jikes RVM CVS head

For the time being Linux PPC64 regression tests of Jikes RVM CVS head will be started manually. I plan on doing this at least once a week.

The need for this arises from the fact that for some reason the host IBM Java SDK crashes during the build process if regression tests start as a cron job:

(built utility_kludge.jar) \
/opt/IBMJava2-ppc-141/bin/java \
-Xbootclasspath/p:/opt/regression/powerpc... -Xbootclasspath/a:/opt/regression/powerpc64-... \
-Xmx400M \
-classpath /opt/regression/powerpc64-unkn... \ \
-classpath /opt/regression/powerpc64-unkn... \
-n /opt/regression/powerpc64-unknown-linux-gnu/nightShadow/images/production/RVM.primordials \
-o /opt/regression/powerpc64-unknown-linux-gnu/nightShadow/images/production/RVM.image \
-demographics -m /opt/regression/powerpc64-unknown-linux-gnu/nightShadow/images/production/ \
-ia 0x31000000
JVMXM008: Error occured while initialising System ClassException in thread "main" Could not create the Java virtual machine.
make: *** [/opt/regression/powerpc64-unknown-linux-gnu/nightShadow/images/production/RVM.image] Error 1
make: Leaving directory `/opt/regression/powerpc64-unknown-linux-gnu/nightShadow/rvm/src/tools/bootImageWriter'
jbuild.linkImage: Exiting unexpectedly with status 2.
jbuild.linkImage: Cleaning up...
jbuild.linkImage: ...cleaned up.
69 s
jbuild: Trouble while running "./jbuild.linkImage -demographics"
(exit status 2); aborting execution

I’ve tried changing environmental variables of the cron job so they look exactly like those of a regular account, but it didn’t help.

The problem may have something to do with the 64-bit version of PPC Linux we have. It is one of the first pre-releases of 64-bit Yellow Dog Linux, which has a bunch of custom workarounds and kludges, including a custom-patched kernel 2.6.1

The long term solution I’d like to try is installing the latest Fedora Core 4, which does have 64-bit PPC kernel, and running the regression tests on top of that.

Trac problem after upgrading to Fedora Core 4

We’ve finally solved the last problem connected to Fedora Core upgrade from version 3 to version 4. After the upgrade our Trac stopped working completely with the following error message:


Trac detected an internal error:
file is encrypted or is not a database

Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/trac/", line 531, in cgi_start
  File "/usr/lib/python2.4/site-packages/trac/", line 513, in real_cgi_start
    env = open_environment()
  File "/usr/lib/python2.4/site-packages/trac/", line 190, in open_environment
    version = env.get_version()
  File "/usr/lib/python2.4/site-packages/trac/", line 162, in get_version
    cursor.execute("SELECT value FROM system WHERE name='database_version'")
  File "/usr/src/build/539311-i386/install//usr/lib/python2.4/site-packages/sqlite/", line 244, in execute
DatabaseError: file is encrypted or is not a database

We’ve finally tracked the problem to SQLite version 2.x vs 3.x

On Fedora Core 4, Trac uses SQLite 3.x although the trac.db database in conf directory is in version 2.x format. The solution is to manually upgrade all the Trac environment databases to version 3.x:

mv trac.db trac2.db
sqlite trac2.db .dump | sqlite3 trac.db

Cyrus IMAP server problem after upgrading to Fedora Core 4

The problem of Berkley DB 4.3 in Fedora Core 4 vs Berkley DB 4.2 in Fedora Core 3 hits Cyrus IMAP server also. Basically the server stops working showing mulptiple errors in the log:

Jun 26 20:01:44 mail imaps[3581]: DBERROR: critical database situation
Jun 26 20:01:44 mail master[3582]: about to exec /usr/lib/cyrus-imapd/lmtpd
Jun 26 20:01:44 mail lmtpunix[3582]: DBERROR ´ : db4
Jun 26 20:01:44 mail lmtpunix[3582]: DBERROR: critical database situation

The problem can be solved stopping the daemon and removing deliver.db and tls_sessions.db from /var/lib/imap and also erasing everything from /var/lib/imapd/db/

Subversion problem after upgrading to Fedora Core 4

The first problem we faced after upgrading from Fedora Core 3 to Fedora Core 4 was that Subversion repositories completely stopped working. The error message you get while trying to do something is the following:

svn: PROPFIND request failed on '/repos/ta2'
svn: PROPFIND of '/repos/ta2': 500 Internal Server Error (

Apache logs show some more useful info:

[Sun Jun 26 17:21:32 2005] [error] [client]
(20014)Error string not specified yet: Berkeley DB error while opening environment for filesystem /var/www/svn/admin/db: DB_VERSION_MISMATCH: Database environment version mismatch

The problem lies in the fact that Fedora Core 3 shipped with Berkley DB version 4.2, while the newest Fedora Core 4 utilizes version 4.3 The solution is described here and basically requires you to manually upgrade your Subversion Berkley DB repositories with db42_upgrade command:

db42_upgrade changes copies nodes representations revisions strings transactions uuids

Repairing broken Subversion repository

Somehow Subversion repository based on BDB tends to break at least in our case working on Fedora Core 3 with Trac 0.8.1 Usually an indication of this is either your Subversion client (TortoiseSVN, svn, etc) stops responding for no reason or you cannot browse any sources using Trac “Browse” link.

Here are the steps one need to take in order to fix this problem:

  1. log in to your Subversion server, be sure you have appropriate (possibly root) privileges

  2. stop Apache:

    /sbin/service httpd stop
  3. check whether it actually stopped:

    ps axu | grep http
  4. if you see something like this:

    apache    5420  0.0  2.0 17320 4556 ?        S    13:25   0:00 /usr/sbin/httpd
    apache    5423  0.0  2.0 17320 4564 ?        S    13:25   0:00 /usr/sbin/httpd
    be sure to kill the remaining processes:
    kill -9 5420 5423
  5. fix the repository with svnadmin recover command:

    svnadmin recover /var/www/svn/cp
  6. change repository owner/group back to apache:

    chown -R apache:apache /var/www/svn/cp
  7. start Apache:

    /sbin/service httpd start

Everything should work fine now.

Liferay Portal on Tomcat 5.5.x and Tomcat 5.0.x

I don’t know what kind of support policy Liferay advocates, but we are not going to use their product for the following reasons:

  • It seems impossible to find out how or whether it is possible to run Liferay Portal with Tomcat 5.5.x I’ve checked their mailing list, forum, web site - nothing. Some people asked about Tomcat 5.5.x back in February, but their questions remained largely conveniently ignored. Is that what open-source about? I don’t think so.
  • When I downloaded a standalone WAR and followed the instruction for installing the portal on Tomcat 5.0.x, I found out that the whole installation looks more like a nasty kludge. One has to modify Tomcat startup scripts and create additional ext directory in common/lib copying almost all Liferay JAR files there. Well this all would be fine, if it didn’t make it impossible for some other applications to work with the same copy of Tomcat. For example I have blojsom using log4j and for this purpose being deployed together with log4j JAR in its lib directory. Now installing (kludging) Liferay on the same Tomcat and putting Liferay log4j JAR into common/lib/ext breaks my blojsom. I realize that Tomcat is a pain to configure but if one cannot do it right for a product software then just don’t do it.