Disclaimer: This is a personal web page. Contents written here do not represent the position of my employer.

Tuesday, March 17, 2015


How do you upgrade your distro? A tale of two workarounds

Every classic Linuxer would know why it's very handy to dedicate a separate partition for the /home folder of your tree: you could in theory share it between multiple OSs that you installed in your box (which you choose to run when you start your computer).

Now, I'm guessing that many people reading and nodding to the above, will also know that sharing /home/ is one thing, sharing $HOME (/home/yourUserName) is a completely different beast.

For example: you have a stable distro installed in your box; you decide to install a new version of that distro along the old one, in the same box. You run the new distro with a new account tied to the old /home/yourUserName folder: KABOOM!!! Weird things start happening. Among these:

To workaround these problems, I have a strategy: I use a different /home/ sub-directory for each distro installed in my system. For example, for distro X version A.B I use /home/knocteXAB/, for distro Y version C.D I use /home/knocteYCD/. The advantage about this is that you can migrate your settings manually and at your own pace. But then, you may be asking, how to really take advantage of sharing the /home folder when using this technique?

Easy: I keep non-settings data (mainly the non-dotfiles) in a different /home/ folder with no associated account in any of the distros. For example: /home/knocte/ (no version suffix). Then, from each of the suffixed /home/ subfolders, I setup symlinks to this other folder, setting the appropriate permissions. For instance:

You may think that it's an interesting strategy and that I'm done with the blog post, however, when using this strategy you may start finding buggy applications that don't deal very well with symlinked paths. The one I found which annoyed the most was my favourite Gnome IDE, because it meant I couldn't develop software without problems. I mean, they were not just cosmetic problems, really:

So I had to use a workaround for my workaround: clone all my projects in $HOME instead of /home/knocte/Documents/Code/OpenSource/ (yah, I'm this organized ;) ).

I've been trying to fix these problems for a while, without much time on my hands.

But the last weeks a magical thing happened: I decided to finally sit down and try to fix the last two remaining, and my patches were all accepted and merged last week! (at least all the ones fixing symlink-related problems), woo!!!

So the lessons to learn here are:

Labels: , , , , ,

Tuesday, May 20, 2014


Banshee GSoC-2014 projects under Gnome umbrella

Here we are, at the beginning of a great summer!

This time, Google has given plenty of slots to the GNOME project, so we could accept many participants, including 3 brilliant students to work on the Banshee project. In case they haven't blogged about it, or didn't give much detail, I'll elaborate a bit about what they will be aiming to do these months:

  1. USB can work for the first sync, but whenever you update your library, I never remember to connect my phone again with my cable, or I'm too lazy to do it. Now imagine that whenever your phone is near your computer (and of course if you have Banshee running), they could negotiate together to update the sync without the need of moving a finger!
  2. Wifi could work also for the use case I just explained, but getting Wifi to work, compared to Bluetooth, would involve creating an app for the phone that could talk with Banshee. And we all know what are the problems associated with that: we would need to be cross-platform for at least the 3 main mobile platforms out there (well, iOS wouldn't even work neither with this nor with Bluetooth, because there are no public APIs to integrate with the music database of the OS, sigh iTunes...), and that means a lot of maintenance burden (even if we choose a same-language native platform like Xamarin), and a user experience that is not so seamless (as it would require the user to install an app first).
As you can see, most things are work under-the-hood this year, with little UI work. That's good for me because I'm no design expert. However, there is one area which we could do with some help: the new backgound tasks that will be implemented will need a way to notify the user (i.e. SongKick: when a new gig is discovered; AcoustID: when new/better metadata is found). In this respect, maybe Hylke Bons (our chief designer for the last Gnome .NET hackfest) and Garrett LeSage (assistance that Hylke proposed now to avoid getting himself swamped!) will be able to help! (BTW, if you're interested in participating in this year's Gnome .NET hackfest, message David Nielsen, which started to plan it recently.)

I'm very happy about starting the mentoring of these projects this year. And I'm specially jealous about my students... I became mentor of GSoC myself without being GSoC student first! (Maybe I should switch roles in the future?)

Wish them good luck! It was actually just yesterday when GSoC really started! (gotta love mondays)

UPDATE: Fixed embarrassing typo: I meant AcoustID, not OpenID!

Labels: , , , ,

Monday, May 05, 2014


GSoC 2013 with Gnome

So let this be a belated report about previous GSoC! sorry for the delay.

In summer 2013, Tomasz Maczynski worked on Banshee as a GSoC student, and he did great work! He developed a SongKick extension, and a FanArt.tv one. Both were worked on in the banshee-community-extensions repository. They work very well but there are a few downsides about this work, which we didn't have time to fix:

That is all folks! Stay tuned for the next blog post, which will explain the plan for GSoC 2014 (this year I get to mentor three students!).

Labels: , , , ,

Sunday, May 04, 2014


Belated Gnome .NET Hackfest post

OMG, I should feel embarrassed about posting such a belated blog post (yes, the hackfest was more than 6 months ago), but oh well, at least I can say I have enough excuses:
So this doesn't leave enough room for blogging, which is a necessary but a less appealing task. But I have to say it somewhere: the hackfest that David Nielsen organized was amazing, the best kind I have attended so far, as I came to meet for the first time some awesome hackers such as him, and:

(BTW I didn't include the awesome Bertrand Lorentz, fellow Banshee co-maintainer and GtkSharp gatekeeper, in the list, because I had already met him before, it wasn't my first time!).

And it was with the latter Stephan (not Stefan) the one I ended up spending more time with, because we decided to work on the new GStreamerSharp bindings since the 2nd day of the hackfest (the 1st day I mainly worked with Bertrand to release Banshee 2.9.0, our first Gtk3 compatible release, which he already blogged about).

So what was special about this work?
"Polish" sounds like easy work, but it wasn't. We fixed lots of crashes, and we contributed fixes to GObject-Introspection metadata upstream. And we proposed big patches for the gtk-sharp GAPI generator. And of course we updated our Banshee managed playback backend to the new GStreamerSharp API.

Main kudos should go to him though. I mainly added Banshee expertise, gtk-sharp contributing expertise, and lots of motivation (or at least I thought).

We had a big success: a Banshee playing audio with GStreamerSharp. Unfortunately video playback was freezing. But some months later after the hackfest we fixed it, and we released first GStreamerSharp 1.0 preview, which we called "0.99.0", and we released the first Banshee release that depends on this work: 2.9.1.

And it was my first time in Austria (and in Vienna). Overall a great experience, and I need to mention our awesome sponsors:

The GNOME Foundation, providers of the GNOME desktop

The University of Vienna and the Institute for Theoretical Chemistry, our venue sponsors

Collabora Ltd, Open Source Consulting

Norkart AS, Norway’s premier supplier of Geographic Information Systems and related consulting

Novacoast IT, Professional Services and Product Development

Hotel Schottenpoint, our hotel partner

Labels: , , , ,

Monday, October 28, 2013


Launchpad pull request

So you want to do a pull-request to a LaunchPad project?
Stop right there! The content of this blog post has been migrated to this question in stackoverflow. Move on, nothing to see here.

Labels: , , ,

Friday, June 14, 2013


Modernizing blam's autotools (or shaving the yak to move out from GoogleReader...)

Before focusing my spare time completely on the GSoC* (as I have mentoring responsibilities this year \o/ ), I wanted to solve a problem that cannot wait after July...

Yes, I've been victim of Google's cuts too... And I was wondering, where should I move? Feedly? ThingyBob? Well, I shouldn't make the same mistake twice, right?

Actually, some time ago I was using a desktop app to avoid relying on software that I cannot control (yes, vendor lock-in, the most important thing that open source tries to solve, right?): Thunderbird. But somehow the convenience of a web app (that I can access from any computer) and the hassle of using my mail client for RSS reading made me move to the web.

I should be able to find a replacement that no company or individual can "take down", and which feels less clunky than Thunderbird for reading RSS. So, enter blam (in the future I'll figure out how to sync its state between computers, maybe using SparkleShare?, to achieve that same convenience that a web-app provides), that Gnome app that has strangely managed to not catch my eye until now...

Well, maybe because if I install it from debian sid and I try to import my very first RSS feed from my GoogleReader list it doesn't work? Well, apparently it is a bug that is already fixed upstream, thanks to Carlos which has modernized the way that the program deals with XML and serialization.

Then I went ahead and tried to compile master myself... and guess what, the autogen.sh execution fails. Here the yak shaving begins, when I feel like this when trying to fix the autotools stuff:

Fortunately, after some tinkering (and some copy&paste from banshee's build scripts), I managed to fix the problem, and also modernized a bit some things (like using the brand new ".ac" extension instead of ".in" for the configure script, or using properly the AC_INIT and AM_AUTOMAKE_INIT macros,...).

Anyway, the real thing to highlight here is that while I was fixing this stuff and pushing to the repository...

... I saw some really good stuff committed by Carlos: using the new .NET 4.5 C# async patterns to get rid of those ugly callbacks! Kudos to him.

And if you're willing to help more with our autotools housekeeping, please do, I still feel this autogen.sh is way too long and needs some ironing.

* And if you're wondering what's up with GSoC (aka Google Summer of Code):

Labels: , , , ,

Tuesday, May 01, 2012


Apple and LastFM can still receive open source love

Here we are in an era in which ad-based services (like LastFM) and closed-products (like Apple ones) are on the rise.

But contradicting what you may think, open source is still friendly to them.

If you have an Apple device supported by libgpod* and you're an avid user of LastFM's scrobbling feature, you can today configure Banshee to send all the songs that were played on your device to your LastFM account the next time you connect your device while you have Banshee running.

Pretty handy, especially if you own a device that doesn't have internet connection these days (something definitely not on the rise). You should thank our new Banshee developer Phil Trimble for doing an awesome job on implementing this feature (and on resisting to not sending me to hell when I made the patch reviews...).

The next version of Banshee, in the 2.5.x series, should include this feature. Until then, hold on to your seats! (or compile it yourself from master ;) )

* Beware: not the last generation ones! you would have to donate to libgpod project if you want those recognised.

PS: If you're a developer and want to extend this feature to other kind of devices, you should just implement the interface IBatchScrobblerSource in the corresponding Source class of your device. If you want to make it scrobble to a different service than LastFM, just create a Banshee addin (simple sample here) that subscribes to the ServiceManager.SourceManager.SourceAdded event to then later subscribe to the IBatchScrobbleSource.ReadyToScrobble event from it, to later make the corresponding HttpWebRequests to the scrobbling service.

Labels: , , , , ,

This page is powered by Blogger. Isn't yours?


RSS of the category Gnome
RSS of the category Mono
RSS of the category C#
RSS of the category Programming
RSS of the category Mozilla
RSS of the category Web Development
RSS of the category Security
RSS of the category Open Source
RSS of the category Engineering
RSS of the category Misc
RSS of the category Politics

Contact with me:

My Photo
Location: London, United Kingdom
Follow me on Twitter