Blogilo test blog entry

In review D17947, it was claimed that Blogilo can no longer post to WordPress. I am creating this blog entry to verify whether it still works or not.

Kannolo, a pure-KDE Fedora Remix

It has been a long time since my last blog post, but that does not mean I stopped doing Fedora-related development. Today, I would like to announce a new project of mine that I had been silently working on for a couple years already. In several cultures, it is customary to make gifts today (in the evening) or tomorrow, so you can take this as a gift for the holidays.

Kannolo is an installable graphical Fedora Remix without GTK+, based on the KDE Plasma Desktop workspace and the Calamares installer. About the name: A “torta fedora” is a Sicilian cake. A “cannolo” is a similar Sicilian sweet with a different shape. The ‘K’ stands for “KDE”.

There is currently a version based on the upstream release 25, and a version based on the upstream release 24, both with all updates up to 2016-12-23. (This is now the third ISO release of Kannolo. The first release was on 2016-12-15.) Only x86_64 images are available at this time.

A distinguishing feature of Kannolo is that it is a hybrid live and netinstall image, powered by the Calamares netinstall module, which offers a selection of recommended (selected by default) and featured optional packages (including developer-oriented packages) to install from the Internet during the installation process.

You can find more information and screenshots at https://sourceforge.net/projects/kannolo/. Further information can be found in the release notes.

You can find these (and eventually future) releases in the Files section. Future release announcements will be posted in the News section.

Enjoy!

New version of Oxygen (colored) Plasma system tray icons

If you’re fed up of staring at a boring, low-contrast all-gray system tray with icons inconsistent with the rest of your system, it’s time to bring some color into your life, or at least your system tray. 😉 In other words, my Oxygen Plasma (≥ 4.5) system tray icons are for you. Please note that credit for the actual artwork goes to the Oxygen icon theme team, I only did the required format conversions. (On the other hand, if things look ugly, it’s probably my fault. ;))

Today, I have updated the package to include a colored version of kpackagekit.svgz, which contains 3 icons (plus a currently unused fourth one) used by Apper. The icons are again converted from the Oxygen icon theme. So if you were using revision 1 of my theme on Fedora 16 and the gray Apper icon was sticking out like a sore thumb, the updated revision 2 is for you!

Plasma PackageKit integration approved as a Fedora 17 feature

I am proud to announce that my Plasma PackageKit Integration GSoC 2011 project has been approved as an official Fedora 17 feature.

In other news, I have recently laid the first stone for a port of my work to KDE Frameworks 5, by getting support for a plasma5 namespace into PackageKit.

GSoC is over, but my code lives

The GSoC deadline is now over. I passed the final evaluation and got my payment, still waiting for the t-shirt and certificate though. But the fact that the deadline has passed doesn’t mean I stopped maintaining the code. This week, the telepathy-kde-presence-applet has landed in Rawhide, which made me find and fix a few issues in my GSoC work:

1. The RPM auto-Provides script got confused by plasma-scriptengine-applet-declarative.desktop in kde-runtime, which has a X-KDE-PluginInfo-Name different from the X-Plasma-API (the name is qmlscript, the API is declarativeappletscript). The dependency extractor was preferring the X-KDE-PluginInfo-Name, but that name is not used for script engines, only the API is relevant. This is fixed by this kde-settings commit, in kde-settings-4.7-8.fc17.
2. The data engine dependency extraction did not support declarativeappletscript QML code. I updated the patch to add support for that feature.
3. The plasma-dataengine-depextractor was passing a relative path to KDesktopFile, which misinterpreted it as relative to applnk rather than to the current directory. I fixed the patch to use QDir::absoluteFilePath instead of QDir::filePath.
4. The plasma-dataengine-depextractor was requiring the user or script calling it to explicitly pass the scripting API/language used through an --api argument. That information is already provided by the .desktop file, which is required anyway, so I dropped the useless parameter and changed the code to detect the scripting API automatically. (If anybody is already using the plasma-dataengine-depextractor: please just remove any -a language or --api language argument you’re passing, it is now all detected automatically.)

Unfortunately, I haven’t been able to build the updated data engine dependency extraction patch into Rawhide yet because the kdelibs build fails due to an unrelated issue with isnan.

UPDATE: glibc has been fixed in Rawhide, and kdelibs-4.7.1-4.fc17 was built successfully.

Plasma/RPM/PackageKit GSoC work now in Rawhide

My GSoC 2011 work has now fully entered Rawhide, i.e. what will eventually become Fedora 17 and later.

The PackageKit portions of the work have already been in Rawhide for a while:

• PackageKit-0.6.16-1.fc16 (patch included upstream) was built on July 4.
• gnome-packagekit-3.1.3-2.fc16 (patch included upstream) was built on July 4 as well.
• kpackagekit-0.6.3.3-3.fc17 (patch backported) was built (by me) on August 1.

I have just imported the remaining portions of the work into Rawhide:

• kde-settings-4.7-4.fc17 includes the RPM dependency generators.
• I have rebuilt kdelibs, kdebase-runtime, kdebase-workspace and kdeplasma-addons to pick up the new Provides. Other packages will automatically pick up Provides and script engine Requires the next time they are rebuilt. (For data engine Requires, you will want to run the new plasma-dataengine-depextractor in kdelibs-devel during the build process, unless/until the upstream metadata.desktop includes an X-Plasma-RequiredDataEngines entry.)
• kdelibs-4.7.0-3.fc17 includes all the libplasma portions of my GSoC project (as backported patches).

The new features should now be fully testable in Rawhide.

Update: I built kde-settings-4.7-5.fc17, which fixes showstopper bug #732271. (I also fixed a related issue in libplasma in kdelibs-4.7.0-4.fc17, but that fix should not be strictly required because the only thing I use Plasma::PackageMetadata::serviceType() for is to figure out the precise type of script engine to verify the presence of, and if I don’t have a service type, I just conservatively look for any script engine for the language, which should be fine as they tend to be packaged together anyway.)

Plasma + PackageKit: The last piece of the puzzle

I have just submitted a patch which implement automatic scanning of the source code of Plasma-related packages (e.g. widgets) for required data engines.

For packages in scripting languages and distributed through Open Collaboration Services (OCS), this is fully automatic and triggered from Package::installPackage. If an X-Plasma-RequiredDataEngines entry is present in the .desktop file (even if empty), the dependency extraction is not run and the explicitly provided information is trusted instead.

For native distribution packages, my patch adds a tool called plasma-dataengine-depextractor which can be run at any time during the build process and which adds the dependency information (the X-Plasma-RequiredDataEngines entry) to the relevant .desktop file.

Authors of plasmoids are encouraged to run plasma-dataengine-depextractor and/or fill in X-Plasma-RequiredDataEngines manually. (Please note that the list is expected to be comma-separated.)

Of course, the automatic scanning is not perfect; in particular, it will not detect convoluted ways to load data engines (e.g. if the name is a variable), and it may have false positives in some corner cases (commented-out use of a data engine, some other function called dataEngine and taking a string literal). However, I expect it to work well in practice, and if it doesn’t work, there’s always the possibility to explicitly add the X-Plasma-RequiredDataEngines entry.

This is the final portion of my GSoC 2011 project, so the project can now be considered 100% complete.

It works: Plasma now looks up missing components through PackageKit!

Sorry, I haven’t blogged for a while, but rest assured that I’m still alive and coding. 🙂 I passed the midterm evaluation, and the final evaluation is approaching. So what do we have in the store?

• My patches to PackageKit, Apper and gnome-packagekit got pushed upstream. The changes to the PackageKit core even trickled down all the way to Fedora 15 (and of course Fedora 16 and Rawhide). I have backported the Apper changes to the Rawhide kpackagekit package.
• I added support for Plasma to automatically prompt for the installation of missing script and data engines the first time something attempts to use them. This patch got pushed upstream.
• I submitted another patch for review, which makes Plasma request the installation of required script engines (always, as this is covered by existing metadata) and data engines (if specified in the metadata through a new X-Plasma-RequiredDataEngines entry) as soon as a package (usually a widget) is installed through Open Collaboration Services (OCS), rather than only when the user attempts to add the widget to some containment (desktop, panel etc.). This patch is pending upstream feedback.
• I also wrote an RPM auto-Requires script based on the same metadata as the above patch. This ensures script and data engine dependencies will be automatically detected in future Fedora packages.

Now the only remaining work item on my project plan is automatic scanning for required data engines. (Script engines are already completely handled by the above patches.)

Small API change to the PackageKit support for Plasma service lookup

Richard Hughes requested a small change to the PackageKit session API used to look up Plasma services before accepting the added function upstream: instead of a dedicated InstallPlasmaResources method, the org.freedesktop.PackageKit.Modify D-Bus interface got a generic InstallResources method, which allows installing all the existing resource types as well as Plasma services, and any other resource types added in the future. It takes a type parameter, which must be set to "plasma-service" in our case.

With those tweaks, the PackageKit change and the gnome-packagekit change are now committed to upstream git. For Apper (KPackageKit), which is our main target, there is a patch for Apper master on Review Board and a backport for KPackageKit 0.6.x on the packagekit mailing list. Hopefully, Daniel Nicoletti will have some time to review the patch soon. If not, he suggested on IRC that I can just commit the patch as is and he’ll refactor it later if needed, so that’s my fallback plan.

PackageKit support for Plasma service lookup

I just submitted patches to the packagekit mailing list which implement a new InstallPlasmaResources method in the org.freedesktop.PackageKit.Modify D-Bus interface. There are patches for PackageKit itself, as well as for Apper (both master and KPackageKit 0.6.x) and gnome-packagekit. See my post to the packagekit mailing list for more details.

This completes the next step in my GSoC 2011 project. Now I can start working on using the new interface in Plasma.