15:04:40 <rdieter> #startmeeting kde-sig
15:04:40 <zodbot> Meeting started Tue Sep 16 15:04:40 2014 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:04:40 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:04:47 <rdieter> #meetingname kde-sig
15:04:47 <zodbot> The meeting name has been set to 'kde-sig'
15:04:53 <rdieter> #topic roll call
15:05:01 <Kevin_Kofler> Present.
15:05:04 <rdieter> hi everyone, kde-sig meeting about to start, who's present today?
15:05:43 <than_> present
15:05:44 <tosky> hi
15:06:58 <rdieter> #info rdieter Kevin_Kofler than_ tosky present
15:07:03 <rdieter> #chair Kevin_Kofler  than_ tosky
15:07:03 <zodbot> Current chairs: Kevin_Kofler rdieter than_ tosky
15:07:46 <jgrulich> hi
15:07:47 <pino|work> o/
15:08:15 <Kevin_Kofler> #chair jgrulich pino|work
15:08:15 <dvratil_> hi
15:08:15 <zodbot> Current chairs: Kevin_Kofler jgrulich pino|work rdieter than_ tosky
15:08:17 * danofsatx is here
15:08:30 <Kevin_Kofler> #chair dvratil_ danofsatx
15:08:30 <zodbot> Current chairs: Kevin_Kofler danofsatx dvratil_ jgrulich pino|work rdieter than_ tosky
15:08:32 <rdieter> #info jgrulich pino|work dvratil_ danofsatx present
15:08:36 <danofsatx> sorry, troubleshooting two issues...
15:08:40 <rdieter> I think we got everyone
15:08:42 <rdieter> #topic agenda
15:08:46 <rdieter> what to discuss today?
15:08:52 <mbriza> hey
15:09:02 <rdieter> #info mbriza present
15:09:16 * rdieter can give kde-4.14.1 status update
15:09:19 <Kevin_Kofler> I looked a bit into the PackageKit-hif stuff.
15:09:31 <dvratil_> KF5-5.2.0, Plasma-5.0.2 status update
15:09:32 <Kevin_Kofler> I can summarize my findings.
15:09:39 <rdieter> ok, PK would be a nice topic, yes
15:09:51 <Kevin_Kofler> Can we start with that?
15:09:54 <rdieter> yes
15:10:29 <rdieter> let's jump in then
15:10:45 <rdieter> #topic PackageKit-hif status
15:10:48 <rdieter> Kevin_Kofler: go ahead
15:12:39 <Kevin_Kofler> So I looked at what functions are not yet implemented in PackageKit-hif. There are 4 sets (functions or pairs of functions) missing:
15:12:45 <Kevin_Kofler> 1. GPG key autoimport: pk_backend_install_signature
15:12:47 <Kevin_Kofler> 2. Dependency querying: pk_backend_depends_on, pk_backend_required_by
15:12:48 <Kevin_Kofler> 3. Category (comps group) support: pk_backend_get_categories, pk_backend_search_groups
15:12:50 <Kevin_Kofler> 4. FedUp upgrades: pk_backend_get_distro_upgrades
15:12:52 <Kevin_Kofler> The biggest problem for Apper is 3.
15:13:06 <Kevin_Kofler> 2. means less information in Apper's package details.
15:13:25 <rdieter> sheesh, its worse than I thought
15:13:32 <pino|work> what's this "hif"?
15:13:33 <Kevin_Kofler> 1. just sucks for everyone, we got that implemented fairly recently in the yum backend, and now it's missing again, it looks like this is really not a priority for hughsie.
15:13:43 <Kevin_Kofler> pino|work: The layer between PackageKit and hawkey.
15:13:50 <rdieter> pino|work: the new PackageKit backend feature for Fedora 21
15:13:52 <pino|work> another one?
15:13:55 <Kevin_Kofler> (almost KDE-style design ;-) )
15:14:07 <Kevin_Kofler> It replaces the yum backend.
15:14:27 <Kevin_Kofler> It goes along with dnf, using the same hawkey library dnf also uses.
15:14:33 <rdieter> I think it's time to raise visibility for this blocker bug (to fesco and friends)
15:14:42 <pino|work> why not use hawkey directly?
15:14:42 <Kevin_Kofler> (and librepo, and if we implement 3., probably also libcomps – dnf also uses those)
15:15:28 <Kevin_Kofler> pino|work: Because it's too low-level, so wrapper functions are needed, and there's at least one project (rpm-ostree) that wanted to use the functions from PackageKit-hawkey, so now it's a library.
15:15:56 <pino|work> m(
15:16:13 <Kevin_Kofler> Unfortunately, dnf does all that high-level stuff in Python, so it's not going into hawkey itself.
15:17:09 <Kevin_Kofler> But to complete my listing, 4. is nice-to-have, IMHO not a high priority.
15:17:16 <rdieter> Kevin_Kofler: when you get a chance, can you document those 4 missing items in bugzilla?
15:17:22 <Kevin_Kofler> It'll only matter once F22 is out anyway.
15:17:39 <Kevin_Kofler> Where? In the "PackageKit-hif missing features" bug?
15:17:42 <rdieter> .bug 1098735
15:17:44 <rdieter> yes
15:17:45 <zodbot> rdieter: Bug 1098735 apper: hawkey backend missing features - https://bugzilla.redhat.com/1098735
15:18:22 <Kevin_Kofler> All the missing stuff looks doable to implement, but I don't know whether and when I'll be able to do it, any help welcome.
15:18:51 <rdieter> 1 3 are blocker-worthy, imo, 2 very much nice-to-have
15:18:58 <rdieter> 4 can wait as you mentioned
15:19:03 <Kevin_Kofler> We should really have at least set 3. done within a month, or Apper will be VERY broken for Beta, probably too broken to pass the release tests.
15:19:29 <Kevin_Kofler> For 1., IIRC, it's not considered a blocker if the kickstart preimports the Fedora keys.
15:19:38 <Kevin_Kofler> (which is why the kickstart has been doing that for a while now)
15:19:48 <rdieter> ok, blocker-worthy as in: gpg import needs to be handled *somewhere*
15:20:19 <rdieter> though it'll suck that PK will no longer be able to help with addon repos after initial install
15:20:21 <Kevin_Kofler> It's still crap because all the third-party repo GPG keys also need to be imported somewhere, and rpm --import in a Konsole sucks as a UI.
15:20:26 <Kevin_Kofler> Right.
15:22:10 <rdieter> I really wish PK folks had highlighted the need for help to impliment these missing pieces earlier
15:22:48 <rdieter> could be they didnt realize how needed these features were, but still
15:23:02 <Kevin_Kofler> FYI, AFAIK, set 4 also last worked with the old PreUpgrade, the yum backend never got FedUp support.
15:23:51 <rdieter> I'd rather not to resort to having to use yumex
15:24:57 <rdieter> Kevin_Kofler: anything else on the topic?
15:25:42 <rdieter> #action Kevin_Kofler will update bug #1098735 with details on missing PK backend features
15:26:08 <Kevin_Kofler> #link https://bugzilla.redhat.com/show_bug.cgi?id=1098735#c11
15:26:39 <rdieter> Kevin_Kofler: so your recommendation would be to help improve -hif to provide the missing features?
15:26:46 <Kevin_Kofler> IMHO, yes.
15:27:02 <rdieter> ok, sounds like a plan
15:27:14 <Kevin_Kofler> Comps shouldn't be that hard, it needs libcomps added to the mix and implemented.
15:27:53 <Kevin_Kofler> Maybe we also need to add something to librepo to fetch the comps data for the repo, I haven't looked THAT closely at how to get the comps.xml files.
15:28:04 <Kevin_Kofler> libcomps only parses them from a local file descriptor.
15:28:59 <Kevin_Kofler> The other stuff should be implementable in libhif and PackageKit-hif, based on hawkey and/or libhif functions.
15:29:06 <Kevin_Kofler> (at least 1. and 2.)
15:29:19 <Kevin_Kofler> (4. is yet another different matter and I don't care all that much about that one for now.)
15:29:46 <Kevin_Kofler> The main problem is, the documentation for the libs is lackluster, for many functions, the best documentation is the unit tests. :-(
15:31:10 <rdieter> Kevin_Kofler: I think I heard you mention something about "upstream access", if so, can you give more details?
15:32:32 <Kevin_Kofler> I have push access to PackageKit and now also libhif.
15:32:59 <Kevin_Kofler> If others are willing to help, hughsie will probably also hand it out to them (or you send a pull request and I merge it).
15:33:23 <rdieter> that's good to hear, very ncie
15:33:24 <rdieter> nice even
15:34:18 <Kevin_Kofler> For the lower-level stuff (like librepo, hawkey or libcomps), that has its own maintainers, so we'll have to sort it out with them. As I said, I don't think I'll have to add anything to libcomps or hawkey, maybe to librepo (quick access to the comps.xml files).
15:35:02 <Kevin_Kofler> The big problem is, we have only 1 month left to get the stuff sorted out.
15:35:09 <jgrulich> I'm leaving now, because it's going to rain so I would like to be at home before it starts
15:35:37 <Kevin_Kofler> I'm also going to leave…
15:36:21 <rdieter> ok, lets move on
15:36:30 <rdieter> #topic kf5/plasma5 status (dvratil)
15:36:33 <rdieter> dvratil_: ^^ ?
15:37:30 <dvratil_> KF5 5.2.0  are being built as we speak (I expect them to finish in ~hour or so) and Plasma 5.0.2 updates are ready, just waiting for KF5 to hit the repos
15:38:51 <dvratil_> I wanted to do the update during Akademy, unfortunatelly the internet connection at the venue prevented me from actually uploading the tarballs to Fedora, so it had to wait
15:40:31 <rdieter> cool
15:41:06 <rdieter> dvratil_: I think I'd asked before on irc, but dont remember the outcome... is there any blocker to bringing kf5 stuff to f20 ?
15:41:29 <rdieter> other than time/energy to do it
15:41:48 <dvratil_> rdieter, no - IIRC we agreed on me requesting the F20 branches - unfortunatelly that was before Akademy and I didn't get to do it, sorry
15:42:18 <rdieter> ok, so at the "if we have time, it would be nice to have" :)
15:42:42 <dvratil_> yep, dependency-wise there should be no problems at all
15:42:59 <rdieter> any other comments or questions about kf5?
15:43:38 <Kevin_Kofler> Can we sort out the translation conflicts?
15:44:01 <Kevin_Kofler> We need a script that lists all the translations KF5 and Plasma 5 stuff installs and blacklists them from kde-l10n CMakeLists.txt.
15:44:12 <rdieter> oh right, are there any bugs tracking that yet? (if not, probably should one one or some...)
15:45:22 <Kevin_Kofler> I guess there aren't any yet…
15:46:46 <rdieter> Kevin_Kofler: are you aware of conflicts in f21, or is this just f22/copr stuff?
15:48:02 * rdieter cant remember, but vaguely thinks it related only to plasma5 copr
15:48:35 <dvratil_> I too think this was related to applications
15:49:05 <rdieter> if that's the case, it's not a critical issue to worry about *now*, but needs fixing sooner or later
15:49:10 <Kevin_Kofler> Yeah, hopefully the Frameworks don't conflict, but you never know.
15:49:36 <Kevin_Kofler> Having scripts to list the stuff and compare with kde-l10n would tell us for sure.
15:49:46 <Kevin_Kofler> Or just trying to install kf5-* and kde-l10n-*.
15:50:17 <Kevin_Kofler> Plasma 5 definitely has conflicts with kde-l10n, there were user complaints about that.
15:51:23 <rdieter> ok, let's just keep an eye out for that and deal with it as needed
15:51:25 <rdieter> moving on...
15:51:43 <rdieter> #topic kde-4.14.1 status
15:52:01 <rdieter> got kde-4.14.1 imported/built for rawhide/f21 last night
15:52:11 <rdieter> will be submitting f21 updates here later today
15:52:22 <rdieter> getting started doing f20 builds this morning
15:54:54 <rdieter> followup question for kde-sig:  we can consider a sip/python-bindings stack update for f20, now there are no remaining blockers (PyKDE3 was fixed recently).  This will allow us to ship python-qt5 bindings (finally).  Options: 1.  include this feature along with kde-4.14.1 (at the same time). 2.  wait until 4.14.1 lands in stable updates and do later , 3.  forget it for f20, make it a f21+only feature
15:55:37 <rdieter> I'm leaning toward option 2 personally, since 1 includes a lot of work already.
15:55:44 <rdieter> thoughts?
15:56:28 <tosky> well, I guess option 2 is still "before F21"
15:56:37 <rdieter> repoquery --whatrequires sip  => http://paste.fedoraproject.org/133945/10882953
15:56:58 <rdieter> these will be approximately the items that need (re)building to accomplish it
15:57:51 <rdieter> tosky: probably, yes
15:58:41 <tosky> any possible blocker due to missing python-qt5?
15:59:38 <rdieter> I've received many requests for python-qt5 on f20, I'm not aware of any blockers
16:00:11 <rdieter> so we *could* do it, question is: should we?
16:00:41 <rdieter> In short, I'm willing to do the work, provided there are no objections
16:00:56 <rdieter> or concerns even
16:01:59 <rdieter> since I'd leaned toward defering this, let's do that. defer it until after kde-4.14.x lands
16:02:24 <rdieter> (I just talked myself into not rushing things here)
16:02:31 <rdieter> :)
16:02:35 <rdieter> #topic open discussion
16:02:48 <rdieter> I've an appointment I need to leave for soon, any last comments before ending the meeting?
16:05:15 <rdieter> alright, let's wrap, thanks everyone!
16:05:17 <rdieter> #endmeeting