[kforge-user] Plugin Patches and Some Questions

John Bywater john.bywater at appropriatesoftware.net
Wed Jan 12 11:34:32 UTC 2011


Hi Eitan,

Wow! Thank you very much for sharing all that. I'll go through it 
carefully and write you back properly soon...

Best wishes,

John.



Eitan Marder-Eppstein wrote:
> John and other KForgers,
> 
> I finally had some time to sit down and get a fully operational KForge setup
> up and running. In the process, there were a few things I ran into that I'd
> like to share with the community as well as a couple of questions I'd like
> to ask. I think that this type of thing lends itself well to bullets, you'll
> find them below:
> 
> - In order to get the moin plugin to work out of the box, I had to make a
> few modifications which included adding a "version" field to the "moin"
> section of the etc/kforge.conf file. There were three issues. First, the
> plugin didn't copy the underlay directory for the wiki correctly. Second,
> the plugin copies the moin.cgi file, but doesn't update it to point to the
> correct location. Third, in order for moin to find its stylesheet correctly,
> it was necessary to add an Alias to httpd-autogenerated.conf that depends on
> the moin version number, so I also read a "version" field now from
> kforge.conf. I've attached a patch to this e-mail with my changes for
> review.
> 
> - In order to get the git plugin to work, I had to change "cmd = 'cd %s; %s
> --bare init; git update-server-info; chmod +x hooks/post-commit' % (path,
> gitCmd)” to “cmd = 'cd %s; %s --bare init; git update-server-info' % (path,
> gitCmd)" in the git plugin. I'm not sure what is supposed to populate
> hooks/post-commit, but I didn't find it. I've attached a patch, this one I'm
> less sure about though... its possible that I've broken integration with
> Trac or something, so I'm not sure it should be applied.
> 
> - I ran into an error with Trac that I think someone trying to install
> KForge awhile back also ran into. Basically, things go well creating a trac
> service until you try to view the page and are greeted with a mod_python
> error that involves the following text: "Can't change extraction path, files
> already extracted". It turns out that the problem stemmed from the fact that
> psycopg2-2.3.2-py2.6-linux-x86_64.egg is installed zipped and is unzipped
> for me to /var/www/.python_eggs when the first query to the database is
> made. The trac plugin tries to set the extraction path for eggs to something
> other than /var/www/.python_eggs, but setup tools doesn't allow this because
> the psycopg2-2.3.2-py2.6-linux-x86_64.egg is already cached in a different
> location and the plugins are doing something like sharing a resource
> manager. I didn't dig too deeply into why this was the case, I just manually
> unzipped the psycopg2-2.3.2-py2.6-linux-x86_64.egg in site-packages so it
> wouldn't be cached and that fixed things. Is this something that people have
> seen before? I think it would only come up using postgres as a backend with
> psycopg2-2.3.2-py2.6-linux-x86_64.egg installed zipped.
> 
> - I couldn't use "sudo /etc/init.d/apache2 restart" for my "reload_apache"
> command. Doing this would cause apache to die anytime a new service was
> created from the web. Running the command as the www-data user from a
> terminal worked just fine, but running it through the KForge python scripts
> consistently caused apache to crash. I ended up switching to "sudo
> /etc/init.d/apache2 reload" which works fine, but doesn't work for reloading
> all plugin configurations. The mercurial plugin, for example, needs apache
> to be restarted... a reload won't cut it. So, in addition to reloading, I
> have a cron job that executes "sudo /etc/init.d/apache2 restart" every 5
> minutes. This works fine as I don't expect people to be creating new
> repositories all the time, but I was curious if anyone else had experienced
> this problem or had any insight into what might be going on. The apache logs
> don't show much, error.log just shows the server going down and it doesn't
> come up again. Actually, there's a more informative message when the reload
> command is run. I see the following in the apache logs even though the
> command seems to work: "kforge [ERROR] ApacheConfigBuilder: Apache reload
> command 'sudo /etc/init.d/apache2 reload' exited with non-zero status 256: *
> Reloading web server config apache2." Any ideas on what might be going on? Are
> people using the "restart" command with success?
> 
> Other than those issues, getting up and running was pretty painless. I'll
> also mention that I did all of this on a Ubuntu Lucid machine and am running
> the following plugins with success:
> 
> - dav
> - git
> - mailman
> - mercurial
> - moin
> - svn
> - trac
> - www
> 
> Hope all is well,
> 
> Eitan
> 
> 





More information about the kforge-user mailing list