:::: MENU ::::

Login as SuperUser on Murmur / Mumble-server on Debian

I’m trying out Murmur / Mumble-server at the moment for conference calls and meetings for FSFE campaigns. The service is great, and audio quality top-notch. Installation and configuration was generally very simple.

In order to have private conversations however (where uninvited users cannot participate), you must first log in as the pre-configured admin user, called ‘SuperUser’. Achieving that was rather confusing on Debian, so for future reference, here’s how to do it.

  1. Set the SuperUser password via the Murmur server CLI:

    sudo /usr/sbin/murmurd -ini /etc/mumble-server.ini -supw <password>

    You must run the command as root, and you must specify the .ini file. Do not use murmur-user-wrapper, which Debian provides.

  2. Connect to the Murmur server using the Mumble desktop client, specifying username SuperUser, and the password that you set above.

Good luck!


Install Ardour 3.1 on Fedora

Ardour 3 is the most powerful Free Software music software currently available. Although Fedora isn’t a GNU/Linux distribution that’s designed for audio professionals, with a little work it can be configured to process sound with low-latency (without 20+ millisecond delays or artefacts like pops and crackles), and get easy access to repositories with many recent pro-audio apps.

We’ll compile Ardour from its source code in this tutorial, because this will get us the very latest version (with features and bug fixes missing from older copies), and because Ardour recently switched to a payment-oriented package distribution model which promotes source compilation as the installation method for people who aren’t Ardour donors.

We’ll also set up the CCRMA package repositories, which contain many audio apps not found in the default Fedora repos, and most importantly will supply us with a real time kernel (which Ardour, and low-latency operation in general, requires). The CCRMA repos are provided by the Stanford Center for Computer Research in Music and Acoustics.

These instructions are designed to work with Fedora 18 and Ardour 3.1.1, though I expect they will work as well with later versions of both. If not, let me know and I’ll try and tweak the guide.

  1. Install package dependencies required by Ardour:
    yum install git jack-audio-connection-kit-devel libsndfile-devel liblo-devel aubio-devel cppunit-devel cwiid-devel liblrdf-devel libsamplerate-devel lv2-devel serd-devel sord-devel sratom-devel lilv-devel flac-devel gtkmm-2.4-devel gtkmm24-devel libgnomecanvas-devel libgnomecanvasmm26-devel suil-devel libcurl libcurl-devel uuid uuid-devel libuuid libuuid-devel lib fftw3 fftw3-devel liboggz liboggz-devel
  2. Setup the CCRMA repositories (more detailed info in the Fedora manual):
    su -c 'rpm -Uvh http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/
    planetccrma/13/i386/planetccrma-repo-1.1-2.fc13.ccrma.noarch.rpm
  3. Update existing packages and refresh what’s available:
    yum update
  4. Install real-time (low-latency) kernel and drivers from CCRMA:
    yum install planetccrma-core
  5. Reboot your machine to use your new real-time kernel.
  6. Download Ardour via  Git and compile it by following the simple official instructions (see “Building Ardour 3.x”). I recommend not installing Ardour unless you really need to (installing is the final step in the official instructions that simply creates links within Fedora’s menus etc. and isn’t required for compiling / running / using Ardour).
  7. Start the jack sound server by running qjackctl (either from system menu or CLI), and click on “start”.
  8. Run your newly compiled Ardour (execute this from within the directory you compiled Ardour in):
    cd gtk2_ardour
    ./ardev

Those are all the necessary steps and you should now have a fully functional copy of Ardour! I recommend installing some additional LV2 plugins however to extend the built-in MIDI instruments that are available within Ardour.

  1. (Optional) Install additional synthesisers for Ardour:

sudo yum install lv2-triceratops lv2-synthv1 lv2-calf-plugins lv2-calf-plugins lv2-mdaEPiano

Those synths should appear automatically as available MIDI instruments when you restart Ardour.

I hope that running Ardour in the way I’ve described will whet your appetite to dive more deeply into audio production on GNU/Linux. If so, I recommend using a dedicated GNU/Linux distribution for audio work, because it’ll provide you with many more tools and features, and save you having to manually configure them all yourself. For now KXStudio is my clear favourite.

Good luck, and let me know how you get on in the comments 🙂


Use Twidere Twitter client with identi.ca

Twidere is a great Free Software Twitter client for Android that also works with identi.ca. The identi.ca server must be configured manually however in order to do this. The below instructions work with Twidere 0.2.1.

  1. Tap the accounts tab (fourth icon from left with multiple human silhouettes)
  2. Tap the ‘+’ button top right to add a new account
  3. Tap the server icon top right next to the spanner icon to configure the server
  4. Change the REST Base URL to https://identi.ca/api
  5. Set the Auth Type to ‘Basic’
  6. Tap OK
  7. Enter your identi.ca username and password
  8. Tap ‘Sign in’

That’s it! Good luck.


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.

Proposals

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

Speakers

  • 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:
    ./DartEditor
  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:
    tools/android
  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.