I just found a very ugly problem that appears in Subversion when ErrorDocument 404 handler is enabled in Apache like this:
ErrorDocument 404 http://www.blah.com
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:
|
|
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:1234567891011121314151617181920212223(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... \ -Djava.security.policy=rvm.security \ \ BootImageWriter\ -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/RVM.map \ -ia 0x31000000JVMXM008: 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 1make: 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 sjbuild: 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.
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:
Oops...
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/core.py", line 531, in cgi_start
real_cgi_start()
File "/usr/lib/python2.4/site-packages/trac/core.py", line 513, in real_cgi_start
env = open_environment()
File "/usr/lib/python2.4/site-packages/trac/core.py", line 190, in open_environment
version = env.get_version()
File "/usr/lib/python2.4/site-packages/trac/Environment.py", 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/main.py", 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
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/
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 (http://example.com)
Apache logs show some more useful info:
[Sun Jun 26 17:21:32 2005] [error] [client xxx.xxx.xxx.217] (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
Here is a link describing upgrading from FC3 to FC4 using yum only. I’ve never done this before in this fashion, but hopefully it will work smoothly.
JBuilder 2006 will be Eclipse-based. This is the most exciting news I’ve heard in a while. Now it explains why Borland decided to throw so much weight behind Eclipse. Interesting questions now are how much this will influence projects like MyEclipse and how much stuff Borland will be willing to contribute outside of core Eclipse SDK in terms of various plug-ins for J2EE development for example.
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:
log in to your Subversion server, be sure you have appropriate (possibly root) privileges
stop Apache:
/sbin/service httpd stop
check whether it actually stopped:
ps axu | grep http
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/httpdbe sure to kill the remaining processes:
kill -9 5420 5423
fix the repository with svnadmin recover command:
svnadmin recover /var/www/svn/cp
change repository owner/group back to apache:
chown -R apache:apache /var/www/svn/cp
start Apache:
/sbin/service httpd start
Everything should work fine now.
I don’t know what kind of support policy Liferay advocates, but we are not going to use their product for the following reasons:
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.On Monday, MyEclipse 4.0M1 finally got released. Now in addition to Struts, JSF, and Hibernate, it supports Tapestry via Spindle integration and UML modeling. The next milestone should have Spring integration and graphical JSP designer. Well, let’s see how it goes.