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

I am providing now a server for development of OpenPetra, with X2Go desktop remoting.
See more details at

To save costs, I am running the server on a jiffybox, which costs less when you freeze it.

So I am providing a php script that allows starting the machine, and to refresh it. After the last start or refresh, the machine will be stopped and frozen.

Now it would be good to remind the users once in an hour to do visit the refresh link.
I am using zenity to display the message.
This script will get all users logged in over X2Go, and display the message on their desktops:

message="Server will shutdown soon, please refresh if you still need it by visiting"
wall $message
for display in `ps xaf | grep x2goagent | grep -v grep | awk '{ print ( $(NF) ) }'`
  user=`ps xaf | grep x2goagent | grep -v grep | grep "$display$" | awk ' { print ( $(NF-5) ) }' | awk ' { print ( $3 ) }' FS='/'`
  echo "$user $display"
  su - $user -c "zenity --info --display=$display --text='$message'&"

(for better layout, see

The crontab looks like this, to run it every hour:
0 */1 * * * /root/

The php script looks like this:

The script is installed on a separate machine, that is always running.
The users can call jiffybox.php/?operation=refresh to start or refresh the machine.
The cronjob for stopping the machine looks like this:
*/15 * * * * cd ~/subs/jb; php jiffybox.php

Tags: , ,
Posted in Software Development | Comments Closed

Use Case OpenPetra for TeenStreet 2011   September 29th, 2011


For TeenStreet 2011 in Germany, we have extended and used OpenPetra.
TeenStreet ( is an International Christian Teenager Event that happens all over the world.
Teenagers, group leaders (aka coaches) and service crew from about 18 European countries, and even further abroad, register for the TeenStreet conference in Germany. The registration is processed through the home office of each country. The home office is responsible for payment and accepting or denying registrations.
The organising office does all the logistics for the conference, eg. printing the badges.
The software ran fine on a Debian Linux on a virtual server. We have had about 3600 applications altogether.



The functionality can be separated into the part that was seen by the participants, and the part that was used by the registration offices and the organising office.


  • There is a base yaml file with general data, eg. photo upload
  • A javascript file contains all the texts, and should be translated by the home office.
  • There are several roles, eg. Teenagers, Coaches, Service people. The questions and fields to fill in are different for each role.
  • The home office can request customizations for the yaml file, which is derived from the base yaml file.
  • An Email is sent to the home office and the applicant, when the registration is submitted. A PDF file is generated and provided as a download and as an attachment to that email.
    • the email and the pdf are based on HTML templates. The PDF can also embed other PDF files, which is helpful for more detailed questionnaires for the adults.
  • The applicant has to print the PDF, sign the paper, teenagers have to let the parents sign as well.
    • If payment is done by direct debit, there is an additional signature for that on the paper as well.
    • the paper is sent as a normal letter to the home office


  • The home office receives the letter, searches for the applicant, and reviews the application. If the applicant is accepted, the state of the application is changed from “On Hold” to “Accepted”. The acceptance date is recorded.
  • If an applicant is cancelled and the application status is set to cancelled, the cancellation date will be recorded.
  • Early applicants will receive a free T-Shirt. There is a special report that tells how many T-Shirts and sizes need to be ordered.
  • Badges can be printed for all applicants, with different layout, defined in HTML, for each role. Photos for the applicants and bar codes can be printed.
    • Lost Badges can be reprinted on demand.
  • Export all data of participants to an Excel file to process the data further.
  • Print reports for medical needs, vegetarians for the kitchen.
  • Print a report to know how many people are on site on each day.
  • Print a report for the children and families on the site, for their special programme.
  • Print reports for the home offices. They tick off who has actually arrived.
  • Print reports for the service crew, or other teams, to know who is supposed to be on their team.
  • Rebukes: allow the “Boundaries Team” to make notes for applicants who violate the rules on site, and print reports for the coaches or home office representatives
  • Medical team: the medical people can see the relevant information and emergency contact information of the participants, and store information about diagnosis and therapy.
  • Import applications from Petra 2.x for offices that did not take part in the online registration.
  • Late and manual registrations have also been processed through the backend.
  • Export applicants into the local Petra 2.x for the home offices.
  • Export gift batches for Petra 2.x to easily process the application and registration fee. This has only been used by the German office this year.
  • Print reports for the organising finance office, to charge the home offices for the participants that come from their country. Consider siblings, and early/late/accepted cancellations. Order participants by role.
  • User management is currently not done in the web interface, but through the OpenPetra fat client. Everything else runs in a web interface.
  • User rights can be limited for the home office representatives to the applicants for their country. The medical team and the boundaries team and the finance office get special permissions.

possible improvements

  • For next year, the applicants should be able to retrieve and update the information they have entered last year
  • Allow applicants to login later again, and register for workshops and seminars
  • Provide a list of all people that are currently on site. Need to record the actual arrival date.
  • Group assignments for the fellowship groups need to be semi automated.
  • The administration of users should be available in the web interface as well.
  • When creating the gift batch file, also create a DTAUS file at the same time.
  • head set distribution for the translation, scan the badges, home offices can get a report to see who has used a headset. check which headsets were not returned after the session.
  • upgrade and ext.js to the latest version, so that IE 9 can be fully supported
Posted in Software Development | Comments Closed