Muon Suite 2.1 alpha released

June 27, 2013

I am proud to announce the first alpha release for Muon Suite 2.14. The Muon Suite is a set of package management utilities for Debian-based Linux distributions built on KDE technologies. Packages for Kubuntu 13.10 “Raring Ringtail” are available in the QApt Experimental PPA. Here’s what’s new:

Muon Update Manager

New Updater UI

Thanks to the excellent work of my colleagues Aurélien Gâteau and Aleix Pol, the user interface for the Muon Update Manager has been streamlined to make it easier to use.

Additionally, resources provided by the new KNewStuff and Bodega resource backends in Muon Discover and the Muon Software Center can now be updated through the Muon Update Manager.

 

Muon Discover

Additionally, further work has been put into refining the Muon Discover frontend.

Upcoming Features

There are several features currently targeted for Muon Suite 2.1 that have not yet landed as of 2.0.65. These features include backends for both the Ubuntu software store (this includes Steam), as well as a PackageKit resource backend.

Changelogs

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


Muon Suite 1.9.95 (2.0 RC) released

March 10, 2013

I am proud to announce the first alpha release for Muon Suite 2.0. The Muon Suite is a set of package management utilities for Debian-based Linux distributions built on KDE technologies. Packages for Kubuntu 12.10 “Quantal Quetzal” are available in the QApt Experimental PPA. Additionally, packages are available in the development release of Kubuntu 13.04, “Raring Ringtail”.

Most of the big stuff for 2.0 was announced in my previous post. This release mostly features bugfixes over the previous 1.9.80 (2.0 beta) release.

Changelogs

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


Muon Suite 1.9.65 (Alpha 2)

December 11, 2012

I am proud to announce the first alpha release for Muon Suite 2.0. The Muon Suite is a set of package management utilities for Debian-based Linux distributions built on KDE technologies. Packages for Kubuntu 12.10 “Quantal Quetzal” are available in the QApt Experimental PPA.

Most of the big stuff for 2.0 was announced in my previous post. Some bug fixes have been applied, as well as some more boring behind-the-scenes restructuring of code. That’s why this is still an alpha release instead of a beta release. We have a few more features we’d like to get in, and then do a beta release. (I’ve been busy studying for final exams this past week, which is why the release is a bit late…)

Changelogs

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


Muon Suite 2.0 alpha released

November 1, 2012

I meant to get this out by Monday, but the hurricane sort of put a damper on that… Here it is now, though.

I am proud to announce the first alpha release for Muon Suite 2.0. The Muon Suite is a set of package management utilities for Debian-based Linux distributions built on KDE technologies. Packages for Kubuntu 12.10 “Quantal Quetzal” are available in the QApt Experimental PPA.

2.0? A rewrite?

Nope! I had to make changes to LibQApt that would prevent programs compiled against LibQApt 1.x from being able to run or compile against LibQApt 2.x. Muon Suite 2.0 simply means that it uses LibQApt 2.0. (In developer speak, this release breaks both ABI and API. It’s mostly source-compatible, but will require a few changes/additions in programs using LibQApt) I’ll write a separate post about LibQApt2 explaining the changes in detail. Most of my efforts this cycle have been towards LibQApt2, but this doesn’t mean that there’s nothing new on the Muon front. ;-)

KNewStuff3 support

Both the Muon Software Center and Muon Discover now support installing things via KDE’s KNewStuff framework version 3. This is the framework that allows developers to publish scripted plugins such as Plasma widgets to the world. Currently the Muon Software Center and Muon Discover have categories for Plasma widgets (as well as plugins for the Comics plasmoid) utilizing KNS3. Suggestions for further categories using KNS3 are welcome.

 

 

Aleix wrote about this feature in detail at his blog. As he wrote, the work in supporting multiple resource types opens up the possibility of new backends. (Perhaps a backend that grabs data from AppStream in the future) Exciting stuff.

Changelogs

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


Muon Suite 1.4.1 released

September 30, 2012

I am glad to announce the first bugfix release for Muon Suite 1.4. The Muon Suite is a set of package management utilities for Debian-based Linux distributions built on KDE technologies. Sorry that this is a bit late. I meant to do this two weeks ago, but my MBR died that weekend. That got fixed, but I’ve not had a chance to do this release until now…

The 1.4.1 release fixes several issues with the experimental Muon Discover frontend. Additionally, a bug where the Muon Notifier would hang KDED for 25 seconds when checking for new versions of Kubuntu was fixed. (Only affected people behind system-wide proxies)

Packages for Kubuntu 12.04 are from the QApt repository, and in the main repositories for Kubuntu 12.10.

Further technical information about the release, including source tarball downloads and a detailed changelog, can be found at the project pages here and here.

Exciting things are happening in Git, so stay tuned for some blogs on that in the near future! (Maybe in two weeks or so?)


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. :)

Conclusion

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. :P


Follow

Get every new post delivered to your Inbox.

Join 25 other followers