This is an update to the post

NSIS (Nullsoft Scriptable Install System) “is a professional open source system to create Windows installers.”

NSIS 3.0 has been released on 25th July 2016:

I have now packages for CentOS7 and Fedora 24: You can find instructions on that page how to install the rpms.

The sources for the package are available here:

I am using this for example to build nightly installers for OpenPetra standalone for Windows, and the build happens on CentOS7: The sources for the installer can be found here: standalone.nsi


Tags: , , ,
Posted in Software Development | Comments Closed

For OpenPetra, I wanted to build the installer for the Windows Remote Client on CentOS.

I know that NSIS (Nullsoft Scriptable Install System) is available for Debian, but I could not find a recent RPM package of NSIS for CentOS.

So I built my own RPM package for the latest stable version of NSIS, version 2.46, using the LightBuildServer. You can see the project here:

The sources for the package are hosted at Github:

You can install the RPM on CentOS 6 like this:

cd /etc/yum.repos.d/
yum install nsis

I use this NSIS RPM package to build OpenPetra in this LBS job: openpetra-server-test, and the sources are available at Github: openpetra-server-test sources.

By the way, the installer source for the OpenPetra remote client can be found here: remote.nsi

Please let me know if you want me to build NSIS for other CentOS versions too.

The source rpm is available here:

Tags: , , ,
Posted in Software Development | Comments Closed

OpenPetra standalone and SQLite   July 30th, 2014

I have seen on the OpenPetra IRC logs that there have been discussions about SQLite related to the new 0.3.0 release.

2 main points:

  1. functionality does work with PostgreSQL, but not with SQLite
  2. no documented upgrade path for SQLite, which is used in OpenPetra standalone

Regarding the first point:

I think it is good to support several databases, because it helps to find bugs, or unclean development. For example PostgreSQL is not so strict with transactions, but SQLite shows us when the transactions have not been opened correctly.

Another advantage: In the future there might be support for even more databases, for example MS-SQL. Then we will be in trouble with SQL code that uses PostgreSQL specific syntax. So it is good to find these problems now and solve them when the developer who wrote the SQL still knows about it.

To solve these issues, I think it is important to maintain automated integration for the winform screens. After all, we have a nightly build of the integration tests every night running against both PostgreSQL and SQLite separately. That way we should find such issues quite soon.

The second point, with the upgrade path:

There has been work on doing an upgrade of the database during the installation of the new OpenPetra standalone version, see and

Unfortunately, this caused too much trouble, and since the standalone installer is only intended for demo purposes, we did not support this upgrade functionality any longer.
For the longterm, the question is anyway whether the standalone installer should be maintained by the community and not by OM anymore, since OM focuses on the client/server solution with PostgreSQL rather than SQLite for production. When we had the discussions about the web services branch, support for the current standalone installer would have been dropped anyways by OM, because that would still quite some work to make it work with the single exe application.

Currently the only way is to export the data in the OpenPetra client of the previous version (login as user SYSADMIN, go to SystemManager, Database, Import/Export, Export all Data).

Then install the new OpenPetra standalone. You would get this message box when starting OpenPetra:

Unsupported upgrade: Please rename the file C:\Users\tpokorra\AppData\Roaming\OpenPetra.org0.2.28.1\db30\petra.db so that we can start with a fresh database!
Please restart the OpenPetra Client after that.

So follow this instruction, and start with a fresh database. Login with user SYSADMIN again, and import your database that you just exported earlier (SystemManager, Database, Import/Export, Restore Database from Backup)

I am personally more interested in hosting OpenPetra in the future on my own servers for free for individuals or a small hosting fee for organisations. Therefore I am not going to invest a lot into the Standalone installer.

Tags: ,
Posted in Software Development | Comments Closed

I have been reading the book “Producing Open Source Software – How to Run a Successful Free Software Project” by Karl Fogel over the past weeks. It is available for free here:

I especially liked the chapters about being open:

Fogel’s point is that if you want to run your project as an open source project, it is better to start early with being open, ie. to have your code publicly available, have discussions in the public, offer demo data for everyone to use, etc.

Please read the short paragraphs linked above, they are well worth reading!

I think we have been quite ok with the OpenPetra project regarding these points:

  • we have a nightly build of the standalone installer
  • we have several demo databases
  • we have a public bug tracker
  • we have an IRC for immediate discussion (although only during working hours in Europe)
  • we have a public wiki and a public forum for discussions
  • we have quarterly (?) news updates on the announcement mailinglist
  • we have Twitter integrated on the website, which is irregularly updated with news items
  • the weekly phone conference is open on invitation basis
  • … and probably some more points that I did not think of at the moment but are still important!

Unfortunately, since Sourceforge did shutdown the hosted applications, our wiki and forum are available only read-only.

My suggestion for the future: Since the forum was not much frequented, I think it might be enough to have a mailinglist where all developers are subscribed. Sourceforge still offers free mailinglists. Mailinglists are the most common way of discussion among developers in the open source community. For users perhaps a forum is more common, but we are not there yet at this point. We can create a separate mailinglist or forum for users when the time comes that we have users of OpenPetra.

I also want to say why I think especially for OpenPetra it is very important to being open:

In the past years, there has been discouragement because the project has invested into potential volunteering developers a lot, but then they vanished before even committing a single line of code. Or they have committed code, that had to be reverted because of poor quality or other misunderstandings.
This makes my point: most of the time, the conversation with these people was in private, not in public. So there was no chance of a peer review from other developers. This might have excluded the new people from the developer community, and they did not get positive feedback. And all the conversation is lost, no other potential developer can learn from it, and for the next person you would have to do it all over again.

Please can we continue to be open in the OpenPetra project, and become better at it!

It saves us all a lot of time, and encourages everyone! You can see what is happening. This also makes the project interesting for outsiders and potential contributors.

I think, one single organisation needs to put in a lot of resources, to make such a huge project like OpenPetra happen. It is worth the effort of being open, if eventually other organisations or individuals get drawn in and share the work load.
This is a gradual process of course, but it is worth continuing it.

Tags: , ,
Posted in Software Development | Comments Closed

This is an updated version of the post Install OpenPetra.Now 2014-05 on CentOS5.

Now we are installing on CentOS6, and using my own LBS repository. OpenPetra.Now is now using the unmodified Mono-opt packages.

OpenPetra.Now is a tagged revision of the official OpenPetra, plus some patches which have not made it into the official OpenPetra yet. This includes a replacement of .Net remoting with https webservices, and a plugin system.

These are the instructions:

Install the Epel repository, the Postgresql repository and my OpenPetra repository.

For Postgresql, have a look here:

Epel Repo (for lighttpd): see

For the mono-opt repository, have a look here:

rpm -Uhv
rpm -Uhv
cd /etc/yum.repos.d/

Now install the packages (this will automatically also install the packages mono-opt, postgresql92, lighttpd and some other dependencies):

yum install openpetranow-server

Now configure the OpenPetra server, and start it:

/etc/init.d/openpetra-server init
chkconfig openpetra-server on

To test the server, connect to http://<yourhostname>/openpetra9000/serverSessionManager.asmx

Tags: , , ,
Posted in Software Development | Comments Closed

OpenPetra.Now is a tagged revision of the official OpenPetra, plus some patches which have not made it into the official OpenPetra yet. This includes a replacement of .Net remoting with https webservices, and a plugin system.

For an installation which involves upgrading from the old Petra 2.3 every night, I had to install OpenPetra.Now on a CentOS5 based system.

These are the instructions:

Install the Epel repository, the Postgresql repository and my OpenPetra repository.

If you have a 64 bit system, the links will be different.

For Postgresql, have a look here:

For the mono-openpetra repository, have a look here:

rpm -Uhv
rpm -Uhv
cd /etc/yum.repos.d/

Now install the packages (this will automatically also install the packages mono-openpetra, postgresql92, lighttpd and some other dependencies):

yum install openpetranow-server

Now configure the OpenPetra server, and start it:

/etc/init.d/openpetra-server init
chkconfig openpetra-server on
Tags: , , ,
Posted in Software Development | Comments Closed

This blog post is a repeat of an email that I sent to the Mono mailing list back in July 2013:

The problem is that there are no recent packages for the major Linux distributions offered at and

I personally use Mono and MonoDevelop for developing and deploying OpenPetra, an open source accounting and contact management system for charities and missions organisations.

I am using the OBS (Open Build Service) from to build recent packages of Mono and MonoDevelop for the Linux distributions CentOS, Fedora, Debian, Ubuntu, and openSUSE.

The installation for MonoDevelop is documented here:
This will install Mono as well.

I also have builds of the Beta and the Alpha versions of MonoDevelop.

If you only want to install Mono, see here:

There are also packages for mono-xsp, mod_mono and mono-tools (including monodoc).

Package mono-libgdiplus makes sure that the libgdiplus is linked properly, which is important for GUI applications.

Since you have the right repo from installing Mono already, you can just run this:

#for RPM based distros:
yum install mono-libgdiplus-opt mod_mono-opt mono-xsp-opt mono-tools-opt

or (please note slightly different name for mod_mono-opt, somehow Debian does not like the underscore in the package name…)

#for Debian based distros:
apt-get install mono-libgdiplus-opt modmono-opt mono-xsp-opt mono-tools-opt

MonoDevelop and Mono (and the other mono specific packages) will be installed to /opt to avoid conflict with the Mono version that comes with your Linux distribution.

To run this Mono on the command line, you can add this line to your .bash_profile file:

 . /opt/mono/

If you are interested in the way how the packages are built, have a look here:

Install OpenPetra on Linux   November 15th, 2013

Installing OpenPetra on Linux should be fairly easy.

Please note that the server works fine on Linux, but the client is not yet fully reliable. But the more interest and fixes it gets, the chances are higher that the client will become stable on Linux too.

We need for the server a patched version of Mono, for the .Net remoting. In the future we aim to switch away from .net remoting to https, but that is still experimental.
The client should be fine with Mono 2.10 upwards.

Install Mono 3.2.3 with OpenPetra patches:
The mono-openpetra package is available for Debian, Ubuntu and CentOS from
Please follow the instructions there for installing Mono.

I will do this tutorial with Ubuntu LTS 12.04 (precise):

apt-key add - &lt; Release.key echo 'deb /' &gt;&gt; /etc/apt/sources.list.d/mono-openpetra.list
apt-get update
apt-get install mono-openpetra

Next thing is to install Postgresql 9.1:

apt-get install postgresql

Now you download the latest release of OpenPetra for Linux from Sourceforge OpenPetra Downloads:

wget -O openpetraorg-server-debian-postgresql-MyOpenPetra-

There is also a package available for CentOS/RedHat based distributions:

wget -O openpetraorg-server-centos-postgresql-MyOpenPetra-

By the way, the code for this release is currently maintained here:

Now, unpack your server tar.gz file:

tar xzf openpetraorg-server-debian-postgresql-MyOpenPetra-
cd openpetraorg-
# have a look at the INSTALL file
# have a look at; we are not configuring the .net remoting keys at the moment

Next thing, you initialise the database:

/etc/init.d/openpetraMyOpenPetra createdb
/etc/init.d/openpetraMyOpenPetra init
/etc/init.d/openpetraMyOpenPetra start

If you get an error like “Possible cause: Npgsql.NpgsqlException: Failed to establish a connection to ‘localhost’.”, try to edit /etc/postgresql/9.1/main/postgresql.conf and enable listen_addresses = '*'. Then service postgresql restart. I don’t currently know why this is necessary on my computer.

Now you should download an empty database, or a demo database from Sourceforge Demo Databases:

wget -O /tmp/demoWith1ledger.yml.gz

Then load this database:

/etc/init.d/openpetraMyOpenPetra loadYmlGz /tmp/demoWith1ledger.yml.gz

Please note that the path for the demo file must be readable by the user that the openpetra server is running under, that is why I am using the /tmp directory.

For the OpenPetra client on Linux, you also need to install mono-openpetra-libgdiplus:

apt-get install mono-openpetra-libgdiplus

Get the linux client, and unpack it:

wget -O openpetraorg-client-MyOpenPetra-
tar xzf openpetraorg-client-MyOpenPetra-
cd openpetraorg-

At the moment, the communication between client and server is not encrypted. This can be enabled though, or you can use a VPN.
We are working on switching to https, replacing .Net remoting in the near future.

To connect the client to another server than localhost, you need to modify the file etc30/PetraClientRemote.config in the client directory, search for localhost and replace it with the hostname of your server! You might need to work on the firewall settings of the server, to allow communication on port 9000, or change to a more common port, eg. 80.

Known issues in the OpenPetra client for Linux:

  • There will be a message, that the patches cannot be found. Please ignore that, and try to login with user demo and password demo!
  • Partner Find layout of the window is broken.  Sometimes it does not find partners, says: no criteria. Workaround: tab out of current control. It worked for me the second time I opened the Find partner screen.
  • Partner Edit screen: also gives lots of errors. Cannot close without saving, when saving complains about empty address.
    The finance screens (Gift Batch, GL Batch, etc) might work better.

The question is: should we invest into the fat OpenPetra client to run on Linux and on Mac, or should we work on a client running in the browser, eg. based on Twitter Bootstrap, see the OpenPetra Demo with Twitter Bootstrap!

Tags: ,
Posted in Software Development | Comments Closed

Easy start for OpenPetra developers   October 18th, 2013

Steps to reproduce the video tutorial:

  1. See full instructions in OpenPetra Wiki
  2. Make sure .Net 4 is installed
  3. Install SharpDevelop
  4. Install NAnt
  5. Install 7zip
  6. Download and unzip nightly build of OpenPetra
    Update August 2015: the nightly build is now hosted at Github, we are not using Sourceforge for this anymore
  7. Start the Developers Assistant: Start the server, start the client, build OpenPetra
  8. Open the solution file delivery\projects\sharpdevelop4\OpenPetra.Server.sln in SharpDevelop
Tags: , , ,
Posted in Software Development | Comments Closed

This is a summary of the thread in the OpenPetra Forum:  mirroring bzr to github

The goal is to get all the version history of lp:openpetraorg into a repository at Github.

I have started mirroring our bzr trunk to a github repository, mainly so that I can host private branches of my customers (including configuration etc) at Github (, which is cheaper than Launchpad commercial plans (

The initial checkout for git is much faster than bzr for some reason.

But it also has some benefits for the development team:
You can use the better history of files for example: … Service.cs
Bazaar messes up the history of a file quite badly by mentioning any merge that is related to a file by some means, which makes it very confusing.

I am using this script:
Blog Entry by Felipe Contreras about the bridge script
Source of

Here are the commands that I am using (on CentOS):

Get the script:

chmod a+x
sudo mv /usr/bin/git-remote-bzr

install latest bzr:

sudo yum -y install gcc python-devel
tar xzf bzr-2.6.0.tar.gz
cd bzr-2.6.0
sudo python install
cd ..

install latest git:

sudo yum -y install curl-devel expat-devel gettext-devel openssl-devel zlib-devel perl-ExtUtils-MakeMaker
tar xzf git-1.8.4.tar.gz
cd git-1.8.4
make prefix=/usr/local all
sudo make prefix=/usr/local install
cd ..

Initial clone:
Attention: the bazaar checkout will download about 4 GB of data (git will later only use about 250 MB!!!). The clone will need quite some memory, about 2 GB of RAM should be available. Therefore I usually do it in two steps, so if something goes wrong in the clone, I don’t need to download everything again!

git clone "bzr::lp:openpetraorg"


bzr checkout lp:openpetraorg
git clone "bzr::openpetraorg" openpetra

Push to github:

cd openpetra
git remote add github
# or use if you want to use authentication with SSH key:
# git remote add github
git push github master

new changes from bzr to git:

cd ~/openpetraorg
bzr update
cd ~/openpetra
git pull origin
git push github master --tags
Tags: , , , ,
Posted in Software Development | Comments Closed