Fixing Broken Dropbox Sync Support

Like many people, I've been using Dropbox to share files with friends and family for years. It's a super convenient and easy way to get files syncronised between machines you own, and work with others. This morning I was greeted with a lovely message on my Ubuntu desktop.

Dropbox says 'no'

It says "Can't sync Dropbox until you sign in and move it to a supported file system" with options to "See requirements", "Quit Dropbox" and "Sign in".

Dropbox have reduced the number of file systems they support. We knew this was coming for a while, but it's a pain if you don't use one of the supported filesystems.

Recently I re-installed my Ubuntu 18.04 laptop and chose XFS rather than the default ext4 partition type when installing. That's the reason the error is appearing for me.

I do also use NextCloud and Syncthing for syncing files, but some of the people I work with only use Dropbox, and forcing them to change is tricky.

So I wanted a solution where I could continue to use Dropbox but not have to re-format the home partition on my laptop. The 'fix' is to create a file, format it ext4 and mount it where Dropbox expects your files to be. That's essentially it. Yay Linux. This may be useful to others, so I've detailed the steps below.

Note: I strongly recommend backing up your dropbox folder first, but I'm sure you already did that so let's assume you're good.

This is just a bunch of commands, which you could blindly paste en masse, or, preferably one-by-one, checking it did what it says it should, before moving on. It worked for me, but may not work for you. I am not to blame if this deletes your cat pictures. Before you begin, stop Dropbox completely. Close the client.

I've also put these in a github gist.

# Location of the image which will contain the new ext4 partition

# Current location of my Dropbox folder

# Where we will copy the folder to. If you have little space, you could make this
# a folder on a USB drive

# What size is the Dropbox image file going to be. It makes sense to set this
# to whatever the capacity of your Dropbox account is, or a little more.

# Create a 'sparse' file which will start out small and grow to the maximum
# size defined above. So we don't eat all that space immediately.
dd if=/dev/zero of="$DROPBOXFILE" bs=1 count=0 seek="$DROPBOXSIZE"

# Format it ext4, because Dropbox Inc. says so
sudo mkfs.ext4 "$DROPBOXFILE"

# Move the current Dropbox folder to the backup location

# Make a new Dropbox folder to replace the old one. This will be the mount point
# under which the sparse file will be mounted

# Make sure the mount point can't be written to if for some reason the partition 
# doesn't get mounted. We don't want dropbox to see an empty folder and think 'yay, let's delete
# all his files because this folder is empty, that must be what they want'
sudo chattr +i "$DROPBOXHOME"

# Mount the sparse file at the dropbox mount point
sudo mount -o loop "$DROPBOXFILE" "$DROPBOXHOME"

# Copy the files from the existing dropbox folder to the new one, which will put them
# inside the sparse file. You should see the file grow as this runs.

# Create a line in our /etc/fstab so this gets mounted on every boot up
echo "$DROPBOXFILE" "$DROPBOXHOME" ext4 loop,defaults,rw,relatime,exec,user_xattr 0 0 | sudo tee -a /etc/fstab

# Let's unmount it so we can make sure the above line worked
sudo umount "$DROPBOXHOME"

# This will mount as per the fstab 
sudo mount -a

# Set ownership and permissions on the new folder so Dropbox has access
sudo chown $(id -un) "$DROPBOXHOME"
sudo chgrp $(id -gn) "$DROPBOXHOME"

Now start Dropbox. All things being equal, the error message will go away, and you can carry on with your life, syncing files happily.

Hope that helps. Leave a comment here or over on the github gist.

Akademy 2018 Trip Report

I recently had the opportunity to attend Akademy - the annual world summit of KDE. This blog post covers my experience of the event, and is mostly a brain-dump memory aide. Akademy attracts KDE developers, enthusiast users and others from the wider Qt, KDE and distro communities. The event is a week-long in-person combination of talks and BoF (Birds of a Feather) sessions. This year Akademy was held at TU Wein in Vienna, Austria.

I'd never attended Akademy before, as I am not a KDE developer, and only recently starting running Plasma on my ThinkPad T450. My employer - Canonical - is a sponsor of the KDE project, and a silver level sponsor of Akademy. A recent reorganisation inside Canonical meant I was able to take someone else's place at the last minute. So I booked travel and accomodation to attend from Saturday to Tuesday.

I understand many of the talks / sessions were recorded, and may appear on the KDE Community YouTube Channel at some point.

Day 0

Akademy kicks off with a pre-event meet-and-greet with drinks and buffet food on the Friday night. This was a great opportunity to put names to faces, get a better understanding of the week's structure from regular attendees and have some delicious nibbles and Club Mate. The event has a dedicated micro-site which covers all the details including schedules, venue details, social events and travel recommendations. Bookmark that site, and you're set for the week.

Day 1 & 2

Saturday and Sunday are mostly talks / discussions / reports. These are some notes I took from the ones I attended. Here begins the brain dump.

Akademy proper starts on the Saturday morning with a set of talks & presentations and finally reports from KDE Working Groups. The keynote from Dan Bielefeld was titled "Mapping Crimes Against Humanity in North Korea with FOSS", and was both upsetting and fascinating. It detailed the work the TJWG (Transitional Justice Working Group) do in South Korea to gather data regarding crimes against humanity occuring in North Korea. Dan outlined the group, their work and highlighted some data they've gathered, then went on to discuss the Open Source tools they use to do their job. I'd recommend reading the report available as a PDF from the TJWG website.

Next up was a set of talks from developers across the KDE community who work on all parts of the stack, from plasma desktop to PIM (Personal Information Manager) to Plasma Mobile. Each gave some detail from their project about how they all work in tandem to highlight how privacy is important to KDE developers and users. We heard that KDE Software doesn't 'leak' data, to promise users a better experience.

One highlight here was from Volker Krause who talked about the intrusive work large companies do analyse emails for travel information. In a section titled "Does Google really need to read your emails so you know when your next flight is?", Volker outlined why these features are problematic for users who value privacy. He also went on to introduce features landing in KDE PIM 18.04/18.08 which will gather flight data and render usable boarding cards, while respecting user freedom and privacy. This introduced a talk later in the week which would go into this in more detail.

Also in this session were details of how KMail will make it easier for users to send/receive and store GNUGP encrypted mail, but have the capability to search inside the mails without decrypting each one. In addition the KMail developers plan to make it easier to validate mails without user intervention, automatically discover keys for encrypted mails and derive trust based on communication history, so users don't need to choose which key to use.

Finally in this session, Bushan Shah talked about Plasma Mobile, and how it differs (from a privacy perspective) from the encumbent mobile OS vendors. He reiterated that with KDE 'your data is safe with us' as with Plasma Mobile 'your data is safe in your hands'. He also briefly talked about how they plan to keep software updated on the Plasma Mobile platform.

Neofytos Kolokotronis presented next with his experience of "Streamlining Onboarding of new Contributors" within the KDE community. With KDE being a diverse community with dozens of projects & hundreds of contributors, there's not a central process for onboarding new contributors. So Neofytos covered his experience in building a better onboarding process, and highlighted numerous suggestions for how KDE projects can imrove the on-ramp for new people. I found this talk very engaging, with plenty of useful information which could apply to any open source distributed project.

In the afternoon some shorter talks stood out for me. David Faure ran a session on "Running without installing" - detailing how developers can test and develop KDE applications without messing up their host installation. This dovetailed nicely with the morning talk about onboarding new users. Often times new contributors only have one computer, and don't want to mess it up with random rebuilt libraries and other components to test if a bug they reported is fixed. David covered some of the things he's learned about separating out the things you're testing, which I feel could be useful for other projects too.

Lays Rodrigues gave her first talk (which went very well) about Atelier - a KDE application for managing 3D printers. This was interesting to me as I recently acquired a 3D printer, and was keen to learn of tools I can use to manage prints. I'd not heard of Atelier (and Atcore) before, so this was a great primer for me. It's early days in the project but they already support numerous 3D printer standards and can remotely monitor them via webcam. It even supports setups with muliple printers, such as organisations who print for a fee on demand.

Zoltan Padrah gave demo and some history of the KTechLab project, which I'd also never heard of before. It's a ciruit simulator, enabling users to drag and drop electronic components onto a layout and hook them up with wires. It's a great little tool which would appeal to a younger audience who are getting started with electronics. KTechLab has been around for quite a while, but hasn't had a lot of contributors recently. Unfortunately the application isn't available in many distributions, partly because it still uses some KDE 3 technologies. Zoltan is hoping to get more contributors so they can move the application forward to newer frameworks.

At the end of the first day was a series of reports from various KDE Working Groups. I understand this was a relatively new concept in KDE. 5 Working Groups were setup as System Admin, Fundraising, Finance, Community and Advisory. Representatives from each WG gave a brief report to the audience. These were relatively short, mostly detailing the impacts of their work as user/contributor numbers go up, or work gets done.

The number individual supporting members (sponsors) rose from 540 (last year) to 597 with 109 paying members (up from 99 last year). As a new attendee I was surprised to learn that KDE e.V. itself has only 3 'staff', one who manages accounting, travel booking etc and two Marketing Contractors who work on the KDE Promo Team. Akademy 2019 is not yet organised as no venue has been selected. This work is ongoing, but the KDE folks could do with help identifying a potential host. KDE received a significant ($200K) donation from 'Pineapple Fund', some of which was used to fund travel to Akademy. The project are still figuring out what to do with the rest. Previously KDE e.V. has been very cautious about how they spend funds, but there is a desire to change that. Perhaps hiring people / contractors to accelerate projects.

One of my favourite talks of the weekend was from Nate Graham titled "Konquering the world - A 7 step plan to KDE world domination". In it Nate covered very clearly 7 areas the KDE project needs to improve, and suggested improvements and their intended outcomes. This was a superbly positive talk, despite it raising some issues that have clearly been a problem for KDE for some time. I transcribed the notes, and shared via Twitter and Mastodon.

The final slot on the second day was for "Akademy Awards". Members of the KDE community were given public recognition for their contributions over the last year. This was a nice touch, a direct "thank you" goes a long way.


Starting on Monday, the much of the rest of the week was occupied with working and BoF sessions.

KDE Promo BoF

I was keen to sit on on this session as there's some overlap between my day job on Snapcraft and what the KDE Promo team are doing. We discussed the Debian PopCon (popularity contest) numbers for Plasma desktop, and how they are on the way upwards. It was noted that the Ubuntu PopCon is no longer functional.

We discussed social media strategies for promoting various KDE initiatives and releases. One of the KDE PIM developers was looking for assistance promoting the application, and finding new contributors. We discussed options including making appearances on technical podcasts to put out calls for contributors.

Overall an interesting session which made me want to get more involved in the promotion side of KDE. I've joined the KDE Promo Telegram & IRC channel to keep up to date with what's going on, and be aware of upcoming promotions which I can share or be involved in.

KDE Distro BoF

This was less of a BoF and more of a presentation round for each of the leading distribtions with some discussion afterwards. There were presentations from a few distros including Kannolo, Chakra, NXOS, LiMux, KDE Neon and others. It was interesting to hear the perceived unique selling point of each distro. We had a short discussion afterwards. Notably we discussed the ways in which distros deal with bugs and crash reports from users. I passed on some of our experience using the whoopsie crash reporter in (K)ubuntu, and our bug tracking activites in Launchpad.

Flatpak & Snap BoF

This session covered a lot of ground, mostly relating to improving support for the new packaging formats du jour. We discussed the support for Snaps and Flatpak in Plasma Discover - the graphical storefront for apps. There was a lot of detailed discussion regarding KDE runtimes, and how and where they may be built. Buildstream seemed like a possible candidate. KDE are keen not to have too much duplication of work to build multiple runtimes for the various new packaging systems. We discussed improving the documentation for building new packages, and I've committed to updating our documentation for building KDE snaps.

KDE Neon

The final (and longest) BoF I attened was the KDE Neon planning session. Harald led the session with a set of discussion points and planning activities for the KDE Neon project. A lot of the discussion was technical build system engineering, release planning and identifying progress blockers.

One highlight for me included discussion of when to sunset KDE Neon based on Ubuntu 16.04, and when to anticipate people to have moved to Neon based on 18.04. Given no expectations had been set in the user community, it was felt the devs could give a relatively short support window for Neon 16.04. Thanks to the snap store metrics for the pre-installed kde-frameworks-5, they were able to get a good handle on how many users were already moving to pre-release 18.04. This data will enable the Neon developers to gauge how well their "You should upgrade now" promotional work is going, and how many users are sticky on the older release.

We also discussed snap support in KDE Neon. The KDE Neon developers have limited time to work on creating & maintaining application snaps for Neon and other distros. We (Canonical) regularly catch up with the KDE developers, but we need to dedicate some more time to help debug and accelerate the building of the latest KDE leaf applications for their users. We've already started on this, but there's a lot to do, so will spread it over the coming weeks.

Final thoughts

As I left to catch my flight on Tuesday, I said my goodbye's to new friends and old at Akademy. As this was my first attendance, I wasn't exactly sure what to expect, but whatever those expectations were, they were exceeded. The KDE community is a warm, friendly, diverse and welcoming bunch of people. Everything was very well organized, relaxed and methodical. We have good notes to cover everyone's actions and can track progress on the plans for the coming months.

It reminded me of Ubuntu Developer Summits from 10 years ago. I absolutely loved spending time at Akademy, and would love to go again to a future event.

Ubuntu Core Laptop

I'm quite the fan of 'old' command line based systems. At college I learned to code on a DEC VT-100, and later, my very first PC had a green text-only display. I had to upgrade to hercules graphics card. Happy days.

I have also amassed a small collection of ThinkPads, which I tinker with in my spare time. Sometimes I'll nuke whatever is on an old ThinkPad and install something else for a bit of a play.

My latest project has allowed me to combine my love of middle-aged ThinkPads and a healthy nostalgia for command-line systems, while installing modern software. How? Ubuntu Core!

Ubuntu Core is a lightweight, small version of the Ubuntu I know and love, but with an interesting twist. It's built from the foundation of Debian packages in the archive, but once installed is comprised of snaps only. Software management is done via the snap command-line tool I'm familiar with on my 'classic' Ubuntu laptop.

Now, a word of warning, this isn't a comprehensive guide with step by step instructions. It's just a bit of a progress report of where I am with this little project.

dd is my installer

Ubuntu Core doesn't (currently) have an installer as such, so it's not as straightforward to install as a traditional Linux system. It's designed for system integrators to bake the image in at the factory, or for enthusiasts to 'dd' the baked image to an SD card for use in an Intel or ARM based board.

I consider myself an enthusiast, so we'll go down that route. However I'm not installing on an SD card system like a Raspberry Pi (although that is supported), I'm going to use one of my old ThinkPads, which boots of a typical hard drive.

Rather than dive right in and install Ubuntu Core onto the internal hard disk, I did a test run, by dd'ing the Ubuntu Core image to a USB key and booting the laptop from that. This all worked fine, so I went ahead to do the full 'install' on the internal drive.

Getting Ubuntu Core onto the hard drive wasn't actually too much of a challenge. Essentially all I did was boot the laptop from a traditional live Ubuntu desktop USB key. I then attached a second USB key which contained the compressed Ubuntu Core image and used the terminal in the live environment to issue the relavent 'dd' command to splat the image from USB key #2 to the hard disk.

First boot setup

Getting online

Remote access

Installing more software

Adding classic



KDE Slimbook 2 Review

KDE Slimbook 2 Review

KDE Slimbook 2  Outside

The kind folks at Slimbook recently sent me the latest generation of their ultrabook-style laptop line for review, the KDE Slimbook 2. You can hear my thoughts on the latest episode of the Ubuntu Podcast, released on June 7th 2018.

Slimbook are a small laptop vendor based in Spain. All the laptops ship with KDE Neon as the default operating system. In addition to their hardware, they also contribute to and facilitate local Free Software events in their area. I was sent the laptop only for review purposes. There's no other incentive provided, and Slimbook didn't see this blog post before I published it.

Being a small vendor, they don't have the same buying power with OEM vendors as other big name laptop suppliers. This is reflected in the price you pay. You're supporting a company who are themselves supporting Free Software developers and communities.

If you're after the cheapest possible laptop, and don't care about its origin or the people behind the device, then maybe this laptop isn't for you. However, if you like to vote with your wallet, then the KDE Slimbook should absolutely be on your list to seriously consider.


The device I was sent has the following technical specifications.

  • Core i5-7200 @ 2.5GHz CPU
  • Integrated Intel HD 620 GPU
  • 16GB DDR4 RAM
  • 500GB Samsung 960 EVO SSD
  • Intel 7265 Wireless chipset
  • Bluetooth chipset
  • 1080p Matte finish
  • Full size SD card
  • Heaphone socket and built in mic
  • 720p webcam
  • 1 x USB 3.0 (USB3.1 Gen 1) (Type A), 1 x USB 3.0 (USB3.1 Gen 1) (Type C), 1 x USB 2.0 (Type A)
  • Spanish 'chiclet' style keyboard with power button in top right
  • 3-level keyboard backlight
  • Elan Synaptics touch pad
  • 46Wh battery, TPS S10
  • Power adpater with right-angle plug
  • USB-C dongle

As shipped, mine came in at around ~1098EUR / 956GBP / 1267USD. Much of this can be tweaked, including the keyboard layout, although doing so may extend the lead time on receiving the device. There are plenty of options to tweak, and the site gives a running total as you adjust to taste. There's an i7 version, and I'm told it will soon be possible to order one with a black case, rather than the silver I was shipped. The laptop shipped with one drive, but has capacity for both an M.2 and traditional form factor drive too. So, fully loaded you could order this with 2x1TB SSDs if you're after extra disk space.

Notable is the lack of Ethernet port, which for some is a dealbreaker, even in these days of ubiquitous reliable wifi for many. The solution Slimbook went with is to provide two optional 'dongles'. One connects to USB3 Type A and presents an Ethernet port. The other option connects to the USB C port and provides 3 more USB 3 tradtional ports and an Ethernet socket. Slimbook shipped me the latter, which was super useful for connecting more USB devices, and a LAN cable.

The cable on the dongle is relatively short, but it feels solid, and I had no problems with it in infrequent daily use. One omission on the dongle is the lack of a pass-through USB C port. Once the dongle is attached to the laptop, you've used your only type-c connector. This might not be a problem if you're a luddite like me who had very few USB-C devices, but I imagine that'll be more of an issue going forward. This is an optional dongle though, and you could certainly choose not to get it, but purchase a differenty one to service your requirements.


KDE Slimbook  2 Inside

Default install - KDE Neon

The laptop shipped with KDE Neon. It's no secret to listeners of the Ubuntu Podcast that I'm a bit of a KDE fanboy since I began testing Neon a few months back, and stuck with it on my ThinkPad T450. So I am a little biased in favour of this particular Linux distribution. So I felt very much at home on the Slimbook with KDE.

On other computers I've tweaked the desktop in various ways - it's the KDE raison d'être to expose settings for everything, and I usually tweak a fair number. However on the Slimbook I wanted to try out the default experience. I found the default applications easy to use, well integrated and reliable. I'm writing this blog post in Kwrite, and have noticed features that I would have not expected here, such as the zoomed out code view and popup spelling completion.

I'm pleasantly surprised by the choices made on the software build here. KDE performs well & starts up and wakes from suspend quickly. Everything works out of the box, and the selection of applications is small, but wisely chosen. Unsurprisingly I've augmented the default apps with a few applications I use on a daily basis elsewhere, and they all fit in perfectly. I didn't feel any of the applications I use stood out as alien, or non-KDE originals. The theme and app integration is spot on. If I were a Slimbook customer, I'd happily leave the default install pretty much as-is and thoughouly enjoy the experience.

The software is delivered by the usual Ubuntu 16.04 (Xenial) archives, with the KDE Neon archive delivering updates to the KDE Plasma desktop and suite of applications. In addition two PPAs are enabled. One for TLP and another for screenfetch. Personally on a shipping laptop I'd be inclined not to enable 3rd party PPAs, but perhaps supply documentation which details how the user can enable them if required. PPAs are not stable, and can deliver unexpected updates and experiences to users.

I should also mention in the pack was a tri-fold leaflet titled "Plasma Desktop & You". It details a little about KDE, the community and invites new users to not only enjoy the software, but get involved. It's a nice touch.

Alternative options

Slimbook don't appear to offer other Linux distributions - and given the lid of the laptop has a giant KDE logo engraved on it, that wouldn't make a ton of sense anyway.

However I tested a couple of distros on it via live USB sticks. With Ubuntu 18.04 everything worked, including the USB C Ethernet dongle. For fun I also tried out Trisquel, which also appeared to mostly work including wired network via the dongle, but wifi didn't function. I didn't attempt any other distros, but given how well KDE Neon (based on Ubuntu 16.04), Ubuntu 18.04 worked, I figure any distro-hoppers would have no hardware compatibility issues.


Display & Graphics

The 1080p matte finish panel is great. I found it plenty bright and clear enough at maximum brightness. There are over 20 levels of brightness and I found myself using a balanced setting near the middle most of the time, only needing full brightness sometimes when outside. The viewing angles are fine for a single person using it, but don't lend well to having a bunch of people crouched round the laptop.

I ran a few games to see how the integrated GPU performed, and it was surprinsgly okay. My usual tests involved running Mini Metro which got 50fps, Goat Simulator at 720 got me 25fps and Talos Principle at 1080p also clocked in 25fps. This isn't a gaming laptop but if you want to play a few casual games or even run some emulators between work, it's more than up to the task.


I use a bunch of fairly chunky applications on a daily basis including common electron apps and tools. I also frequently build software locally using various compilers. The Slimbook 2 was a super effective workstation computer for these tasks. It rarely broke into a sweat, with very few occasions where the fan span up. Indeed I can't really tell you how loud the fan is because I so rarely heard it.

It boots quickly, the session starts promptly and application startup isn't a problem. Overall as a workstation, it's fine for any of the tasks I do daily.


KDE Slimbook  2 Keyboard

The keyboard is a common 'chiclet' affair, with a full row of function keys that double as media, wifi, touchpad, brightness hardware control buttons. The arrow cluster is bottom right with home/end/pgup/pgdown as secondary functions on those keys. The up/down arrows are vertically half-size to save space, which I quite like.

The "Super" (Windows) key sports a natty little Tux with the Slimbook logo beneath. Nice touch :)


The touchpad is a decent size and works with single and double touch for click/drag and scrolling. I did find the palm rejection wasn't perfect in KDE. I sometimes found myself nuking chunks of a document while typing as my fat thumbs hit the touchpad, selecting text and overtyping it.

I tried fiddling with the palm rejection options in KDE but didn't quite hit the sweet-spot. I've never been a fan of touchpads at all, and would likely just turn off the device (via Fn-F1) if this continued to annoy me, which it didn't especially.


As with most ultrabook style laptops the audio is okay, but not great. I played my usual test songs and the audio reproduction via speakers lacked volume, was a bit tinny and lacked bass.

With headphones plugged in, it was fine. I rarely use laptop speakers personally, but tend to use a pair of headphones. Nobody wants to hear what I'm listening to :). It's fine for the odd video conference though.


The model I had was supplied with a 46Wh battery, a small & lightweight ~40W charger and euro power cable & right angled barrel connector to the laptop. Under normal circumstances with medium workload I would get around 7 hours, sometimes more.

Leaving the laptop on, connected to wifi, with KDE power management switched off and brightness at 30% the system lasted around 8 hours 40 mins. I'd anticipate with a variable workload, with KDE power management switched on, you'd get similar times.

I also tried leaving the laptop playing a YouTube video at 1080p, full screen with wifi switched on and power management suppresed by the browser. The battery gave out after around 5 hours.

The battery takes around 4 hours to re-charge while the laptop is on. This is probably faster if you're not using the laptop at the time, but I didn't test that.

Overall impressions

I've been really happy using the KDE Slimbook 2. The software choices are sensible, and being based on Ubuntu 16.04 meant I could install whatever else I needed outside the KDE ecosystem. The laptop is quiet, feels well built and was a pleasure to use. I'm a little sad to give it back, because I've got used to the form-factor now.

I have only a couple of very minor niggles. The chassis case is a little sharp around the edges, much like the MacBook Air it takes design cues from. Secondly, when suspended the power LED is on the inside of the laptop, above the keyboard. So if like me, you suspend your laptop by closing the lid, you won't know if it suspended properly by looking at the slow blink of the power LED. It's a minor thing, but having been burned (literally) in the past by a laptop which unexpectedly didn't suspend, it's something I'm aware of.

Other than that, it's a cracking machine. I'd be happy to use this on a daily basis. If you're in the market for a new laptop, and want to support a Linux vendor, this device should totally be on your list. Thanks so much to Slimbook for shipping the device over and letting me have plenty of time to play with it!

New Ubuntu Community Hub Launched

A while back I proposed that we replace the old static Ubuntu Community site, which looked a bit like this, with something a little more dynamic.

The previous Ubuntu Community site

So today we are replacing the static site with an instance of discourse, which looks a bit like this

The new Ubuntu Community Hub

You can go back and read that blog post for the full rationale but essentially it boils down to two aims:

  • We want to improve community communication
  • We want to smooth the onboarding process for new contributors.

Since the blog post I have spent some time getting feedback from people in the Ubuntu community and we’ve had a bunch of great tips and suggestions to ensure the site works effectively.

The site is now live at - I’d welcome new and existing Ubuntu community members to head on over and take a look. We have opted to exclusively use Ubuntu SSO for authentication, so you won’t need to remember a new password.

A prototype site was stood-up which allowed us to shake out installation and setup issues, and build the initial categories and theme. We created a basic Ubuntu branded theme which will do for the initial site launch, but could certainly be improved upon - CSS experts welcome here!

We ported the existing content over from the static site into the documentation category. These have been converted to ‘wiki posts’ so they can continue to be easily expanded, refined and improved by future visitors. I’d welcome our active community members to re-review those periodically and help us to make them an accurate and welcoming starting point for new contributors.

We created a few “seed” posts thanks to Will Cooke from the Desktop team, and Jean Baptiste on the subject of QA.

A sample desktop post

We have a few initial categories to get things started. Desktop for discussion of the Ubuntu Desktop, where we expect there to be a lot of interest as the 17.10 release approaches, and people discover the new GNOME default desktop. The Quality topic is for co-ordination and announcements of QA activities, such as ISO testing, or where we have interesting new things landing which need wider validation.

A sample QA post

The Events topic was created for discussion of Ubuntu-related events. These could be meet-ups, UbuCons, Ubuntu Hours or any other appropriate in person or virtual advocacy activities. If you’re thinking of planning an event and want to discuss it with people who have trodden this path before, this is the place to do it. It would also be great to see posts in there after events have happened, detailing how things went, what activities were well received, and how things could be improved.

The Site Feedback section and Uncategorised sections should speak for themselves. We will of course take a view on whether more categories are required as and when particular topics break out from the existing ones. For now, the existing ones should be sufficient, but if not, let us know.

Not a technical support site

Finally, the site is very specifically not for technical support, so I’ve explained this in the Support & Help Requests category to make it clear. The site isn’t designed to be a replacement for all the other great places users can get technical help. So we’ve linked to them in the category description.

Where to get support

I’d like to thank Gustavo Neimeyer for standing up the site prototype. I’d also like to thank Nathan Haines, Simon Quigley, Marius Quabeck, Will Cooke, Martin Wimpress and Didier Roche for all their work in keeping this little project pointing in the right direction.

Head on over to, and get involved! :)

Ubuntu Community Hub Proposal

Status Quo

For over four years now, the Ubuntu Community Portal has been the 'welcome mat' for new people seeking to get involved in Ubuntu. In that time the site had seen some valuable but minor incremental changes; no major updates have occurred recently. I'd like us to fix this. We can also use this as an opportunity to improve our whole onboarding process.

I've spent a chunk of time recently chatting with active members of the Ubuntu Community about the community itself. A few themes came up in these conversations which can be summarised as:-

  • Our onboarding process for new contributors is not straightforward or easy to find
  • Contributors find it hard to see what's going on in the project
  • There is valuable documentation out there, but no launch pad to find it

To try address these concerns we have looked at each area to try improve the situation.


A prospective contributor has a limited amount of their spare time to get involved, and with a poorly documented or hard-to-find on-boarding process, they will likely give up and walk away. They won't know where to go for the 'latest news' of what's happening in this development cycle, or how they can contribute their limited time to the project most effectively and it is important that get access to the community straight away


Ubuntu has been around a long time with teams using a range of different communication tools. Despite happening in the open, the quick moving and scattered conversations lose transparency. So finding out what's 'current' is hard for new (and existing) contributors. Surfacing the gems of what's needed and the current strategic direction more obviously would help here and having a place where all contributors can discuss topics is important.


The wiki has served Ubuntu well but it suffers from many of the problems wikis have over time, namely out-of-date information, stale references, and bloat. We could undertake an effort to tidy up the wiki but today we have other tools that could serve better. Sites such as and which are much richer and easier to navigate and form the basis of our other official documentation and ways of working. Using these in conjunction with any new proposal makes much more sense.

So, what could we do to improve things?

Community Hub Proposal

I propose we replace the Community Portal with a dynamic and collaboratively maintained site. The site would raise the profile of conversations and content, to improve our onboarding and communication issues.

We could migrate existing high-value content over from the existing site to the new one, and encourage all contributors to Ubuntu, both within and outside Canonical to post to the site. We will work with teams to bring announcements and conversations to the site, to ensure content is fresh and useful.

In common with many other projects, we could use discourse for this. I don't expect this site to replace all existing tools used by the teams, but it could help to improve visibility of some.

The new Hub would contain pointers to the most relevant information for on-boarding, calls for participation (in translation, documentation, testing), event announcements, feature polls and other dynamic conversations. New & existing contributors alike should feel they can get up to date with what's going on in Ubuntu by visiting the site regularly. We should expect respectful and inclusive conversation as with any Ubuntu resource.

The Community Hub isn’t intended to replace all our other sites, but add to them. So this wouldn’t replace our existing well established Ask Ubuntu and Ubuntu Forums support sites, but would supplement them. The Community Hub could indeed link to interesting or trending content on the forums or unanswered Ask Ubuntu questions.

So ultimately the Community Hub would become a modern, welcoming environment for the community to learn about and join in with the Ubuntu project, talk directly with the people working on Ubuntu, and hopefully become contributors themselves.

Next steps

We’ll initially need to take a snapshot of the pages on the current site, and stand up an instance of discourse for the new site. We will need to migrate over the content which is most appropriate to keep, and archive anything which is no longer accurate or useful. I’d like us to have some well defined but flexible structure to the site categories. We can take inspiration from other community discourse sites, but I’d be interested in hearing feedback from the community on this.

While the site is being set-up, we’ll start planning a schedule of content, pulling from all teams in the Ubuntu project. We will reach out to Ubuntu project teams to get content lined up for the coming months. If you’re active in any team within the project, please contact me so we can talk about getting your teams work highlighted.

If you have any suggestions or want to get involved, feel free to leave a comment on this post or get in touch with me.

Ubuntu Artful Desktop July Shakedown

Ubuntu Artful Desktop July Shakedown

We’re mid-way through the Ubuntu Artful development cycle, with the 17.10 release rapidly approaching on the horizon. Now is a great time to start exercising the new GNOME goodness that’s landed on our recent daily images! Please download the ISO, test it out on your own hardware, and file bugs where appropriate.

If you’re lucky enough to find any new bugs, please tag them with ‘julyshakedown’, so we can easily find them from this testing session.

Ubuntu Artful Desktop

We recently switched the images to GDM as the login manager instead of LightDM, and GNOME Shell is now the default desktop, replacing Unity. These would be great parts of the system to exercise this early in the cycle. It’s also a good time to test out the Ubuntu on Wayland session to see how it performs in your use cases.

Get started

Suggested tests

This early in the cycle we’re not yet recommending full ISO testing, but some exploratory tests on a diverse range of set-ups would be appropriate. There’s enough new and interesting stuff in these ISOs that make it worthwhile giving everything a good exercise. Here’s some examples of things you might want to run through to get started.

Ubuntu on Wayland

  • Logging in using the ‘Ubuntu on Wayland’ session for your normal day to day activities
  • Suspend & resume and check everything still functions as expected
  • Attach to, and switch between wired and wireless networks you have nearby
  • Connect any bluetooth devices you have, especially audio devices, and make sure they work as expected
  • Plug in external displays if you have them, and ensure they work as usual

Reporting issues

The Ubuntu Desktop Team are happy to help you with these ISO images. The team are available in #ubuntu-desktop on freenode IRC. If nobody is about in your timezone, you may need to wait until the European work day to find active developers.

Bugs are tracked in Launchpad, so you’ll need an account there to get started.

If you report defects that occur only when running a wayland session please add the tag ‘wayland’ to the bug report.

Remember to use the 'julyshakedown' tag on your bugs so we can easily find them!

Known issues

There is a known issue with using Bluetooth audio devices from the greeter.  This means that people won’t be able to use screenreaders over Bluetooth at the greeter.  Once in the session this should all work as normal though.

Issues specific to wayland:

We look forward to receiving your feedback, and results!


Building Apps for Linux without Linux

It's now super easy to build Linux software packages on your Windows laptop. No VM required, no need for remote Linux hosts.

I spend a lot of my day talking to developers about their Linux software packaging woes. Many of them are using Linux desktops as their primary development platform. Some aren't, and that's their (or their employers) choice. For those developers who run Windows and want to target Linux for their applications, things just got a bit easier.

Snapcraft now runs on Windows, via Bash on Windows (a.k.a Windows Subsystem for Linux).

Snapcraft on Windows

Microsoft updated their Windows Subsystem for Linux to include Ubuntu 16.04.2 LTS as the default image. When WSL first launched a year ago, it shipped 14.04 to early adopters and developers.

Snapcraft is available in the Ubuntu 16.04 repositories, so is install-able inside WSL. So developers on Windows can easily run Snapcraft to package their software as snaps, and push to the store. No need for virtual machines, or separate remote hosts running Linux.

I made a quick video about it here. Please share it with your Windows-using developer friends :)

If you already have WSL setup with Ubuntu 14.04 the easiest way to move to 16.04.2 is to delete the install and start again. This will remove the installed packages and data in your WSL setup, so backup first. Open a command prompt window in Windows and run:-

lxrun /uninstall

To re-install, which will pull down Ubuntu 16.04.2 LTS:-

lxrun /install

Re-installing Ubuntu

Once you've got Ubuntu 16.04.2 LTS in WSL, launch it from the start menu then install snapcraft from the Ubuntu repositories with:-

sudo apt install snapcraft

Once that's done, you can either launch snapcraft within Bash on Windows, or directly from a Window command prompt shell with bash -c snapcraft. Here's a video showing me building the Linux version of storjshare using this configuration on my Windows 10 desktop from a standard command prompt window. I sped the video up because nobody wants to watch 8 minutes of shell scrolling by in realtime. Also, my desktop is quite slow. :)

You can find out more about snapcraft from our documentation, tutorials, and the videos. We also have a forum where we'd love to hear about your experience with snapcraft.

OpenSpades Snap - pew pew

OpenSpades is a super-fun "Open-Source Voxel First Person Shooter". I've been playing it for a while both on my GameOS desktop and under WINE on Linux. For whatever reason the upstream OpenSpades on github project had no Linux builds available for download, and I was lazy so I used WINE, which worked just fine.

This weekend though I decided to fix that. So I made a snap of it and pushed it to the store. If you're on a Linux distro which supports snaps you can install it with one command:-

snap install openspades

That will install the current stable release of openspades - 0.1.1c. If you'd rather test the latest github master build (as of yesterday) then use:-

snap install openspades --edge

Note: OpenSpades needs a fairly decent video card. My poor Thinkpad T450 with its integrated Intel GPU isn't up to the job, so the game switches to software rendering. However on my more beefy nVidia-powered desktop, it uses the GPU for OpenGL funky stuff.

OpenSpades on Ubuntu

I tested this build on Ubuntu 16.04, Debian 9, elementary OS Loki, Lubuntu (i386), Fedora 25 and OpenSUSE Tumbleweed. One snap(*), lots of distros. Yeah baby! :D

OpenSpades on OpenSUSE Tumbleweed

OpenSpades on Fedora 25

OpenSpades on Debian 9

(*) Technically four snaps. One per arch (32/64-bit) and one per release (stable/edge).

I proposed my changes upstream to the OpenSpades project.

I used Launchpad to build the binaries for stable and edge on both i386 and amd64 architectures, for free. Thanks Canonical!

I had to do a couple of interesting things to make OpenSpades work nicely across all these systems. I bundled in a few libraries, and wrapped the launching of the game in a script which sets up some environment variables. I just copy and pasted that part from other projects I've done in the past.

The only slightly kludgy thing I did was copy the Resources directory into a writable directory and modify the default configuration for first-launch. OpenSpades has an 'update check' feature which looks for game updates online, but it seems to me this doesn't work on Linux - probably due to there being no binary builds currently available. So rather than the user getting prompted to enable this feature, I enabled it by default, so the user just gets a notification that they're on the latest version, rather than being asked to enable a feature that won't work anyway. With snaps the user will get an update as soon as it's pushed to the store, so no need for the in-app update mechanism I think.

I also had to disable EAX (positional audio) because it crashes OpenAL on the i386 builds. Players on AMD64 systems can of course just re-enable this, as it's only the default I set, not permanently off. I might modify this default so it's only disabled on i386 builds in future.

So if you're in need of something fun to play on your Linux system. Give OpenSpades a try, and let me know if you get any problems with the snap!

Pew pew!

April Snapcraft Docs Day

Continuing Snapcraft Docs Days

In March we had our first Snapcraft Docs Day on the last Friday of the month. It was fun and successful so we're doing it again this Friday, 28th April 2017. Join us in #snapcraft on Rocket Chat and on the snapcraft forums

Flavour of the month

This month's theme is 'Flavours', specifically Ubuntu Flavours. We've worked hard to make the experience of using snapcraft to build snaps as easy as possible. Part of that work was to ensure it works as expected on all supported Ubuntu flavours. Many of us run stock Ubuntu and despite our best efforts, may not have caught certain edge cases only apparent on flavours.

If you're running an Ubuntu flavour, then we'd love to hear how we did. Do the tutorials we've written work as expected? Is the documentation clear, unambiguous and accurate? Can you successfully create a brand new snap and publish it to the store using snapcraft on your flavour of choice?

Soup of the day

On Friday we'd love to hear about your experiences on an Ubuntu flavour of doing things like:-

Happy Hour

On the subject of snapping other people's projects. Here's some tips we think you may find useful.

  • Look for new / interesting open source projects on github trending projects such as trending python projects or trending go projects, or perhaps recent show HN submissions.
  • Ask in #snapcraft on Rocket Chat if others have already started on a snap, to avoid duplication & collaborate.
  • Avoid snapping frameworks, libraries, but focus more atomic tools, utilities and full applications
  • Start small. Perhaps choose command line or server-based applications, as they're often easier for the beginner than full fat graphical desktop applications.
  • Pick applications written in languages you're familiar with. Although not compulsory, it can help when debugging
  • Contribute upstream. Once you have a prototype or fully working snap, contribute the yaml to the upstream project, so they can incorporate it in their release process
  • Consider uploading the application to the store for wider testing, but be prepared to hand the application over to the upstream developer if they request it

Finally, if you're looking for inspiration, join us in #snapcraft on Rocket Chat and ask! We've all got our own pet projects we'd like to see snapped.

Food for thought

Repeated from last time, here's a handy reference of the projects we work on with their repos and bug trackers:-

Project Source Issue Tracker
Snapd Snapd on GitHub Snapd bugs on Launchpad
Snapcraft Snapcraft on GitHub Snapcraft bugs on Launchpad
Snapcraft Docs Snappy-docs on GitHub Snappy-docs issues on GitHub
Tutorials Tutorials on GitHub Tutorials issues on GitHub