Fedora RPM: Automatic "Provides" for CMake projects packages

If you ever did any RPM packaging (not just on Fedora) you probably noticed that some SPEC files don't use package names in BuildRequires fields but instead they refer to pkg-config module names, like this:

Name:           qt5-qtbase
Version:        5.4.1
Release:        1%{?dist}
...
BuildRequires:  pkgconfig(dbus-1)
BuildRequires:  pkgconfig(fontconfig)
BuildRequires:  pkgconfig(gl)
BuildRequires:  pkgconfig(glib-2.0)
BuildRequires:  pkgconfig(gtk+-2.0)
...

This is achieved by the respective packages simply having these aliases as their Provides (for example dbus-devel package Provides: pkgconfig(dbus-1)). The Provides are extracted automatically by an RPM script when the package is being built which gave me an idea...what if we could do the same for CMake modules?

And so I've written a simple script for RPM which extracts CMake package name and version from the package config files installed to /usr/lib/cmake. Simply put it means that kf5-kcoreaddons-devel will have

Provides:       cmake(KF5CoreAddons) = 5.8.0

and qt5-qtdeclarative-devel will have

Provides:       cmake(Qt5Qml) = 5.4.1
Provides:       cmake(Qt5Quick) = 5.4.1
Provides:       cmake(Qt5QuickTest) = 5.4.1
Provides:       cmake(Qt5QuickWidgets) = 5.4.1

...and all this happens automatically :-)

So, if you are packaging a CMake-based projects for Fedora you don't have to wonder which package provides the needed dependencies but you can just use the name from find_package() in BuildRequires and be done with it.

Name:           plasma-workspace
Version:        5.2.1
Release:        6%{?dist}
Summary:        Plasma workspace, applications and applets
...
BuildRequires:  cmake(Qt5Widgets) cmake(Qt5Quick) cmake(Qt5QuickWidgets) cmake(Qt5Concurrent) cmake(Qt5Test) cmake(Qt5Script) cmake(Qt5Network) cmake(Qt5WebKitWidgets)
BuildRequires:  cmake(Phonon4Qt5)
BuildRequires:  cmake(KF5Plasma) cmake(KF5DocTools) cmake(KF5Runner) ...
...

Another advantage is that this makes it easier to automate dependencies extraction from CMakeLists because we will no longer have to bother with mapping the CMake names to package names (for reference I have wrote a script to mass-update dependencies of all our KDE Frameworks 5 packages in Fedora).

We have pushed the script into Fedora's cmake package (currently in rawhide and (soon) in F22 but eventually I'd like to have it in F20 and F21 too) so all packages that will be rebuilt after this will get the automatic Provides.

In the long-term we would like to try to get the script to upstream RPM so that other distributions can use this too. For now the script is available in cmake package distgit.

Plasma 5.2 arrives to Fedora

It's here! Plasma 5.2 has been released just yesterday and you don't have to wait a single minute longer to update your beloved Fedora boxes :-)

I won't go into detail here about all the new awesome things that are waiting for you in Plasma 5.2, but I totally recommend that you go and read Plasma 5.2: The Quintessential Breakdown by Ken Vermette while you are waiting for your package manager to wade through the update. You can also read the official Plasma 5.2 release announcement, it has fancy animated screenshots ;).

And there's other news related to Plasma 5.2 and Fedora: Fedora rawhide has bee updated to Plasma 5.2 too. This means that KDE SIG will ship Plasma 5 in Fedora 22! Of course we will still maintain the Copr repository for our Fedora 20 and Fedora 21 users.

So, how to get Plasma 5.2 on Fedora?

On rawhide, just do dnf update. On Fedora 20 and Fedora 21, if you are already running Plasma 5.1.2 from dvratil/plasma-5 Copr, then all you need to do is to run dnf update. If you are running Plasma 5.1.95 (aka Plasma 5.2 beta) from dvratil/plasma-5-beta Copr, then it's time to switch back to stable:

dnf copr disable dvratil/plasma-5-beta
dnf copr enable dvratil/plasma-5
dnf update

If you are still running KDE 4 and you want to update to Plasma 5.2, just follow the instructions on dvratil/plasma-5 Copr page.

And if you don't feel like installing Plasma 5 on your production box right away and would like to just try it out, there's a live ISO for you. This time I did not forget to add Anaconda, so once you decide that Plasma 5 is good enough for you, you can just install it right from the ISO ;-)

EDIT: I might have included Anaconda, but did not add grub2 to the ISO, so the installer would fail anyway. This has been fixed and updated images are available now on the same link. If you are planning to install from the live ISO, please download the updated images (29-Jan-2015 00:42)

 

Oh, and if anyone is around in Brno next week for DevConf, let us know and we can informally meet for ceremonious consumption of beer to celebrate the Plasma release ;)

Plasma 5.2 Beta available for Fedora testers

On Tuesday KDE has released first beta of the upcoming Plasma 5.2. Plasma 5.2 is adding many new features and improvements and we would welcome testers to help find and fix bugs before the final release.

Fedora 21 with Plasma 5.2 beta Fedora users are welcome to try out Plasma 5.2 beta, either by running Fedora Plasma 5.2 beta live ISO, or by installing packages from plasma-5-beta Copr (see Installation Instructions on the Copr page)

Check out the release announcement to see what new features and improvements are waiting for you in Plasma 5.2. Final release will be in two weeks on January 27, after that we will update the plasma-5 Copr to get the update to all our users :-)

KDE Frameworks 5.3 and KDE Plasma 5.1 for Fedora are ready!

Fedora KDE SIG is happy to announce that latest version of KDE Frameworks 5 have just reached stable repositories of Fedora and  brand new version of KDE Plasma 5 is now available in the our Plasma 5 COPR.

KDE Frameworks 5.3.0

The third release of KDE Frameworks brings mostly bugfixes. KDE Frameworks 5 is a collection of libraries and software frameworks created by the KDE community. It's an effort to rework KDE 4 libraries into a set of individual and independent, cross platform modules that will be readily available to all Qt-based applications.

KDE Frameworks 5 are available in official Fedora repositories for Fedora 20 and the upcoming Fedora 21.

KDE Plasma 5.1

Fedora 20 running KDE Plasma 5KDE Plasma 5 is the next generation of KDE workspace based on Qt 5 and KDE Frameworks. It's latest version brings many bug fixes, performance improvements but also many new features! Dark color theme for the Breeze style, more widgets, improved Task switcher, reworked tray icons and much more. You can read about all the new things in Plasma 5.1 in the official release announcement.

To install KDE Plasma 5 on Fedora, just add the Plasma 5 COPR repository to yum, and simply run yum install plasma-5.

Live ISO

Do you want to give Plasma 5 a try, but don't want to install it yet? Easy! We have prepared a live ISO image based on Fedora 20 for you! You can get it from here: http://pub.dvratil.cz/plasma/iso/5.1/ (use Torrent for faster download).

Do you need help? Come talk to us: either on #fedora-kde IRC channel on Freenode, or join our mailing list kde@lists.fedoraproject.org.

Fedora 20 running KDE Plasma 5

I'm going to Akademy 2014 in Brno!

What am I going to do there? I will give a short talk on Saturday at 11:35 about what we have achieved in Akonadi in the past year and I'll be attending the KDE PIM BoF on Tuesday morning - you are all invited of course to join us in discussions about the future of KDE PIM! Possibly I'll also go to KTp BoF (purely for nostalgic reasons) and Solid BoF (did someone mention KScreen?).

I tried to list some talks I want to attend, but as I was browsing the program I realized I want to attend all of them. Seriously! So many interesting talks and so many things to learn this year! Any progress on the self-duplicating technology, so I could attend two talks at the same time? :-)

I'm really excited about this year Akademy. For us in Brno the Akademy has already begun in a sense with all the planing and preparations, but the real Akademy starts when everyone is here. I'm really looking forward to meet with all my friends from KDE again!

By the way, if you arrive on Friday (or earlier), stop by at the brand new Red Hat office for the pre-registration event. Food, drinks and fun are guaranteed!

I'm going to Akademy 2014

See you all in couple days! *hug*

Hacking my way through Randa

Hello! This is me, reporting from Randa KDE meetings!

I decided to go to Randa to work with the KDE Mutlimedia team on getting Date in the Digital Clock appletPhonon GStreamer 1.0 port out and to discuss future directions of Phonon. As you could figure out from Harald's blog, my mission was successful (mostly). All the original porting work was done by Rohan Garg, Torrie Fisher and Harald Sitter, so big thanks to them! Here in Randa I was mostly fixing existing Phonon GStreamer bugs and polishing the 1.0 port to make it ready for release (had to undust my glib skills :P). An just three days ago, we pushed out first public beta. That night we also fixed a bug that made videos in Gwenview have a blue tint, but the fix is not in the beta release.

Even though it was not part of the plans for Randa, I spend all Wednesday trying to fix some issues in Plasma 5 that were too annoying for me to just continue ignoring them - so in Plasma 5.0.2 the labels in Kickoff will finally be properly centered and in Plasma 5.1 the date will return to the Digital Clock applet. I also submitted patches to add keyboard layout changer and CapsLock-on warning to the new screen locker.

Screenlocker with keyboard layout switcher and caps lock warningI tried to avoid working on KDE PIM here, but got bribed by chocolate into fixing a specific bug related to contacts and events tags, which I started working on, but haven't finished yet.

And now it's time to leave. If it was up to me, I could just stay in this beautiful place all year... :-)

Many thanks to Mario and the team for organizing the Randa meetings, many thanks to sponsors who made this possible financially and finally huge round of applause to the kitchen team for preparing such delicious meals :-)

See you all in Brno in couple weeks!

I'm going to Akademy!

No Gmail integration in 4.14 after all :(

Hi folks,

I'm sorry to bring bad news, but after trying to fight some last minute bugs in the new Gmail resource today, I realized that pushing the resource into KDE Applications 4.14 was too hurried, and so I decided not to ship it in KDE Applications 4.14. I know many of you are really excited about the Gmail integration, but there are far too many issues that cannot be solved this late in 4.14 cycle. And since this will probably be the last 4.x release, shipping something that does not perform as expected and cannot be fixed properly would only be disappointing and discouraging to users. In my original post I explained that I was working on the Gmail integration to provide user experience as close as possible to native Gmail web interface so that people are not tempted to switch away from KMail to Gmail. But with the current state of the resource, the effect would be exactly the opposite. And if the resource cannot fulfil it's purpose, then there's no point in offering it to users.

Instead I will focus on implementing the new native Gmail API and merging together the existing Google resources to create a single groupware solution that will provide integration will all Google's PIM services - contacts, calendars, tasks and emails.

 

Improved Gmail integration in KDE PIM 4.14

Update: no Gmail integration after all, feel free to contact me if you want to help

Hi all,

I already teased publicly about the new Gmail resource on Google+ yesterday, now it's time for some more explanations and...screenshots!

What is this about?

A native Gmail Resource for Akonadi that will bring much better integration of Gmail features into Kmail.

I've been talking about it and promising it for quite some time. But now thanks to some changes to the regular IMAP Resource that Christian Mollekopf has done recently, I could finally start working on it!

But...why?

Those who use Gmail know that Gmail does some things differently than most normal mail services. The biggest difference is that there are not really any folders with emails. Instead there's one folder with all your emails and then there are labels, that you can assign to emails and then you can just filter your emails by the labels. And you can assign multiple labels to one email.

Yeah, but why bother? It already works quite well with the normal IMAP resource, right?

Yes, Gmail is able to hide this specialities from regular email clients so that they can still work with Gmail like with any other generic mail server, but at the cost of losing some features.

More and more often you can hear today that desktop email clients are dead and the future is in webmail (and cloud). And for many users who only have one email account this is true - why having KMail and KOrganizer etc. running, when they can have all this and more opened constantly in a single tab in their web browser? And the truth is, that Gmail is simply the largest mail provider in the world today. So if we want to persuade all these users to keep using KMail, we need to provide a user experience that is as close as possible to the native web interface. And for that we need a native Akonadi Resource ;-)

(Note: I'd like to avoid flamewars about "desktop clients are not dead vs. are dead" - I believe they are not dead for people who use more than one email account. They will cling to desktop clients until the dawn of the Gods, and even longer, but for normal users with just one mail account, it might be just matter of years to leave desktop clients. But who knows. impossible to see the future is).

Ok, so what's the difference between Gmail and IMAP Resources?

The Gmail Resource supports some Gmail-specific IMAP extensions. In other words, it can speak and understands Gmail's IMAP dialect. This means that the Gmail resource can handle the Gmail specifics better than the generic IMAP Resource:

1) Flattened folder hierarchy. This is best shown on screenshots: on the left, there's a folder hierarchy as shown in KMail when using the current IMAP resource, on the right there's the same account but synced via the new Gmail resource.

Folder hierarchy synced via the IMAP resource
Folder hierarchy synced via native Gmail Resource

2) One email to rule them all! As explained above, one email on Gmail can have multiple labels. But when you sync the mail via normal IMAP, you get a copy of that email in each folder. That means, that marking the mail as read will only mark as read that copy, but not the other copies in other folders, simply because KMail does not know they are effectively the same mail.

The Gmail resource is aware of this, an it syncs all your emails into one hidden folder and then just links them to the actual folders representing Gmail labels that you can see in KMail, so when you mark an email as read in any folder, it will mark it as read in all folders it's linked into. Awesome, right?

3) OAuth authentication. The regular IMAP resource only supports the regular username-password authentication (and GSSAPI), which means that your password is stored in the computer somewhere, and if you use 2-step verification, you need to generate an app-specific password.

The Gmail resource has support for Gmail's OAuth2, so you only enter your password once into Google's web login, and the resource will then use a special tokens issued by Gmail with limited life-span to authenticate all your requests.

Gmail Resource authenticationGmail Resource: 2-step authentization support

The authentication is actually powered by LibKGAPI, a Qt/KDE library that implements various Google APIs, so it has the same look and uses the same code as the Akonadi Resources for Google Calendars and Google Contacts.

(Funny story and a question: I actually had to write a custom plugin for Cyrus-SASL to support XOAUTH2 mechanism, as upstream does not support it. Does anyone know whether there's an existing implementation somewhere on the interwebs that I could use instead my crappy plugin?)

4) Simpler configuration. This is not really that big, bacause you don't open the dialog very often, but I really like the configuration dialog a lot: simple and without complex options like encryption, mechanisms... This is simply because Gmail supports only a specific set of IMAP features, so I could just remove lot's of stuff from the configuration dialog making it thinner and much easier to understand (IMO).

Gmail Resource configuration dialog

5) Push-notifications for all folders. The IMAP Resource can only monitor one folder for changes (using IMAP IDLE), because of certain technical restrictions. The folder usually is the Inbox. So if you have server-side filtering, you will never get push-notifications about new emails arriving to your other folders.

The limitation for watching only one folder applies to the Gmail Resource too. However since we understand Gmail, we can watch the "All Mail" folder, instead of the Inbox, so this way we get push notifications about emails from absolutely all folders (except for Trash and Junk folders, but who cares about these). Thinking about it, I could even remove the "Check Interval" option from configuration now.

Uhm ok, so what's the state of the resource?

Currently the resource is still in a branch, waiting for some more features to be finished and for Christian to approve some of my changes to the IMAP resource (I'll bribe him with some beer during Akademy, if necessary ;-)), and some changes must be done in KMail to properly support copying and moving of the linked emails, but other than that, it already works quite nicely :-)

That's about it, see you next time :-)

KDE Frameworks 5 Beta and Plasma Next preview on Fedora!

The Fedora KDE SIG brings you all the new and cool stuff from KDE Frameworks and Plasma Next worlds!

First, our Copr repository with KDE Frameworks has been updated to 4.99.0 release, so go get it! All frameworks are co-installable with KDE 4, so you can develop against KF5 without needing any special setup. Also KDE Frameworks 5 were approved as feature for Fedora 21, which means that in next Fedora release, we will ship all Frameworks in the Fedora repositories! There are already some packages imported into rawhide, the rest will follow in next weeks.

And now for the awesome news: we have a live ISO with Plasma Next preview!

Fedora Plasma Next Live ISO Login screen

We packaged as much as we could (but still not everything!), including Rekonq, Dolphin, System Settings, Baloo, Milou and more - all built against Qt 5 and KDE Frameworks 5 of course.

Download Fedora Plasma Next Live ISO or get it via torrent.

Fedora Plasma Fedora Plasma

If you are really interested in trying locally, you can check out all the additional packages from kde-frameworks-unstable and plasma-next COPRs, but remember that all packages from those repositories install to /usr, so you will get conflicts with KDE 4 packages.

KDE Frameworks 5 and Plasma 2 on Fedora

Fedora logoFirst technological preview of KDE Frameworks 5 has been released few weeks ago, a clear signal for us in Fedora KDE SIG to roll up our sleeves, heat up the builders and start packaging. For the last few days Martin Bříza, Jan Grulich, Lukáš Tinkl, Siddhart Sharma and I were working on bringing KDE Frameworks and Plasma 2 to Fedora. Now we are done and you can try out current technological preview of KF5 and Plasma 2 directly on your system without having to compile anything or messing up your default profile.

If you are a KDE developer, a Qt developer interested in using KF5 in your application or just a curious user, all you have to do is adding kde-frameworks repo to yum and install the packages! The repository is available in Copr, just download the repo file to /etc/yum.repos.d and you can start using Frameworks and Plasma 2. All Frameworks packages are prefixed with kf5- to prevent conflicts with regular packages and at this point they are installed into /opt/kf5 prefix instead of /usr

If you install kde5-workspace package, you can also have a sneak peek at what Plasma guys are doing for Plasma 2! Your display manager should have "KDE Plasma Workspace 2" entry in session types list, which will log you into Plasma 2 session. Just remember that Plasma 2 is still under heavy development and not yet ready for day to day use.

We will now start making the KDE Frameworks 5 packages co-installable with KDE 4 into regular prefix and hopefully we will ship KDE Frameworks 5 as a feature in Fedora 21 available to everyone.

Btw if you are coming to Brno for DevConf (February 7th - 9th) and want to know more about KDE Frameworks and Plasma 2, make sure to visit "KDE Frameworks 5" talk by me and Siddhart Sharma ;-)