- Fix the name of the preinst script
- Make all scripts executable
- Make the common-functions POSIX-compliant
- Use the default shell instead of hard-coding bash

Make sure that when images are placed in views in 'listself' mode, they get put in filedownload blocks, which is more consistent for the upgrade. This makes the 'filelist' template migrate nicely.

There are now 3 binary packages being built:
- mahara: the bulk of Mahara, can be used with any web server
- mahara-apache: configures Mahara for Apache 1.x
- mahara-apache2: configures Mahara for Apache 2.x

Another big change was moving the Mahara code from /var/www/mahara into /usr/share/mahara.  This is to follow the Debian policy more closely and to mirror what the mediawiki does for example.

Other changes:
- Set myself as maintainer until the package has been accepted in Debian.
- Cleaned-up the package dependencies and build dependencies.
- Removed the database checks in preinst since they were postgres specific
- Removed files (like README, LICENSE) we shouldn't install
- Fix for rotations of empty log files
- Fix the path in the purge target of mahara-apache.postrm
- Renamed the XS-Vcs-* fields to Vcs-*
- Check to make sure that the cron job exists before running it

The template itself is reasonably simple, the problems lie around the translation of certain template blocks to blocktypes - but these problems affect all templates.

It gets converted to a five column view (regardless of how many columns are actually used). The images are shown without their titles. All in all, this one migrates quite nicely, with the exception of images that are tall - the grid like effect is somewhat lost.

Anyway, it now migrates reasonably well. The labels are only output if there's artefacts associated with them.

Move installing view column widths into its own function, so it can be called by the 0.8 - 0.9 migration.

handle_exception isn't really an API method for exception classes, so make it final in MaharaException.

The only other class using it was SQLException, this has been changed to rollback any existing transaction in the constructor.

This means that we can safely call db_begin() and db_commit() anywhere, and as long as the calls balance, the transaction will only be committed when the last one is committed.

If a rollback is asked for at any time, the entire transaction is rolled back.

Make sure that transactions use db_begin() and db_commit(), so that transaction level counting can apply.

This was a very annoying bug to find, it manifested itself as transactions that appeared to commit at some random point despite me not having asked for this. I'd blame DDL but it's not its fault that we made db_begin() and friends.

Also changed a couple of columns in view_artefact to be nullable while the migration is running. Tried this with XMLDB, it ate my face.

Penny started this work but I'm taking up the rest of it, so there's some changes to how certain things work that I made while trying to understand the way the migration works.

Also commented everything.

Next work - test the PPAE migration, then on to the other templates.

Check for identicality when setting values, that way '' and 0 are not treated the same and thus not changed properly.

Given that that transaction level counting is now implemented, there's no reason to do it ourselves when committing artefacts.

Make sure the attachment list table stays below any content in the blogpost, regardless of how that content is floated.

There are now three apache config files:
- /etc/mahara/apache.conf
- /etc/mahara/servername.conf
- /etc/mahara/serverredirects.conf

The last two are managed by debconf (overwritten at configure time) and are included in the first one.

/etc/mahara/apache.conf is marked as a config file and is meant to be edited by users.  It is symlinked into /etc/apache2/conf.d/mahara or /etc/apache/conf.d/mahara.

WR#1274

MySQL cannot handle unique indexes on fields that do not have a length. Even on those that do, the length is limited to 255 characters. Made sure there was a rule in the interface too.

Check for both the mysql and mysql5 db types when doing a mysql hack. Will be mysql5 only later, of course.

 * Make sure that the root user has their authinstance ID set correctly.
 * Make sure that the root user is forced to have ID 0

Also includes a sample French translation

A couple of checks to make sure that having blocktype code running when blocktypes aren't installed doesn't kill the admin section completely.

old fix fails for apostrophies