dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Search | Go
Wiki > Main > DevCon > DevCon2012 > DevConEuro2012

Rockbox Developer Conference - Euro Edition! 2012

Date and Location

When: 18-20 May 2012

Where: Hasselt, Belgium. The location is upstairs (one floor up), and therefore isn't wheelchair accessible.


These people are going to show up. Please add your route/airport and expected time of arrival.


Since we can code and IRC at home, too, we should focus on helpful group activities.

  • Conference room will be available from 13:00

  • T.B.D.
  • T.B.D.

Ideas for discussion
  • Voice strings on target
  • Testing
  • Stable targets without active maintainers
  • MinGW build of the Sim in the build system
  • Manual in the build system
  • Daily vs. archived builds, and archived builds support in Rockbox Utility
  • Naming (see forum thread / Mailing list thread)
  • Rockbox Utility binaries on Linux / distribution packages
  • PNG support in core
  • fms for official cabbie
  • Toolchains distributed as linux packages (.deb, .rpm, etc.)
  • gerrit patch series that aren't ordered nicely

Ideas for hacking
  • Stable, RC, and patch testing builds using the build system
  • Update the translation site to use git
  • Resolve H300 bootloader issues


Bring your own laptop and DAP devices of choice. There should be enough power outlets, although only European. Bring converters if you need them. Unrestricted wifi access ethernet access will be available. A USB hub might be helpful. A webcam for friends who can't attend physically would be great (see below).

Feel free to add extra things onto this list if you feel it is necessary (such as unported targets/etc)

  • Basic Tools, paperclips, soldering stations,... - PeterDHoye (soldering station)
  • Espresso machine - FrankGevaerts (nespresso)

How to get there

  • From Brussels airport
    • Take the train to Leuven or Brussel Noord. From there take the train to Hasselt. Ask at the airport railway ticket desk, the people there will know. From Hasselt station see "By train"

  • By train
    • Find a train that stops at Hasselt station.
    • From Hasselt station, either:
      • call FrankGevaerts and ask to be picked up. This is easier if several people arrive at about the same time.
      • take bus H1 direction Kermt to stop "Kuringen Kuringenstraat" or "Kuringen McDonalds". Ask if you're on the right bus.
      • walk. route. This is about 3km next to busy roads, so not a very enjoyable walk.

  • By car
    • On the E313 (Antwerp-Liege):
      • if you're coming from Antwerp/Brussels: take exit 27bis (Hasselt-West) and follow direction Hasselt
      • if you're coming from Liege: take exit 27 (Hasselt-West) and follow direction Hasselt
    • After about 500m to 1km, at the traffic lights (with a McDonalds on your right) turn right and park on the supermarket car park.
    • Now walk to the DevCon location, using the following pictures as a helpful guide:


  • From Maastricht airport
    • (these directions have not been verified, use at your own risk) Take the shuttle bus to Maastricht station. From there, take the bus to Hasselt station. From there, follow the "by train" directions.

  • From Brussels South airport (which is near Charleroi and not actually Brussels)
    • (these directions have not been verified at all, use at your own risk) There might be a shuttle bus to Charleroi station. From there, take a train to Brussels (either Midi, Central, or North), and from there take a train to Hasselt. This is not a very convenient option.




Local language is Dutch.

Hotels and Room Sharing

  • The nearest hostel is De Roerdomp, around 12 km from the conference location. Add your name here if you want to share a room there.
  • Hasselt has several hotels at around 3 to 4 km from the conference location.
  • Most have choosen to stay at the Ibis hotel in Hassselt
    • petur and pamaury share a room
  • We will have breakfast at the conference location


We can buy beer at the supermarket next door. Possible pub visits will have to be investigated.


There are several restaurants and fast food places nearby. The supermarket next door will have anything we need on the conference location.


Meeting minutes

  • Voice strings on target (
    • DominikRiebeling proposes to include voice strings in the build to:
      • reduce dependency on the server (allow offline use, and easier server restructuring. e.g. svn builds aren't supported any more by the server side now),
      • allow using rbutil for builds that the server doesn't know about
    • Nobody thinks size is a big problem
    • Proposal: only store voice strings that differ from main strings:
      • savings not worth the extra complication
    • Proposal: one voice string file for all language to reduce FAT overhead
      • probably worth it
    • Extra advantage: this will be needed if we ever have a TTS in core
    • Conclusion: If someone wants to do the work, go for it.

  • Stable targets without active maintainers (
    • m:robe100 has broken audio in 3.11.
    • Testing system will improve this
    • How do we deal with this?
    • If a target is not known working, don't include it in the release
    • Fix: make rbutil able to install the previous release. This only requires server-side changes, RockboxUtility can already handle this. Have know about exceptions. RockboxUtility should tell the user if the target misses the latest stable release.
    • People doing support need to be aware of this
    • Advertise targets as stable on the front page if they're not at the latest release? Yes
    • Long-term target, "RC not tested -> no release". This obviously depends on the testing system

  • Manual in the build system (
    • prerequisite: clean up latex errors (or filter them)
    • Build the pdf manual and see if it's there. Normally if there is an error it won't be generated (html is not reliable for this)
    • Conclusion: this is useful, but the issues need to be resolved. First step: have a non-uploading pdf build.

  • Naming (see forum thread / Mailing list thread) (
    • Conclusion: implement as proposed, rbutil work remaining, shout at people using the wrong names. (main change: current build -> dev build or latest dev build)

  • Rockbox Utility binaries on Linux / distribution packages (
    • Many reported distribution-specific issues
    • Distribution-created packages will likely result in people using outdated versions
    • The actual problem seems to be that rbutil isn't linked statically enough
    • Someone needs to experiment with this. TorneWuff may volunteer.

  • PNG support in core (
    • Useful for theming, mainly on android where resolutions tend to be high and apk storage space is sometimes restricted
    • This probably has to be disabled on lower-spec hardware.
    • No objections if someone does the work.
    • Also useful for album art
    • Skin support for backdrop gradients partially address the same issues, but nobody thinks this is a reason not to add png

  • fms for official cabbie (
    • General issue: touchscreen cabbie is buggy.
      • One problem here is that skins are resolution-dependent.
      • ThomasMartitz is working on resolution-independent skins, but there are some doubts involving rounding error induced artefacts.
      • An Android-style (or other UI toolkit) layout engine is CPU-intensive
    • doesn't handle fms, and it's not easy to fix this
    • This seems to be the main blocker for fms in cabbie in the default build.
    • MarcinBukat has an MPIO fms file ready which he will commit.
    • The backdrop font on cabbiev2 seems to be unknown/missing, which makes new backdrops tricky to make

  • gerrit patch series that aren't ordered nicely (
    • We have a patch series on gerrit for IAP support, but it's not split the way we would like it. How do we deal with this?
    • In the future we want people to work with us sooner on this sort of thing. We do want linux-style patchsets
    • It is unreasonable to ask to rework the build order, so we will ask the author to flatten it. If needed, someome else can flatten it too, but the original author doing it is nicer.
    • The change id of the first patch should be kept, the other changes can then be abandoned.
    • No active rockbox developer knows enough about IAP to review this usefully.
    • BertrikSikken will handle this and talk to the patch author to get a flattened patch and ask to involve developers earlier next time.

  • How is git/gerrit working? (
    • Most people are happy, some people still dislike git.
    • Gerrit theming has not been done. Nobody thinks this is important
    • Commit emails are still missing (BjornStenberg)
    • Commit numbering is still missing (TorneWuff)
    • UsingGit instructions are basic and assume an svn-style workflow. It needs to be expanded. TorneWuff may work on this, but wouldn't mind someone else picking this up. Most instructions on the web assume merge-based workflows while rockbox wants to rebase.


-- FrankGevaerts - 18 Mar 2012

r30 - 02 Apr 2021 - 20:46:06 - UnknownUser

Parents: DevCon > DevCon2012
Copyright © by the contributing authors.