:::: MENU ::::

Make your ownCloud app compatible with the new filecache

Robin Appelman has recently rewritten ownCloud’s filecache components, and made a variety of improvements to the filesystem handling classes. Some of the changes break compatibility with existing apps however, especially if they use the filecache directly.

I have just finished making the encryption app compatible, and here are the instructions I followed (originally posted by Robin to owncloud@kde.org):

OC_Filesystem and OC_FilesystemView have been renamed to OCFilesFilesystem and OCFilesView. For backwards compatibility they are still available under their old name for now but that will probably change in the future.

The filesystem cache is accessible with the following functions:

  • OCFilesFilesystem::getFileInfo($path)
  • OCFilesFilesystem::putFileInfo($path)
  • OCFilesFilesystem::getDirectoryContent($path)
  • OCFilesFilesystem::search($query)
  • OCFilesFilesystem::searchByMime($mimetype) (accepts both ‘text/plain’ and wildcard ‘text’ style mimetypes)

If you need to access the cache for files outside the user’s home directory, the same functions are available in OCFilesView.

Enable USB debugging mode on CyanogenMod 10

To enable the developer options settings in CyanogenMod 10 you need to do something quite obscure:

Go to Settings -> About Phone -> click “Build Number” six times in a row.

This information is available elsewhere, including where I found it, but hopefully reposting here will make it easier to find.

Run ownCloud Cucumber tests on Fedora 17

ownCloud uses automated testing to check for problems, and writing and executing these tests is important for any contributor. In my capacity as an ownCloud systems developer I use these tests to quickly verify that my apps don’t break after merging or pulling new code. For those less familiar with Ruby however, getting the Cucumber based behaviour tests running can be confusing. Here’s how to do it on Fedora.

  • Install the necessary dependencies:
    sudo yum install libxslt libxslt-devel libyaml libyaml-devel xorg-x11-server-Xvfb openssl-devel
  • Install RVM. If you have previously installed it, you may need to reinstall it so that the newly available libraries are used:
    sudo rvm install 1.9.3
  • Install the Selenium gem:
    sudo gem install selenium-webdriver
  • Clone the acceptance-testing repository from GitHub:
    git clone https://github.com/owncloud/acceptance-testing
  • Switch to root (su), and enter the newly created directory (this will trigger the .rvmrc shell script):
    cd acceptance-testing
  • Accept the warning and agree to run the script
  • If the script encounters errors (e.g. “RVM not found” or “RVM is not a function”), then open a new terminal, and repeat steps from “Switch to root”.
  • If you are testing a copy of ownCloud running locally on your machine, start your webserver, e.g.:
    service httpd start
  • Run cucumber to execute the tests:
    cucumber HOST=foo.bar.com features

The future of quality and testing in ownCloud

At the last ownCloud sprint in Berlin we ran a workgroup on QA and testing. In my capacity as an ownCloud systems developer, myself and four others spent a day working on how to improve the quality and stability of ownCloud in future, with a particular focus on tools and automation of checks and reviews.

The result was a set of proposals which I presented to sprint attendees on the last evening. Only 24 hours after we had come up with these ideas, some had already been implemented, and by the end of the sprint, one of the most important ones — a peer-review based work-flow — had been agreed and adopted. This is testament to the benefits of centralised sprints – with so many important people in the same room we were able to develop ideas, share them, and even execute some of them in a single weekend!

Below are the original proposals made at the sprint. Look out for status indicators like [DONE] and [IN PROGRESS]. Please note that these are just proposals, and not an agreed roadmap. Some of the ideas are good and have been implemented, but others may not be so good, and may not be implemented.

Share your own views either in the comments or on the ownCloud public mailing list.


Issue tracker management

  • We can Improve communication of where to report bugs
    • Add a link to the GitHub issue tracker in main nav-bar and/or at top of developer homepage nav
    • Remove “bug reports” and “feature requests” section of the forum [IN PROGRESS]
    • Identify and consolidate contact platforms and support them equally well, or remove
  • We can make reported bugs more useful
    • Define labels on github issues [DONE]
    • Use issue milestones
    • Publish who maintains which apps/features (see New feature introduction)
    • Formalise bug triaging process – consider appointment of an official bug quality controller

New feature introduction

  • App / feature mini-specifications
    • Adopt convention of writing explanations of key features / goals of apps
    • Contain a few paragraphs or bullet points only
    • Include them in info.xml using <spec> tag?
    • This way other developers can spot high-level opportunities and issues early on
  • Implement a code review system
    • Short term: use GitHub’s pull request system for all commits to ‘Stable’ and ‘Master’ branches, perform code reviews before changes are merged, and integrate the ownCloud CI server into the pull request workflow [DONE]
    • Long term: consider using a stand-alone web-based code review system like Gerrit
    • Potential benefits:
      • Ensure all changes are checked by humans before
        commit (chain of responsibility)
      • ‘Stable’ branch doesn’t get broken
      • Integrated peer review
      • Integrated automated test suites
      • More open governance
      • A cleaner git history (easier identification of
        issue origin)
      • Easy extendability of checks (security)
      • Automated code quality checks
      • Specifically, by integrating ownCloud’s existing JenkinsCI server into the process we can:
        • Ensure all changes pass existing automated tests before commit (PHPUnit, Cucumber, others)
        • Define additional tests for common issues (code sniffers, correct use of API etc.)
        • Check for security problems (e.g. error_log(), file upload, echo in templates)
        • Give contributors automated feedback before another human has to review it (simple errors are automatically spotted and notifications sent)

Isolation of functionality and apps

  • Long term goal:
    • Move towards object-oriented code, away from static methods (see coding standards)
  • Short term goal:
    • Make internals more independently testable by decoupling static dependencies (dependency injection) [DONE]
    • Abstract away static method calls one level to allow the use of alternatives in unit tests (mocking objects )
    • Instead of OC_User::getUser('foo'); use $api->OC_User->getUser('foo');
    • Potential benefits:
      • Enables isolation of functionality under test
      • Doesn’t affect existing code (usage is voluntary)
      • Supports multiple versions of internal ownCloud API (provides a compatibility layer between apps etc.)
      • Very simple to use (just add $api-> before existing class names)

Bugfixing workflow

  • Proposed bug-fixing procedure (for PHP):
    • Reproduce the bug
    • Write a unit test which isolates the behaviour
    • Check the test fails and confirms the issue
    • Fix the bug
    • Check the unit test now passes
    • Mark bug fixed

Release procedure, security announcements

  • Promote the security list, push public to use it instead of bugtracker via website links
  • Ensure release procedure includes checking CI server test status
  • Expand existing unit tests (see Isolation of functionality and apps & New feature introduction)
  • Ensure all necessary apps are enabled on CI server for tests leading up to new release

Coding standards (link)

  • Add code-sniffers to CI to identify problematic code (see New feature introduction)
  • Add recommendation for object oriented code (see Isolation of functionality and apps)
  • Add requirement of mini-spec files (see New feature introduction)
  • Add requirement of DocBlock comments for all classes and methods
  • Disallow use of dangerous functions in templates [DONE]
  • Add policy on word order of “public static function”

Parliamentary candidates challenged to digital debate in Manchester

19.00, 7th Nov at the Dancehouse Theatre, Manchester, UK – Free Entry

Manchester Central candidates will be challenged to explain how they will defend citizen’s privacy and free speech online.

Recent arrests for “offensive tweets” and proposals to put the whole UK population under Internet surveillance and data collection have thrown digital issues into the forefront of political debate.

Candidates will be asked how they will protect Manchester’s voters from dangerous Internet policies, and also ensure that the local digital economy is supported.

Newly formed Manchester Open Rights Group has teamed up with NUJ New Media, No2ID Manchester and Free Software Foundation Europe to run the event which is being widely promoted.

Presentations will also be followed by a Q and A and debate giving the public a chance to quiz candidates on issues effecting one of Manchester’s largest and fastest growing industries.

As well as the digital economy, we invite comments and questions on the use of the Internet for social change and views on the proposed increase in powers of surveillance.

Free Tickets are available from http://www.thedancehouse.co.uk

There is a booking cost if you book online – But you can get a free reservation by ringing the Dancehouse Box Office on 0161 2379753


  • Tom Dylan – Green Party
  • Marc Ramsbottom- Liberal Democrats
  • Loz Kaye – Pirate Party
  • Lucy Powell (invited) – Labour
  • Matthew Sephton (invited) – Conservatives

With support from

  • Peter Bradwell – Open Rights Group
  • Martin Bryant – Managing Editor, The Next Web
  • John Robb – Louder than War

Supporting organisations

  • National Union of Journalists
  • New Media Industrial Council
  • Free Software Foundation Europe
  • Manchester Open Rights Group
  • Manchester No2ID.

Press contacts: Mick Chesterman 0044 7913 882193, Tom Chiverton 0044 7967 672404

Install Google Dart language on Fedora 17

The JavaScript related Dart language has a compiler and IDE provided by Google. The project developers work on Ubuntu, and so in order to get these tools working on Fedora we have to make a couple of preparations. These instructions are designed for Fedora 17 64-bit, and were tested using Dart version 14167.

Dart is non-copyleft Free Software using a BSD license.

  1. Install the required packages:
    yum install subversion pkgconfig python perl gcc-c++ bison
    flex gperf nss-devel nspr-devel gtk2-devel glib2-devel freetype-devel
    atk-devel pango-devel cairo-devel fontconfig-devel GConf2-devel
    dbus-devel alsa-lib-devel libX11-devel expat-devel bzip2-devel
    dbus-glib-devel elfutils-libelf-devel libjpeg-devel
    mesa-libGLU-devel libXScrnSaver-devel
    libgnome-keyring-devel cups-devel libXtst-devel libXt-devel pam-devel
  2. Link your bzip2 library so that Dart can find it:
    ln -s /lib/libbz2.so /lib/libbz2.so.1.0
  3. Download and extract Dart from http://www.dartlang.org/
  4. Open a terminal and cd into your Dart directory, e.g.:
    cd ~/Downloads/Dart
  5. Run Dart:
  6. Open one of the included demo projects, open a .dart file, click ‘Run’ (green ‘play’ button in toolbar), and see Dartium open the freshly compiled project.

Install Android Emulator in Fedora 17

Android emulator allows you to test apps and websites from an Android user’s perspective, without the need for a physical Android device. The Emulator does not work “out of the box” in Fedora however, and only a version for 32-bit machines is provided. Additional packages are required, and the GUI must be started from the command line. These steps are designed for 64-bit machines, but they should also work on 32-bit ones as well.
android emulator screenshot

  1. Install the additional packages which the emulator depends upon:
    yum install libstdc++.i686 glibc.i686 ncurses-libs.i686 libstdc libstdc++.i686 libzip.i686 libX11.i686 libXrandr.i686 SDL.i686
  2. Download the Linux edition of the emulator from Google: http://developer.android.com/sdk/index.html
  3. Extract the downloaded archive (open your Downloads folder right click on the file, “extract here”)
  4. Open a terminal, change directory to the folder you have just extracted:
    cd ~/Downloads/android-sdk-linux/
  5. Run the emulator:
  6. Once the repository has automatically updated itself, download the packages that have been automatically selected for you (click “install packages”)
  7. Open the Virtual Device manage window from the menu: “tools” > “Manage AVDs”
  8. Click “new” to create a new AVD, use default settings
  9. Highlight your new device and click “start”, then “launch”

The emulator should now boot up after a few seconds and allow you to use the device.

Install Webgen in Fedora 17 with Ruby 1.8.6 and RVM

Webgen does not work with new versions of Ruby. Using Webgen installed using ruby and rubygems from Fedora repos results in errors including “obsolete and deprecated Config”.

To get webgen to work, we will use RVM (Ruby Version Manager). This allows you install multiple versions of ruby side by side. RVM is not available in Fedora repositories, and must be manually installed.

  1. If you have already installed ruby from a repository, remove it:

    yum remove ruby ruby-libs rubygems

  2. As root, install RVM, and follow the on-screen instructions:

    curl -L https://get.rvm.io | bash -s stable --ruby
    Note: the leading backslash () is intentional and could be important

  3. Install Ruby 1.8.6:

    rvm install 1.8.6
    Note: you can see what versions are available to install using: rvm list known

  4. Switch to use Ruby 1.8.6 by default:

    rvm use 1.8.6
    Note: You can check that it worked using: ruby -v
    Note: If you want this to be permanent, for all shells, and not just the terminal you’re currently using, execute: rvm use 1.8.6 –default

  5. Install webgen:

    gem install webgen

  6. That’s it! Good luck.

Results: Free Software voice & video testing

Last weekend on Software Freedom Day the Manchester FSFE Fellowship group, assisted by additional participants in Britain and Germany, spent the afternoon testing Free Software alternatives to Skype.


The 25 sets of results were recorded, and can be browsed, sorted, and searched on the news article edition of this post.

Six audio tests successfully passed (24%), as did five video tests (20%). Mumble was the most successful client, passing 100% of tests (audio only, video is not yet supported). XMPP passed four out of 14 audio tests, whereas SIP passed only one out of ten (both video and audio). Of nine apps tested, only Mumble, Pidgin, Jitsi, and Google Talk’s web client achieved passes.

results table
Chat testing results table


The clients tested performed more poorly than expected, probably due to network problems. One of the difficulties in testing was that generally there was little or no information about why the test had failed.

SIP clients couldn’t connect successfully except when both testers used the same client, and had accounts on the same SIP server. This was surprising, especially considering that the accounts used for testing were is many cases paid for and commercially supported.

The only client and protocol which consistently did what it promised was Mumble, which had 100% test pass rate. Unlike all other clients, Mumble uses its own protocol, and also offers audio conferencing and text-to-speech by default. Mumble users are constrained to using the same server however, unlike SIP and XMPP users who should theoretically each be able to use a separate server of their choice.

It would have been useful to have a local SIP and XMPP server on the same network as the testers in order to better identify network related problems. This could have helped determine whether failures stemmed from the client, network, or server..

Examining STUN and ICE configurations was beyond the scope of our tests, but as these technologies seem critical to whether calls succeed or fail, they merit careful examination when choosing or configuring SIP and XMPP servers.

FSFE Fellows will be pleased to note that XMPP calls using FSFE’s own XMPP server were often successful: several volunteers could see and hear each other when both were using their @jabber.fsfe.org accounts.

A Skype alternative?

Skype uses a variety of notorious methods to punch through network obstacles like firewalls, and to ensure it can locate the intended call recipient wherever they may be. It also benefits from being a centralised system where, if necessary, all roads lead to Rome (or a Skype managed server, at least).

Contrastingly, Free Software systems play by conventional rules of network traffic, and try and connect callers using established procedures. They also have to communicate with a variety of different servers, which may operate in ways they don’t know or expect. In addition to this, some of the chat clients that we tested have only recently added support for more than text-based chatting (Gajim in Debian testing is too old for video, for example), and probably add a few problems of their own into the mix.

Based on our test results, those looking for a Free Software Skype alternative should use either Mumble, or SIP with all callers on the same server and using the same client.

Moving Forward

We had hoped to publish a conclusive compatibility table of chat clients, providing a reference for people needing to know “what works with what”, and “what is easiest”. Instead, we have table of subjective results, and a list of questions:

  • How can we determine whether an XMPP server supports audio and video (‘Jingle‘)?
  • How can we gather more detailed information about why a call failed?
  • How can we determine whether a SIP or XMPP server supports STUN (and should therefore be less prone to network issues)?

If you have answers to these questions, please share them in the comments!

Install Rar in Fedora 17: make rar archive files

Plenty of resources explain how to install unrar support in Fedora, but what about when you need to create rar files, instead of merely extracting them?

Rar has licensing issues which is why it isn’t available in standard Fedora repositories. The package ‘Unrar’ is available in rpmfusion repositories, but to get rar compression support you can install one of these two non-Free packages:

rar-3.8.0-1.el6.rf.i686.rpm (32 bit)
rar-3.8.0-1.el6.rf.x86_64.rpm (64 bit)