Blue Systems, the Muon Suite, and Kubuntu

August 19, 2012

Blue Systems

Like several of my Kubuntu comrades, I too will be joining Blue Systems. I will be starting in September, working half-time as to accommodate my academic journey in college. The scope of my work includes the development the Muon Suite, its supporting libraries, and Kubuntu in general. I would like to thank Blue Systems for giving me this opportunity to focus my non-academic attention to FOSS, and Kubuntu in specific. I would also like to thank my previous employers for giving me valuable experience in the field of software engineering, albeit not in the arena of FOSS.

I would like to take this opportunity to share with the wider Kubuntu and KDE community what my plans are going forward.

My Plans

I will continue my work developing and maintaining the Muon Suite, as well as its supporting LibQApt library that facilitates interaction with the APT package system. I also plan on continuing in my role as a Kubuntu Developer, contributing to the various blueprints brainstormed at Ubuntu Developer Summits, as well as the packaging of new KDE releases and KDE software. I do have a list of some specific things I would like to accomplish, at least to start with.

LibQApt 2

LibQApt is the library used “behind the scenes” by Muon for interaction with Debian’s APT package manager. It’s main purpose is to provide an easy way for Qt applications to get information about packages, using Qt data types and providing a sane Qt-style API for interacting with packages and the package system.

Following the release of LibQApt 1.4.0 this last Thursday, LibQApt is now 2 years old! Over these past two years, LibQApt has proven to be a solid library and APT worker implementation, with defects decreasing release-by-release. It’s also proven itself to be fairly feature-complete; as a testament to that, the Muon team didn’t have to add very many new features at all during the 1.4 release cycle to accomplish progress with Muon, and there were no requests for additional API by third-parties using QApt across that time period.

That being said, LibQApt is by no means perfect. There are several flaws within QApt that come from foundational design decisions I made when I first started working on LibQApt in late 2009, two and a half years ago. At the time, LibQApt was the most ambitious and technically challenging project I had taken on, so I’ll try to excuse to 2009-me. But there are some times when I look back at the stuff I did back then and say “why on Earth would you do that, 2009-me!?”. Now that LibQApt has a robust feature set and slowed need for feature development, coupled with the approach of Qt5 and KDE Frameworks 5, I believe now is the time to break API stability to fix the structural problems within LibQApt and release LibQApt 2.0. With ABI (and in some cases API) incompatible releases of core libraries such as Qt and KDE on the horizon, the near future seems to be the prime time to introduce API changes to LibQApt itself.

The Issues

The design issues I mentioned earlier mainly have to do with LibQApt’s runtime component, the QApt Worker, and the API within LibQApt used to communicate with it. The QApt Worker is a small daemon running as root that gets invoked whenever an application using LibQApt wants to initiate a transaction with the APT package system. (Say, to install or remove a package, update the package cache, or any other task that requires administrative privileges) Communication between the worker and the QApt library happens via a D-Bus interface, where an instance of the “Backend” class in LibQApt listens for signals on the D-Bus interface. The only problems is that with the current API, any instance of QApt::Backend can receive these signals at any time. This means that any frontend application listening to LibQApt can receive events from the worker even when they’ve not entered into a state where they would be expecting them, and if they’re not careful crash trying to handle the events.

This can be rectified by having any function that initiates a worker transaction to return a D-Bus object that the worker and the client that specifically requested the transaction can use to communicate with each other, as opposed to every client instance talking over the same interface and stepping over each others’ toes. This has been bandaged up with some funky workarounds in the Muon Suite to ensure we only respond to events we expect to get, but it’s a “gotcha” that really shouldn’t exist. Changes to the DBus API should be able to rectify this.

Additionally, changes need to be made to how LibQApt communicates with the worker in regards to what changes the worker needs to make to packages. Currently, when a user hits the “apply changes” button to initiate a commit, LibQApt takes a look at changes the user has made to the internal dependency cache, and creates a dict of packages and the state that the user wishes to apply to the package. The worker will then go through this list an manually mark each package in to the proper state in its own dependency cache, before acting on the requested changes. This, as it turns out, can take a long time with large sets of packages and introduces a long waiting period when starting a commit. It also makes it so the worker cannot tell that a package being installed is being installed as the dependency of another package, so the “auto-installed” flag is set to false. When a user later removes the program, the dependencies will not be marked as auto-removable since the QApt Worker didn’t know any better and installed them with the auto-installed flag as false.

To solve this issue, in LibQApt 2 I plan on communicating transactions to the QApt Worker as lists of actions taken by the user, which the worker can apply to its own cache before running the commit. This will not only decrease the amount of time spent marking individual packages by the worker (the APT dependency cache is much faster at figuring those sorts of things out),  but will also ensure that the auto-installed flag is properly set for dependencies of manually installed packages.

There are also a few other things here and there that require ABI/API changes to fix (like renaming functions, changing return types, changing internal class layouts) that have little impact in terms of runtime quality, but will make the library easier to use by developers. A few deprecated functions, signals and slots will also be removed. Depending on how things go, I may also port LibQApt to Qt5, though I’d like to see how that all turns out and don’t want to commit to anything regarding to Qt5 just yet.

Muon Suite Plans

Of course, if API changes are made in LibQApt, Muon will have to be modified to adapt to these changes. This alone would make the next Muon release Muon 2.0. There are some nice new features that have already been committed to Git master for the next Muon Suite release, but these are more incidental and are part of the existing feature development cadence of Muon. What I guess I’m trying to say is that the Muon Suite 2.0 will *not* be a large rewrite of the project, but more of an evolution of the existing codebase adapting to changes in the software stack underneath Muon. I’d also assume that version 2.0 of Muon Suite would use KDE Frameworks 5 and Qt5. This would obviously depend on the time frame within which KF5 would materialize. But hey, maybe part of my work at Blue Systems could include helping with the Frameworks effort!

LibQApt2 or Qt5 porting aside, the current feature cadence will still be maintained within the Muon Suite. Aleix did a good write up of what we have done for 1.5 (or possibly 2.0) here. I’ve adapted the Muon Software Center to the backend changes required for the backend abstraction work that Aleix did, so you’ll be able to play around with the new KNewStuff3 backend in either the Muon Software Center or Muon Discover next feature release. The backend abstraction stuff itself is pretty exciting, and opens up a lot of possibilities for delivering all types of software in a central application.

Kubuntu Plans

It’s no secret that most of my contributions to Kubuntu today come in the form of the development of Muon. (And there’s nothing wrong with that) I still do like to contribute to Kubuntu in other forms, though, like helping the rest of the team package KDE releases, as well as implement blueprint specifications. Sponsorship by Blue Systems will help ensure that I will be able to still contribute in this way, since combining work and FOSS contributions means I will have one less thing to juggle in my life. 🙂


All in all, I am very excited about this opportunity and look forward to the coming months. Of course, nothing here is set in stone. I may come up with more things to do, and priorities may change. One thing is for certain; for me, the future is looking very blue. 😛


Muon Suite 1.4.0 Released

August 17, 2012

After five and a half months of development (yay, we’re basically on time this go around!), I’m proud to announce the release of version 1.4.0 of the Muon Suite. The Muon Suite is a set of package management utilities for Debian-based Linux distributions built on KDE technologies. Due to a data center maintenance on Canonical’s part, PPA packages for Kubuntu 12.04 will be delayed. Once the data center move is completed, the packages will be in the QApt PPA. Sorry for the inconvenience. Packages are also available in the development release of Kubuntu 12.10, codename “Quantal Quetzal”.

The 1.4 series new features all around, as well as a preview of what will be the “next big thing” in the Muon world. In the process, all applications within the Muon Suite have become more robust and bring a streamlined user experience.

I would like to also thank the KDE translation team for their awesome work this cycle. The Muon Suite is now over 70% translated in 32 different languages, (three more than last time!) making it accessible to a wide variety of users across the world. Here’s a round of applause for kde-l10n!

What’s New

Muon Discover Technology Preview

Muon Discover is the experimental new frontend in the Muon Suite. It was written by Aleix Pol Gonzalez as part of his employment at Blue Systems. You can read more about it here.The idea is to create a Muon frontend that makes finding new software super-simple, and doing so with a little bit of flair. It’s no secret that even though the existing Muon Software Center has some nifty graphical effects here and there, the interface is still somewhat “spartan”.

Muon Discover will eventually replace the Muon Software Center, but not just yet. Muon Discover is young, and its interface is written entirely in QML. KDE has not issued a set of comprehensive UI guidelines for QML usage on the desktop, and currently Muon Discover is using the Plasma QML components for several of the controls in its interface. While we wait for a set of guidelines, the classic Muon Software Center will remain the default software center application of the Muon Suite, allowing Muon Discover to mature in the process. The QML Desktop Components (slated for release sometime around Qt 5.1 or 5.2, or so I have heard rumored) and KDE Frameworks 5 will likely be a big part of KDE’s QML standardization, so expect Muon Discover to replace the Muon Software Center in around that time period.

Muon Software Center

With all the buzz around Muon Discover, you may think that nothing has been done with the Muon Software Center. Well, never fear, as there are several cool new features and user experience improvements that have been made for Muon Suite 1.4.

  • Thanks to work done by Aleix, the Muon Software Center no longer has to reset the view back to the main page when it reloads the APT cache. This provides for a much smoother experience whilst installing multiple applications.
  • A progress view has been added for displaying currently running and pending transaction.
  • All Muon frontends now use the KDE proxy, if set. (Before it only used the system proxy and APT proxy settings) Priority goes: KDE proxy, APT proxy, system proxy.
  • Additional pages of application reviews can be fetched now.
  • A busy throbber has been added to the main page to provide feedback during launch.
  • Application views can now be sorted by Name, Rating, Buzz and search relevancy.
  • By popular request, non-application packages can be toggled for application views. (Though you’re still probably better off using the Muon Package Manager for package management.)
  • Ratings are cached locally so they can be accessed in the absence of an internet connection.
  • Language and localization packages for applications are now automatically and transparently installed when the “check-language-support” utility provided by Ubuntu is installed. Systems without this utility will work as before.

Muon Package Manager

The Muon Package Manager has not been forgotten, either. Highlights for the 1.4 release mainly include tools for better handling Multi-Arch packages on 64-bit systems.

  • By default, when a package is available for both the native and foreign CPU architectures, only the native package is shown. Installed packages of any architecture are shown. This means no more duplication of most every single package in the archive polluting the Muon package view. 😛
  • A new architecture filter has been added, allowing you to filter packages by their architecture.
  • The new Debian package categories “Education” and “Introspection” have been added to Muon’s category filters.
  • A package’s archive component is now displayed in the technical details tab. (E.g. universe, main for Ubuntu packages)

Muon Update Manager

  • Technical package items in the “System Updates” category are now displayed by their package name, as the description is not always descriptive enough.
  • The version of the available update is now shown in a separate column of the update view.
  • Updates are now sorted alphabetically

QApt Utilities

The QApt Deb Installer now has a dialog where you can see what additional changes are required for the installation of a .deb file.

Additionally, the QApt Deb Installer can install multi-arch enabled foreign-arch packages (such as Skype on a 64-bit system) without issue.

The Future

I’ll do a proper overview of the future direction of the Muon Suite in a separate post fairly soon. I’d do it now, but there’s some things I can’t reveal for another few days. (How’s that for a tease? ;-)) For now, you can take a look at Aleix’s post to see a preview of some of the things happening for Muon Suite 1.5.

Geeky Stuff

There hasn’t been movement on the LibQApt front as vigorously as in previous releases, but there are still some new things that application developers might find useful. I think it’s a testament to the quality and maturity of the software. 🙂 But at any rate, here’s what’s new:


  • Add an origins() function to QApt::Backend to return a list of machine-readable origin names.
  • Added a function for retrieving a list of origins by its host URL.
  • Use a faster QString -> const char * conversion when looking up packages by name.


  • Added a method to retrieve a list of CPU architectures supported on the system as reported by APT.


Detailed changelogs for LibQApt and Muon can be found here and here, respectively.