A clockwork carrot

This weekend I had the opportunity to travel to the yearly LiMux sprint to spend some time with my fellow kubuntu devs and talk about the potential issues we’re facing with the CI system and improving the Debian CI system to be more robust.

Some of the more important issues that were discussed included figuring out a way to improve file tracking in packages, so that the CI can detect file conflicts without having to actually install all the packages. Another important topic that was bought up was using the packagekit and appstream with Muon. This is apparently being held back on account of Ubuntu Touch, but is slated to be resolved soon. Once the necessary packagekit packages are updated, we can play around with the idea of perhaps shipping a muon using the packagekit backend on the next Kubuntu release.

As usual, the LiMux folks are a great bunch to hang out with, and I happened to notice something on the wall of their office while lunching with them. It was a clock. Not just a regular clock though, a timey wimey clock. I’ll let a picture do more of the talking here :


Timey Wimey clock

Timey Wimey clock


Told you. Timey Wimey.

I got quite the headache looking at the clock, but my fascination with it stuck. So once I was back home, I hacked up the regular Plasma 5 analog clock and made it timey-wimey too ;)

Timey Wimey clock

You can download and install the clock from here. Clocks and Carrots, a weekend well spent I say. As usual, you can find me and the other kubuntu devs in #kubuntu-devel on IRC or on kubuntu-devel@lists.ubuntu.com in case you want to reach out to us about Kubuntu, Clocks or Carrots.

Legalese is vague: Always consult a lawyer

Jon recently published a blog post stating that you’re free to create Ubuntu derivatives as long as you remove trademarks. I do not necessarily agree with this statement, primarily because of this clause in the IP rights policy :


The disk, CD, installer and system images, together with Ubuntu packages and binary files, are in many cases copyright of Canonical (which copyright may be distinct from the copyright in the individual components therein) and can only be used in accordance with the copyright licences therein and this IPRights Policy.

From what I understand, Canonical is asserting copyright over various binaries that are shipped on the ISO, and they’re totally in the clear to do so for any packages that end up on the ISO that are permissively licensed ( X11 for eg. ), because permissive licenses, unlike copyleft licenses, do not prohibit additional restrictions on top of the software. A reading of the GPL has the explicit statement :

4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you under
this License will not have their licenses terminated so long as such
parties remain in full compliance.

Whereas licenses such as the X11 license explicitly allow sub licensing :

… including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software …

Depending on the jurisdiction you live in, Canonical *can* claim copyrights over the binaries that are produced in the Ubuntu archive. This is something that multiple other parties such as the SF Conservancy, FSF as well as Bradley Kuhn have agreed on.

So once again, all of this is very much dependent on where you live and where your ISO’s are hosted. So if you’re distributing an Ubuntu derivative, I’d very much recommend talking to a professional lawyer who’d best be able to advise you about how the policy affects you in your jurisdiction. It may very well be that you require a license, or it may be that you don’t. I’m not a lawyer and AFAIK, neither is Jon.

Addendum/Afterthought :

Taken a bit more extreme, one could even argue that in order to be GPL compliant, derivatives should provide sources to all the packages that land on the ISO, and just passing off this responsibility to Canonical is a potential GPL violation.

An alternative to Linaro’s HWPacks

For the past couple of weeks I’ve been playing with a variety of boards, and a single problem kept raising its head over and over again, I needed to build test images quickly in order to be able to checkout whether or not these boards had the features that I wanted.

This lead me to investigating tools around building images for these boards. And the tools I came across for each of these boards were absymal to say the least. All of them were either very board specific or were not versatile enough for my needs. Linaro’s HWPack’s came very very close to what I needed, but still had some of the following limitations :

  • HWPack’s are inflexible in terms of partitioning layout, the entire partitioning layout is internal to the tool, and you could only specify one of three variations of the partition layout, and not control anything else, such as start sectors of the partitions.
  • HWPack’s are inflexible in terms of bootloader flashing, as far as I can tell, there was no way to specify the start sector, the byte size and other options that some of these boards were passing dd to flash the bootloader to the image.
  • HWPacks, as far as I could tell, could not generate config files that would be used by u-boot at boot.
  • HWPack’s only support Apt.

So with those 4 problems to solve, I set out writing my own replacement for Linaro’s HWPack’s , and lo and behold, you can find it here. ( I’m quite terrible at coming up with awesome names for my projects, so I chose the most simple and descriptive name I could think of ;)

Here’s a sample config for the ODROID C1, a neat little board from HardKernel.

The rootfs section

You can specify a rootfs for your board in this section, it will take a url to the rootfs tar and optionally a md5sum for the tar.

The firmware section

We currently have 2 firmware backends for installing the firmware ( things like the kernel, and other board specific packages ). One is the tar backend which, like the rootfs section, takes a url to the firmware tar and optionally a md5sum and the Apt backend. I only have time to maintain these 2 backends, so I’d absolutely love it if someone could write more backends such as yum or pacman and send me a pull request.

The tar backend will copy everything from the boot/* folder inside the tar onto the first partition, and anything inside the firmware/* and modules/* folder into the rootfs’s /lib folder. This is a bit implicit and I’m trying to figure out a way to make this better.

The apt backend can take multiple apt repos to be added to the rootfs and a list of packages to install afterwards.

The bootloader section

The bootloader has a :config section which will take a ERB file to be rendered and installed into both the rootfs and the bootfs ( if you have one ).

Here’s a quote of the sample ERB file for the ODROID C1:

This allows me to dynamically render boot files depending on what kernel was installed on the image and what the UUID of the rootfs is. You can in fact access more variables as described here.

Moving on to the :uboot section of the bootloader, you can specify as many stages as you want to flash onto the image. Each stage will take a :file to flash and optionally :dd_opts, which are options that you might want to pass to dd when writing the bootloader. The stages are flashed in the sequence that is declared in config.yml and the files are searched for in the rootfs first, failing which they’re searched for in the bootfs partition, if you have one.

The login section

The login section is quite self-explanatory and takes a user, a password for the user and a list of groups the user should be added to on the target image.

The login section is optional and can be skipped if your rootfs already has a pre-configured user.

At the moment I have configs for the ODROID C1, Cubox-I ( thanks to Solid Run for sending me a free-extra board! :) and the Raspberry Pi 2.

If you have questions send me an email or leave them in the comments below, and I’ll try to answer them ASAP :).

If you end up writing a config for your board, please send me a PR with the config, that’d be most awesome.

PS: Some of the most awesome people I know are meeting up at Randa next month to work on bringing Touch to KDE. It’d be supremely generous of you if you could donate towards the effort.

On featuring and writing clickbaity articles

I recently came across a very click bait’y article on the front page of Hacker News which advocated why users should use RHEL or CentOS over Ubuntu. As a Ubuntu contributor I found this article offensive and quite outright absurd. I’m not going to link the article here since that would mean just driving more clicks to the author’s website, but most of the folks who read HN regularly will know what I’m talking about.

To the author of the article :

I think you do not even begin to understand the complexities of how communities in Linux interact with each other. I have friends across Red Hat, Ubuntu, Fedora, Arch, Debian and countless other distributions that I’ve acquired during the past 5 years of working on Kubuntu and KDE. Sure, from time to time we joke about the short comings of one another’s projects, but that’s what they are, jokes. We most certainly do not intend to belittle each others work and to be honest, I am quite happy that you’re not part of this community.

To the HN community:

Why would you upvote this to the front page when it clearly deserves none of your attention? ( Thank god for the flag button )

To the awesome folks working on Ubuntu Server :

You guys are awesome and don’t let anyone tell you any different :D


Plasma5 : Now more awesome as a Kubuntu ISO

Kbuntu Next

The Kubuntu team is proud to announce the immediate availability of the Plasma 5 flavor of the Kubuntu ISO which can be found here (here’s a mirror to the torrent file in case the server is slow). Unlike it’s Neon 5 counterpart , this ISO contains packages made from the stock Plasma 5.0 release . The ISO is meant to be a technical preview of what is to come when Kubuntu switches to Plasma 5 by default in a future release of Kubuntu.

A special note of thanks to the Plasma team for making a rocking release. If you enjoy using KDE as much as we do, please consider donating to Kubuntu and KDE :)

NB: When booting the live ISO up, at the login screen, just hit the login button and you’ll be logged into a Plasma 5 session.

The KDE Randa meetings need your help

The Randa meetings provide an excellent opportunity for KDE developers to come across for a week long hack session to fix bugs in various KDE components while collaborating on new features.

This year we have some amazing things planned, with contributors working across the board on delivering an amazing KDE Frameworks 5 experience, a KDE frameworks SDK, a KDE frameworks book, the usual bug fixing and writing new features for the KDE Multimedia stack and much much more.

So please, go ahead and donate to our Randa fundraiser here , because when these contributors come together, amazing things happen :)

A shiny new release fresh out of the oven

The Kubuntu and KDE team has been hard at work for the last 6 months, which has culminated into a rocking Kubuntu 14.04 release which introduces a whole bunch of new features, the most important of which are :

  • A new semantic search framework for KDE SC 4.13, leading to faster email and file searches
  • Automatic error reporting in order to improve the quality of KDE and Kubuntu
  • A new driver manager to make it simpler to activate hardware that requires proprietary drivers
  • Notifications for when additional drivers or language packs can be installed to improve your Kubuntu experience
  • A new touchpad management app for laptops
  • Misc. bug fixes and features that can be found here

Kubuntu 14.04 is a LTS release, so while introducing new applications, we’ve also taken into account personal and business users who would want to run it for extended periods of time, which is why the Kubuntu team makes the following promise :

  • Kubuntu 14.04 will keep receiving security bug fixes when such fixes are available from KDE upstream for the next 5 years
  • New releases of the KDE SC will be backported to 14.04 and be available via Kubuntu PPA’s for the next 2 years
  • A long-term upgrade path to the next LTS release

Along with the above, the Ubuntu team also has plans to backport new Xorg and friends releases as well as new kernel releases as part of their LTS Enablement stack, making sure that your hardware performance keeps improving over the time of 5 years.

All of this makes Kubuntu the ideal distribution to use for enterprise rollouts, OEM’s and of course regular users who want a longer support cycle ( as opposed to the regular, 9 month, support cycle )

You can download your copy of Kubuntu 14.04 from here. We also have some Kubuntu swag that you can purchase over here!

New Touchpad management app in Kubuntu 14.04

Hot on the heels of the new driver manager, we have the new touchpad management app that we introduced in Kubuntu 14.04.

New Touchpad KCM

The new app replaces the old Synaptiks touchpad management app and has many more buttons and settings that you can twiddle and tweak to get the best experience. The Kubuntu team would like to thank Alexander Mezin for working on this replacement app as part of his GSoC project. The package comes complete with its own plasmoid for easy access to enable and disable touchpads! Quite useful for folks who don’t have a physical hardware button to Enable/Disable touchpads ;)

Users of Kubuntu 14.04 can grab the new touchpad management app from the Ubuntu repos by installing the kde-touchpad package.

New Driver Manager for Kubuntu

Hola Kubuntu users

Ubuntu ‘recently’ deprecated jockey and moved to ubuntu-drivers-common. ubuntu-drivers-common is a python backend which will try to figure out which drivers are best suited to your system. Up till Kubuntu 13.10 we were still relying on the backend called Jockey which is python2 , however for the 14.04 cycle, one of our major tasks was to rehaul the driver manager interface and use the fancy new ubuntu-drivers-common backend which is python3 based.

By leveraging this new backend, we are now at feature parity with Ubuntu when it comes to driver handling. Packages are now available to trusty users and can be acquired by installing the ‘kubuntu-driver-manager’ package.

Once installed you’ll find it in your System Settings Menu under “Driver Manager for Kubuntu”


If you find any bugs , please report them here

Introducing Project Neon 5 ISO’s

Everyone working on KDE Frameworks Five and Plasma Workspaces 2 is eager to bring you the next iteration of the desktop experience. However, wouldn’t it be awesome if you could play with all the shiny stuff just a bit earlier? ;)

I’ll assume you’re nodding your head right about now, so without further ado I give you Project Neon 5 ISO’s which are designed to give you a glimpse into how things are shaping up in the Frameworks 5 and Plasma Workspaces 2 world. Complete with an installer!

Neon 5 Live Env

However, I *highly* recommend NOT installing this directly onto your machine, as it’s not even meant to be a tech preview, but more of a this *will* eat kittens release. If you really want to install it, I’d recommend using KVM or VirtualBox. Out of the box you get the Neon 5 daily PPA, upgrade and things might not work, the only supported path for upgrades is reinstalling the next ISO that comes out.

If you’re interested in the nitty-gritty details of how the ISO is made, you can checkout the scripts over here.

There’s also a known bug where plasma-shell crashes on boot, we’re still investigating that and the best way to fix it is to either start plasma-shell via the xterm window or just rebooting your virtual machine a couple of times.



Get every new post delivered to your Inbox.

Join 839 other followers

%d bloggers like this: