- This is the weblog of Iago Toral -
I will be talking about MAFW, the Media Application Framework for Maemo, at the Desktop Summit in Gran Canaria. That will be a nice place to introduce MAFW to the desktop community as well as an opportunity to showcase it to those interested.
The talk is scheduled on Wednesday 8th July, for details on MAFW and the contents of the talk you can take a look here.
Today we have added our test GUI to the garage repository (component mafw-test-gui). This is by no means a product quality application, but it is a good sandbox for testing MAFW while we work on it. Maemo developers interested in writing multimedia applications based on MAFW can use this application as a reference. If you just want to give MAFW a try, this application is a good place to start as well.
If you missed the previous posts, you can find MAFW’s repository here.
Enjoy!
UPDATE: Zeeshan just remembered me that I forgot to mention that this UI is based on gupnp-av-cp code 
Quim has just announced that MAFW (Multimedia Application Framework) has moved to an open development model. This means that from now on we will work directly in garage and anyone interested can browse the source code and provide feedback (and even better, patches!). I’ve been looking forward to this moment for quite some time, so I am really excited that this has finally happened. Thanks to Nokia and Quim for making this possible!
If you are planning to write or port Maemo multimedia applications for Fremantle, I suggest that you to give MAFW a try and share your experience with us, we really need your input. In that case you probably want to start by reading the documentation here.
BTW, I intend to use my blog to keep the Maemo community updated on MAFW news, so stay tuned…
I thought it was time I had a category for Maemo related posts only, so here it is. I expect to post some interesting news and info in the days to come, so stay tuned if you are interested!
Thanks to Frederic Peters, who’s kindly worked on providing a new design that’s more integrated with the Gnome Website look and feel, and Alejando Piñeiro, who’s been working on actually making it work with our Builbot installation.
You can check it out here. Hope you like it!
As some of you may already know we have been postponing for some time the addition of new slaves to build.gnome.org. The reason for this was that in order to allow other slaves to connect to our master we had to open a large range of ports in the firewall, fact that worried some people maintaining the server. So, I and my mate API invested some time (more than we would have liked to) trying to find a solution based on a single public port. Unfortunately, our lack of experience with the Twisted framework was a constant pain and made it a bit difficult to move forward. In the end, we managed to implement a solution which worked fine… for a while, until the TWisted beast bit us hard, yet again, with a random, low-level, indecipherable error…
So, at that moment we had to choose: either we continue working on that, maybe delaying work on the build brigade for some more weeks or months, or we find a temporary workaround to keep things moving forward. Of course, we chose to keep things moving forward ;), so we moved the master back to Igalia with the help of Olav Vitters and enabled two slaves: the one we had in the old build.gnome.org and a new one running at Igalia. You can see the results in the gnome-buildbot web page. Of course, this means that now we can finally accept new slaves, so let us know at the build-brigade mailing list or IRC channel if you want to do so! We will be glad to guide and help you in the process.
Meanwhile, we will still try to find a solution to the ports issue, but now with a new approach, thanks to John Carr for working on this matter!
PD: Sorry to those who had offered slaves but have had to wait so long for us to get this done.
I’ve checking out the gnome mobile moduleset created by Ross Burton some days ago. My idea is to setup a gnome-mobile-buildbot that provides continuous integration of gnome-mobile software stack in several architectures.
First attempt (Debian, i686) quite successful:
The Gnome Buildbot has been showing many modules failing on update stage for some time. This had to do with some changes in Jhbuild to support Mercurial repositories (back in May) and, specially, the inclusion of mercurial repositories in the modulesets.
The reason for this to fail in the Gnome Buildbot was that we were not using an up-to-date Jhbuild version and a simple update would not do the trick here because we were using a slightly patched Jhbuild version. You might wonder why we did not push our patches into jhbuild in the first place, but the truth is that we did it since the very beginning, however, there was still one of them pending to be applied because it needed some tweaks prior to go upstream and these fixes were postponed for too long… (my fault).
When the modulesets were updated to actually include mercurial repositories, our jhbuild version raised the problem because it did not know anything about this repository type. Nothing better than actually see a problem to start working on solving it, suddenly fixing that pending patch became my most important ToDo item :), after some days of work and the valuable help of Frederic Peters, we managed to get a functional, corrected and up-to-date patch against Jhbuild trunk, so finally the Gnome Buildbot is working using a non-patched version of Jhbuild.
For the future, now that we run a non patched version of Jhbuild, and taking into account that jhbuild is a key component of the Gnome Buildbot, we should consider a regular update mechanism that keeps our build environment up-to-date.
BTW, thanks to Frederic for helping us with this! (and also with the other patches we merged in Jhbuild), you have definitely made our life much easier :).
For those of you interested in the slides of my talk about the Gnome Build Brigade at Guadec
Answering to Olav post about my plans for the gnome buildbot: the more slaves, the better :). However, it is obvious that I cannot review all build errors on all modules for all the slaves, besides it makes not much sense… for me, the good way to go here would be that project maintainers and core developers (at least) subscribe to the modules they are experts on and whenever they receive notification that any of these projects fail to build, drop by the buildbot and check what’s going on with it. I’m sure they’ll know better and will realize sooner in most cases what’s going on there, so they can fix the problem in the repository if needed or give feedback to us so we can fix the build for that module (for example using appropriate build flags, installing missing dependencies, etc.).
Btw, I removed the test coverage stuff to build scrollkeeper successfully at least once, so modules failing to build due to its dependency on this module can build. Unfortunately, I see that gnome-doc-utils failing to build is also causing a lot of build problems in other modules. Is there anyone who can help us out to fix this build error?:
xsltproc -o “C/db2html-bibliography.xml” \
–stringparam basename “db2html-bibliography” \
–stringparam xsl_file “/usr/local/buildslave/gnome/work/src/gnome-doc-utils/doc/xslt/../../xslt/docbook/html/db2html-bibliography.xsl” \
“./xsldoc-docbook.xsl” “C/db2html-bibliography.xsldoc”
db2html-bibliography: No documentation for template mode l10n.format.mode
See complete Log here.
Bad Behavior has blocked 13 access attempts in the last 7 days.