Tag Archives: gsoc

GSoC – Final report

GSoC 2013 is coming to an end, and in this posting I’d like to inform you about the new things that I added to Rainy since Midterm.

The second half of the GSoC was mainly about adding HTML5 interfaces. Although there are now two different interfaces – admin and user (note editing) client – they use the same technologies. After some evaluation, I setup both with AngularJS and Bootstrap. Bootstrap was especially helpful, since I am by no means a creative designer that could come up with a nice design, so using the (nowadays somewhat common) bootstrap default elements resulted in an acceptable overall look.

Single page applications – single executable

The interfaces are pure single-page applications (SPA) – that means they interact solely via JSON/REST with the backend, there is no server side HTML generation involved. So the major code parts of the interfaces are Javascript codes and HTML/Bootstrap skeletons. This has the advantage that they are just plain static files, which can be served by a tiny webserver – and directly via the HttpListener with a custom ServiceStack handler that is spawned by Rainy.

This is the part I like the most in this solution: All website files (.html, .js, .css etc.) are embedded as a resource into the Rainy.exe file and served by the builtin webserver. That means: No messy folders with assets, no setting up pathes in any configuration whatsoever. Deployment is still a single Rainy.exe file that only requires mono as a dependency.

Admin interface

The admin interface is the first thing that will pop open in your browser if you start Rainy on a system with a graphical environment (read: have a $DISPLAY variable set). It can be used to add, remove and edit users, as well as temporarily deactivate user accounts. The admin password is global, and needs to be specified in the settings.conf file prior to starting Rainy.




The note editing client was the more difficult part, especially the WYSIWYG editor. Tomboy uses a custom note XML format, and converting this to HTML and back without messing up the markup is not that easy. The bootstrap-wysihtml5 widget was of good help, but unfortunately has some bugs and the projects seems to be abandoned (wysihtml5, which is part of bootstrap-wysihtml5) on github. As a result, the WYSIWYG sometimes messes up the note formatting when saving, but I am confident that this can be sorted out in the future.

Nonetheless, viewing notes with custom markup works now pretty good. There is also a search field which responds as you type, so no server callbacks are involved. notes1

As soon as you change a note’s text, create or delete a note, the Sync button will become available and start a timer of 300 seconds. After 300 seconds or when you manually click the sync button the notes are synced with the upstream server version. You don’t have to sync after editing every note, changes are temporarily saved. So you can switch back and forth between the notes and make changes. Sync will only happen when the timer reaches zero or you manually press the sync button. For future versions I plan a complete offline mode that syncs the notes to local storage, but I will have to figure out what is the best way to do this.

Host it for your friends and family

For smaller groups up to 20 people, the SQLite backend will perform sufficiently well. But with the PostgreSQL support added before Midterm, Rainy is now ready to serve many more users at once. That is why I added the possibility to signup for an account. In the settings.conf, you can specifiy if signup is allowed (default: off) and whether or not users need to be manually activated by an admin after signup (default: on). This allows you to invite your friends, family members or co-workers to use your custom Rainy installation – hosted in a secure environment at home or at your data center of choice (remember that storage encryption was also added as part of the GSoC). You can even host it on a RaspberryPi running Debian! (sorry, no Raspbian yet due to missing ARMHF support in mono)



Give it a try – the public test server

The public test server that has been in place for months is updated to the latest release, and I try to keep it aligned with the latest git master. The HTML5 note interface is available for testing, too. Head over to the public test server page in the Rainy wiki or directly go to the login.

New RELEASE: v0.5.0

I’ve just uploaded a new release which contains all new features up to today. The v0.5.0 is the unstable branch that should evolve into a v0.6 stable release later after more testing. Get it from the Rainy download page and let me know of any bugs or issues that you have in the github issue tracker.


GSoC status report #2

It has been more than two weeks since the last (and somewhat late) status report, so here is the update about the new features I implemented the last two weeks.

OS X like “Go back to version” for Notes

Rainy now supports a TimeMachine like archiving of notes that are synced. Every note that is changed or deleted in the syncing process is saved with a revision number in a special archive table. Via the REST API the client can query the history for any given note, and possibly restore any previous versions (much like Dropbox file history). Since this a feature specific to Rainy and not part of the Tomboy REST API 1.0 specification, there is no support in any client whatsoever, yet. However, I plan to support it in the HTML5 web interface that I’ll be working on in the next weeks. During implementing, I hope to find any shortcomings in the API and fix them, so that at the end of the GSoC I can extend the API specification so that others can catch up on that. With the feature present in the Web interface, at least a user can view and restore older versions in the browser, in case he lost some important changes or wants to recover an already deleted note.

The note archive also supports the recently introduced note encryption, so make sure you don’t forget your password AND lose all your authenticated device keys (=OAuth tokens), else the whole archive will be unusable!

Approaching Midterm

My GSoC  is split up into pretty much two parts: In the first half (until mid-term), do all important server-side stuff like the new database support, note encryption and go-back-to-any archiving. The second half is more client-centric, as it covers a creation of an HTML5 backend (=client) to access the notes.

Since I managed to finish the server-side stuff a little early, I am right now polishing the code a bit and add more unit tests, to make sure new features are working as intended, stabilize the code, and to actually have something to show at the mid-term evaluation to my mentor. There is nothing more satisfying to a developer, than a list of (mostly) green lights after pressing the “Run tests” button 🙂 So far Rainy has around 120 unit tests (although some are modified derivations of tomboy-library), but most tests actually test against the real REST API with HTTP requests to a local server,  not against any mockups or mocked servers with predefined responses).

GSoC 2013 – First progress report

As you might know, I was accepted to work on Rainy during Google Summer of Code 2013. It is a great opportunity to turn Rainy into something great, and I am happy to give my first status update about what I’ve been doing the last three weeks and what I am up to in the next time.

Rainy has grown to an extend where I thought it might be a good idea to have public website (not only a blog about it) online, and for some month the home of Rainy has been and still is located at http://dynalon.github.io/Rainy. Check for releases, news, infos and updates that are Rainy specific.

Week 1: PostgreSQL Support & Cleanup

In the first week, I planned to add PostgreSQL support. Since I plan to add more database backends in the future (MySQL, MSSQL) I first had to refactor some classes and interfaces that allow to plug in other backends at a later point. This was the first time I got in contact with the Inversion of Control pattern, as I ended up refactoring most of Rainy’s classes to use constructor-injection and auto wiring using ServiceStack’s Funq IoC container implementation. This was very fun to learn, and I like the concept, especially since ServiceStack uses the IoC  constructor injection pattern everywhere and you can easily hook into it.

After the refactoring, I added the PostgreSQL backend, which was very easy since I already used ServiceStack.OrmLite as an O/R mapper which brings the necessary abstractions.

So, Rainy can now be used using either the SQLite or PostgreSQL backend, allowing to scale for a much larger number of users. My first benchmarks show that SQLite is actually faster than Postgre, but I measured only using a small number of notes and users. For larger databases I think PostgreSQL will outperform SQLite.

Week 2 & 3: Server side encryption

This is one of my favorite tasks that I added to the GSoC proposal, and I think will be the most valueable one. Especially since recent events in the media should have raised awareness of data privacy in the cloud to a broader audience 🙂

Unfortunately, Tomboy and Tomdroid do not yet support full client side encryption of notes, that would enable us to store them safely in the cloud. To overcome this, we can at least implement server-side encryption in Rainy. Notes are encrypted on the fly using AES256 before they are stored in the database, and decrypted transparently upon requesting the notes. The required keys should of course not be stored in plaintext in Rainy’s database, so that it is non-fatal if someday a Rainy server-instance gets hacked and the database is made public.

The crypto implementation was one of the harder pieces in my proposal, and I am happy to tell that it is done and has landed in the git master. For anybody interested in the details how the crypto and the key management works, I wrote developer docs that can be viewed here. Since a basic understanding of encryption is required, I will discus only a easy-to-understand approach here, for details see the developer docs.

What the encryption does

  • works completely in the background and on the fly, no setup on the clients is necessary
  • encrypts every note with a per-note key, which is itself encrypted with the users master key
  • the master key is not stored in the database, but part of the users oauth credentials. That way, if the database gets public the notes can’t be decrypted without the users master key
  • if you lose a device (say your cell phone with Tomdroid) and you immediatley revoke the access token for the device before an attacker finds it, the attacker cannot sync again (but might access the notes that are stored on your phone). No need for changing the password or revoke all tokens
  • Change your password at any time, without re-authenticating any device or client

What the encryption does not

  • replace client-side encryption (which is sadly not available yet)
  • protect your from malicous server administrators – they can still modify Rainy’s code and hijack your keys which should only reside in the RAM

What’s next

For the next weeks I’ve planned to add a Time-Machine like “Go back to version” function into Rainy, that will save all note versions into the database and allows to access any older revision. Very much like the TimeMachine mode os OS X or Dropbox allows to go back to any previous version of a file.

This requires the Tomboy REST API to be extended and might not land into the client software too soon. But it  will  be in the  HTML5 Webinterface client that I will also be doing as part of the 2nd half of the GSoC. More about that in a future blog post 😉

GSoC Progress Report #4 – MidTerm passed

This is the 4th post in the series of my biweekly gsoc status reports. Last week was MidTerm deadline, and I am happy to say that I passed my MidTerm evaluation. I am a little ahead of time, actually. I proposed to have a Banshee.app ready with no working Mass Storage yet, but preview USB plug-in detection. The last alpha3 build already had full usb mass storage support working. So I had the time in the last two weeks to polish the hardware support a little.

Sync your music to network shares with Banshee

I’ve modified the OS X specifc hardware detection code a little, so that not only USB devices get recognized, but all kind of mountable volumes that have an .is_audio_player file on them. This allows one to create a fake mass storage device to sync your media to, but it’s actually just a folder on a network share. This can be any kind of network share, like smb or afp mounts, or as I am going to show step-by-step, a remote SSH location mounted by sshfs/MacFusion.

Howto: Syncing to a remote machine over SSH

I want to be able to sync my media collection and selected playlists from Banshee to my linux powered File-/DLNA-/ Server where I store all my music. I’ll only want to carry a subset of tracks on my Macbook, which has only limited disk space. This is how we can enable syncing via SSH (provided you use at least alpha4 build):

  1. Login via ssh to the machine to want to sync to, and create a folder for your Music and put an .is_audio_player into it:
    mkdir ~/SharedMedia/
    mkdir ~/SharedMedia/Music
    mkdir ~/SharedMedia/Playlists
    touch ~/SharedMedia/.is_audio_player
  2. Edit the .is_audio_player file with your favorite editor and have it look like this:
  3. On your OS X system, install MacFusion (successor of MacFuse)
  4. From the MacFusion tray icon, select “Connect to Server” and enter the ssh:// address of your remote machine. In my case, this is “ssh://timo@orion/home/timo/SharedMedia/”. Replace “timo” with your username and “orion” with your  hostname of your machine. You will need to have setup ssh public key authentication for the connection to succeed!
  5. Banshee will detect the network share as a generic mass storage device. You can now sync your whole media collection or single playlists between the network share and your banshee media database! 🙂

Other improvements in the hardware backend include stability fixes as well as making the “Eject” button working for the external devices.

Native file dialogs

Also new in alpha4 is the support for native file dialogs. Right now, the Gtk file open dialog is just broken on OS X. If you own a system with more than one harddrive (no matter if internal or external through usb/firewire/thunderbolt) the Gtk Filechooser will not display it. Same holds true for any network shares. Only way to access external storage is, if you know that OS X mounts those volumes in your /Volumes path – a fact that is not known to lots of OS X users (and there is no need to, as you got your external Volumes always in your sidebar). Currently only the Import Media->From File/Folder uses the OS X native file open dialog. At other points, its more complicated due to Gtk Widgets being embedded in the chooser. But those dialogs are usually less often used (export playlist dialog, choose cover art dialog).

As usual, with this bi-weekly report I’ve rolled a new alpha bundle which included my latest development progress and all features talked about in this post, as well as all previous posts. Get it here or follow this direct download link to test it yourself!

Source Code

Since the source for the hardware support and the native file choosers will likely change within the GSoC period, I’ve not submitted patches to upstream, yet. However, I’ve setup a mirror on GitHub including latest banshee master branch from gnome, and a branch with my changes (nicely formatted and rebased). A pull request against myself can be used to retrieve a single patch including all my changes for this GSoC assignment. I’ve also updated the banshee-git package in bockbuild to auto-retrieve this patch and build when doing a release build.

GSoc progress report #3

This is my 3rd post in the series of my bi-weekly status reports for my GSoC banshee OS X assignment. This two weeks period was actually quite more fun than the weeks before, as I shifted from doing packaging and bugfixing work (which is sometimes very time consuming and frustrating when dealing autotools and  recompiling packages over and over again to check for regressions) to actual coding work.

Hardware support

Part of my self-set midterm goal is bringing basic support for hardware devices in OSX banshee, in particular to USB mass storage devices. Mass storage devices are very common: From the first generation of mp3 players, the mass storage usb  driver was used to put mp3 files into the players flash memory and it is still widely used today: All recent Android phones support it, as well as low-cost consumer mp3 player sticks and more sophisticated “feature phones” are also often loadable via usb mass storage. That makes having mass storage support in OS X banshee very important.

OS X disk arbitration library

After little research, I found there are several methods to access usb devices on OS X. There is the IOKit framework, that can be used to handle everything usb related, as far as low level device driver programming. Luckily, there is another Framework that is a little higher on the device layer while not being bound too strictly to USB and fits perfectly for our purposes: the DiskArbitration framework. You can use it to hook callbacks whenever a disk device (being a USB/Firewire mountable volume like a usb stick or harddrive, network shares or .dmg images) appears or disappears to the system. So I chose to go for it and started research.

Unfortunately, neither the IOKit nor the DiskArbitration framework are yet bound in MonoMac. That meant I had a number of choices:

  • writing myself a C based glue layer to interface with the frameworks
  • bind the needed function calls myself with DllImport P/Invokes and wrap the datatypes

The first way is usually an easier one from a programmers perspective, as I could do everything in C and just write a very basic public interface that is marshaled by the mono runtime. Future changes in the framework’s public ABI can be spotted very easily, as the C compiler will complain about missing functions or changes datatypes.

However, I chose the second way as usually prefer keeping one language in a project. Banshee uses quite some C gluelayers at the moment, bug there are efforts to remove them and someday have a completely C# based codebase.

Although MonoMac did not bind the IOKit/DiskArbitration framework, there is limited support for the CoreFoundation framework which helped doing a managed-only solution. I did never work on low-level OS X APIs before, neither did I work with MonoMac, so I spent nearly a full-time week digging into the Header files (which turned out to be the best documentation for the API) and finding out about MonoMac, and how I could handle the native CFObject types and marhsal them into C#.

If I had more knowledge about MonoMac and OS X internals, I’d have tried to contribute them to MonoMac by binding the missing frameworks. I am however glad I didn’t chose that in the first place, as it turned out I only needed a handful of funtions wrapped, and especially IOKit is a huge beast with far more complexity needed for my purposes. So right now, there are two small static IOKit and DiskArbitation classes that expose the needed library calls via the public static extern DllImport mechanism.

Hooking into disk arbitration wasn’t the difficult part. Turned out, for device recognition I needed the usb vendorId/productId pairs, and those were not provided by disk arbtitration (as its not bound to the USB bus). It took me days to figure out how to do that, and I had a chance to catch up with my rusty C abilities, as I did the prototype completely in C, and then rebuild it in C#.


I managed to get USB device recognition working quite well (as far as I could test). In the latest alpha build (see below), you can plugin usb mass storage devices at will, before or during banshee runs, and we hook into all necessary events (device unmounting, hard usb removal because life is to short to remove usb safely) and banshee will refresh the devices list.

The usb vendor/product ID pairs are exposed, so lots of device abilities are detected automatically. My Samsung Galaxy S (with CM9) is correctly detected as an android device, and I tested a simple USB stick with an .is_audio_player file to pretend it being a MP3 player. There might be glitches with devices having more than one partition on them, I have yet to test that.

Syncing works (again as far as I could test) although I had to apply two non-hardware backend related patches (1,2) to make the process work seamlessly.

As I only have a limited number of devices, I invite everyone to test with your devices, and give me feedback so I can further improve the mass storage support.

Minor improvements

The alpha3 build I put together includes, besides the very large hardware-support patch (that is not yet in upstream as it will likely change in the next weeks), enabled  UPnP/DLNA client support . There was not much to do, just create a bockbuild package dependency and it worked out of the box, same way as it does on Linux.

As the folks from xamarin pointed out to me in IRC, there are known problems with Glib 2.32 on OS X which severely impact performance. The (quite old) gcc Apple ships seems to have problem with gcc interlocked/atomic intrinsic (compare-and-swap and alike). I downgraded to Glib 2.30 by reusing the xamarin package and to my great surprise I could actually feel it. The UI is a little more responsive, but the great change is the playback: While I often had sound stuttering when the system was under load, that is completely gone now. That change is also included in the latest alpha build.

New alpha build release

As I had done with the two progress reports before, I’ve bundled a new Banshee.app (this time alpha3) ready for everyone to download and test. Get it from here and do not forget to read the instructions provided. Feedback is greatly welcome, you could use the banshee mailing list for that.

GSoC progress report #1

GSoC coding phase has run for nearly two weeks now and I have quite some things to report on what I was working on during that time.

BCE build system

One core goal of my GSoC assignment is to enable the BCE build system to work an mac. This was actually very easy task to do, as I could just recycle the bootstrap-bundle and profile-configure scripts from banshee, with just some minor modifications. So for now, a ./bootstrap-bundle will prepare the build environment (mainly scan through your setup and set all necessary environment variables, like LD_LIBRARY_PATH and so on), and “./profile-configure darwin” will run the configure script with the suggested enable/disable flags.

BCE compatibility check

After the basic  build system setup was done, I was curious on what modules would compile out of the box – I thought about my previously contributed FolderSync which does not rely on any unmanaged code – and just tried to enable more and more extensions by adding an according “–enable-<extensionname>” to the profile-configure file. For a handful of extensions this worked seamlessly – but for some others I had to learn there were dependencies that had to be build first and thus I created package files suitable for bockbuild.

A very nasty bug in the gnome-doc-utils m4 macros wasted nearly a day of my time – which was mostly due that I am not that familiar with the whole autotools stack. I finally managed to fix it by replacing the m4 macros with the ones shipped with banshee.

OpenVP investigation

The OpenVP extension gave me a very hard time. OpenvP  creates stylish visualisation in banshee on linux, and it’ll be great to have it on OS X. After nearly 2 days of research, I came to the conclusion that its not easily portable, and here is why: The OpenVP extension relies on the nowadays abandoned/unmaintained  Tao.OpenGL stack. I then found that OpenTK offers a compatibility layer to that, so I created a bockbuild package and added OpenTK as a dependency. This allowed to build the OpenVP .dll and enable them in banshee. However, I quickly found that trying to start it would result in EntryPointNotFound exception: The GLWidget that is used by OpenVP tries to call native gdk_x11_drawable_get_xid() which is unavailable – as we use the gtk-quartz backend, not the x11 one. There is no similar function in the gtk-quartz backend, so I was screwed. After a while I found an alternate GLWidget implementation, which is also based on OpenTK and does not reference native code, but leaves that to the OpenTK backend. I could get everything to compile after some fixes and even be able to run, but upon activation banshee crashed completely from within OpenTK. After searching the OpenTK source, I found that the drawable context is setup using System.Windows.Forms constructs – and that didn’t work out on  OS X using gtk-quartz. So after 2 days I decided that OpenVP will not easily be portable, unless there is a more reliable GtkGLWidget that works with quartz. Bummer.

Webkit-based extensions

There are a bunch of extension that require Banshee.WebBrowser which is currently not available on the OS X plattform. I dug into what would be necessary to get Banshee.WebBrowser enabled, which would be very nice because that would allow Amazon’s WebStore to work. Banshee uses at the moment a glue library (libossifer) to embed WebKit within Gtk#. That native glue code links against WebKit directly. I had some failed attemps to get the WebKit source from svn/git (its just huge!),  and the tarball failed to build. I’ll have to investigate this further, especially since there is a GtkWebKit project which could replace libossifer and a banshee branch with some code to replace libossifer with webkit#. I will definitely get my hands on the WebKit-part in the next weeks, but found it too time consuming for the first weeks as I wanted to show some early results 🙂

BCE extensions running right now

After some dependency research, package creation & compilation, I have finally now running and working the following extensions:

  • FolderSync
  • AlarmClock
  • AlbumArtWriter
  • DuplicateSongDetector
  • RadioStationFetcher
  • LiveRadio
  • LastFMFingerprint (required native fftw and libsamplerate packages)
  • StreamRecorder (requires fixed dllmap .config, lame package plus some Makefile fixes)

Discarded extensions

Some extensions just don’t make sense on the OS X plattform, as they interface with software that is usually not present there:

  • Zeitgeist-data-provider
  • Awn integration
  • Telepathy integration
  • Appindicator

I’ve disabled these extension in the profile-configure file so they don’t get build when on OS X.

 The remaining extensions

As with the remaining extension, I do not know yet whether I should port them or there are some problems. I.e., I could get the RandomByLastFM plugin to compile but it throws some exception while running. As mentioned before, all Banshee.WebBrowser dependentand extensions require further investigation. With the clutterflow extension I am not yet sure whether its possible to integrate cutter into gtk-quartz.

Bockbuild changes

Besides some new packages added that were needed by the BCE, I’ve bumped some packages to newer versions, and merged David’s and Xamarin’s branch into my local branch at github. I try to stay aligned with the xamarin branch of bockbuild as close as possible, because most of the gtk-quartz/mono fixes they integrate directly apply to banshee.  However, due to a bug in pango’s CoreText implementation, we are still stuck on an older pango version.

I also rearranged some of the bockbuild util* stuff and added a python script that  allows to write the necessary environment variables directly into a MonoDevelop .csproj file in XML format using the “–csproj-instert=<filename.csproj>” parameter. Check the build howto for more information.

Banshee changes

I’ve also prepared a patch to banshee which switches to the new gtk_mac_* API and drops the old ige_mac_* API . Before I sent this patch upstream, I’ll check whether its possible to completely switch to the new GtkOSXIntegration API, which would use Cocoa instead of Carbon. The patch is included in my bockbuild repo and automatically applied when building.

Build instructions

I’ve created an extensive HOWTO on how to build current banshee 2.4 with the currently running extensions from BCE on the OS X plattform. So if you want to build banshee from source, or get your hands on the code, now is a good time for it 🙂

Unfortunately, there are still some glitches when creating an .app Bundle, so I can’t offer an early alpha .app right now – but stay tuned!

GSoC preparations – part 1

The official GSoC coding phase hast not started yet (will start on May 21th) but of course, I already did some research and preparations (as is also suggested by Google) in order to be ready when it does. In this post, I put together some thoughts and findings that occured to me while prep’ing. This is part 1, there will be a part 2 soon ^^

Enter bockbuild

First step when working on a project is setup a build environment. I did this already before my actual GSoC application, so I can get a better understanding  and estimate the effort necessary to integrate the BCE into banshee’s current build system. When building software that originates on Linux for Mac, you inherently face the problem that there is no package repository tool available as you would expect from a linux system (apt, zypper, etc.). You can’t just do a “zypper si –build-deps-only” to install the required dependencies  as I would do on my openSUSE box. And if you go for fetching and compiling every little dependency yourself, you will soon realize that it comes to more than 60 different software packages (for banshee), each in their own tarball, git repo or whatever, and each possibly dependent on another package(s). Eventually, you will be lost in compilation.

This is where bockbuild comes into play. Created by Aaron Bockover, bockbuild takes care of fetching and compiling the sources from scratch in the correct order and installs them all together into a single $prefix. This includes building build tools (like autotools and cmake), gtk and its dependencies (cairo, freetype, glib etc.), gstreamer, a full mono environment and finally the bunch of banshee dependencies and most of the C# wrappers to the aforementioned libraries.

On my development machine (a 2008 Macbook white with a Core2Duo and SSD) the whole process of fetching and building the environment takes about 2,5 hrs. Because one would not rebuild the entire world after each tiny package upgrade  (bumping a tarball to a newer version or moving to a newer git commit), one can simply recompile the modified packages. This is where it gets messy. While the recompilation of a single package may succeed on the pre-setup world, a completely new build of the world from scratch could fail. This is one of the reasons I spent almost two days before my application for GSoC to patch bockbuild for my system to successfully compile the world – just in order so I could compile a recent banshee version on my machine. The whole process is very painful and I wouldn’t recommend it to anybody – maybe a reason why to this date there are not that much banshee developers based on OS X. I decided to change that, or at least lower the bar for other developers to get their hands on banshee on the Mac.

Better testing of bockbuild

As the build results of bockbuild when building the world are dependent on dozens of factors, I needed a clean-room environment where I can test the builds and later on the .app bundle. Now that I am sponsored by Google and knowing that I  will (hopefully) soon receive my initial funding, I did not hesitate to spend some of Google’s money to back my development process: I acquired a copy of Parallels 7 (which comes as a full-version educational edition for 39,99 €) which allows me to run virtualized versions of Lion and – with a little hackery  – my old Snow Leopard DVD non-server version.

I am really no big fan of Parallels, they don’t seem to treat their customers well (pop-up ads for their own products as well as crapware bundles like Kaspersky subscriptions etc), but I’ll maybe blog on that later. For now,  Parallels 7 will give me a playground to accomplish my next goal:

Stable bockbuild releases

In order to allow other developers (and users!) to compile banshee from source and roll their own AppBundle, I’ll try to maintain two branches in my GitHub repo:

  • -stable branch, which is tested to build completely from scratch on different OS X installations with different settings. It is alligned with the banshee releases – for now I created a banshee-2.4-stable branch which could be used to build banshee 2.4 and roll your own AppBundles
  • a –testing The master branch which someday will eventually turn into banshee-2.6-stable branch. Patches against this branch might cause the build world to fail, as it is not tested everytime a change is made. Use at your own risk!

Now the branches are setup, but documentation on building the world and banshee on OS X are a little outdated – I will give more detailed instructions in a future blogpost, where I will also tell more about how to easily setup MonoDevelop to compile and run banshee for your development purposes.