Migrating from Trac to Redmine

In the past few days, I needed to migrate from a 6 years old server with CentOS 5 (it’s end of life is this month) to a shiny new one with Ubuntu 16.04. One of the services that was running in the old server was Trac 0.11 and I had several issues to move it to version 1.2. I like Trac and I’ve used it without any issues until now. After a while I decided to try Redmine 3.3.2, but I was not sure about the migration process.

After installing a large amount of requirements (a lot of Ruby packages), I followed this migration procedure that seemed straight-forward and should work with Trac 0.11, but it failed almost immediately for a very simple issue: The timestamps in all the database tables in Trac were in microseconds, whilst the script was expecting them in seconds.

I wrote this simple Perl script that changes the timestamps in all the Trac database tables:

Assuming that you have installed all the requirements (including the Perl ones with CPAN) and that the SQLite3 Trac database is called trac.db, execute the above script followed by the Redmine migration script:

The Ruby (rake) script asks for your Trac settings:

and outputs all the items that were migrated without any errors.

I checked immediately in Redmine if everything was migrated correctly and I noticed a couple of issues:

  • The attachments in the wiki and tickets are not migrated
  • The wiki links are corrupted. The whole wiki was migrated (all the pages and their content is correct), but the links got corrupted.

The attachments were not a big issue since I had a few of them.
The wiki links was a bit annoying, I went to the Index by title, check the new name and edit the pages that link the correspondent page. My wiki is large, but it’s not heavily linked, so it didn’t take too much time to fix it.

Now that I’ve been using Redmine for a week I feel quite comfortable with it and I think that its integration with Git is better than Trac’s.

Cross-building LibGTop

LibGTop is a library used to get system specific data such as CPU, memory usage and info about running processes.
Since it’s part of the GNOME desktop environment, it’s used by some system monitor applets, but it’s main interface is completely independent, so it can be used as a standalone library even for embedded system that already use GLib.

Normally, you should debug your system before deployment and be sure that there are no processes with memory leaks or that are consuming more CPU than they should, but sometimes there could be strange conditions in a process that at certain point start to eat too much CPU or just Valgrind doesn’t support your processor.

In these cases, the system needs to be closely monitored and a library like LibGTop with an API that you can easily use could be quite handy.

I normally use Buildroot, but it doesn’t include LibGTop, it seems that Yocto doesn’t have a recipe neither. I’ll try to explain briefly how to cross-build it for an ARM processor that I’m using with the Linaro hard-float toolchain.

Download:
libgtop-2.34.1.tar.xz

First, let’s export common environment variables that make our life easier:

Configure remove unneeded things for an embedded system:

Edit lib/Makefile and set the following variables:

Compile and install:

You can have a look at the GLibTop API here.
That’s it.

Skipping incompatible /lib/libc.so.6 when searching for /lib/libc.so.6

When cross-building a program (but this could also happen when building natively), it’s normal that we don’t have the environment variables and building flags set with the right paths that indicate where the toolchain and the sysroot are.

The wrong paths can lead to many types of building errors at different stages. This one happened to me recently:

This linking error says that it is skipping an incompatible library that is searching in my host’s filesystem even though I explicitly indicated in the Makefile the paths to use in the environment variable LDFLAGS with the -L:

The $SYSROOT environment variable was set correctly

To indicate the linker to use the right path you have to add the -Xlinker -rpath-link=/your/sysroot/path directives.

For adding the /lib and /usr/lib path that are in my sysroot, the previous setting of LDFLAGS becomes:

Now the linker does not complain anymore.