15:16:37 <Kevin_Kofler> #startmeeting KDE SIG Meeting
15:16:37 <zodbot> Meeting started Tue Nov 11 15:16:37 2014 UTC.  The chair is Kevin_Kofler. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:16:37 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:16:46 <Kevin_Kofler> #meetingname kde-sig
15:16:46 <zodbot> The meeting name has been set to 'kde-sig'
15:16:50 <Kevin_Kofler> #topic Roll call
15:16:57 * Kevin_Kofler present, leading, who else is present?
15:17:09 * rdieter waves, hi
15:17:35 <pino|work> me
15:17:35 * ltinkl present
15:18:29 * dvratil is late
15:18:42 * dvratil or is he?
15:18:51 <Kevin_Kofler> We're all late. ;-)
15:18:55 <jgrulich> present
15:20:36 <than> present
15:21:42 <Kevin_Kofler> #chair rdieter pino|work ltinkl dvratil jgrulich than
15:21:42 <zodbot> Current chairs: Kevin_Kofler dvratil jgrulich ltinkl pino|work rdieter than
15:22:01 <heliocastro> me here
15:22:04 <Kevin_Kofler> #chair heliocastro
15:22:04 <zodbot> Current chairs: Kevin_Kofler dvratil heliocastro jgrulich ltinkl pino|work rdieter than
15:22:42 <Kevin_Kofler> #info Kevin_Kofler, rdieter, pino|work, ltinkl, dvratil, jgrulich, than, heliocastro present.
15:22:46 <Kevin_Kofler> #topic Agenda
15:23:38 <Kevin_Kofler> So I'd like to d
15:23:58 <Kevin_Kofler> I'd like to discuss plasma-oxygen (Qt 5 style) package naming and review request.
15:24:01 <rdieter> status updates for various stuff: f21 issues (PK/apper, oxyxgen-gtk), kde-4.14.3 status
15:25:41 <Kevin_Kofler> Right.
15:25:44 <heliocastro> frameworks 5 missing apps ?
15:25:48 <heliocastro> essential ones
15:26:35 <dvratil> heliocastro:  you mean KDE Applications 14.12?
15:26:47 <Kevin_Kofler> I'm not sure this is worth discussing. We'll just ship the KDE 4 ones in F22, only the stuff that needs to integrate into the workspace is really essential.
15:27:02 <heliocastro> Ok, so off topic discussion
15:27:08 <Kevin_Kofler> (because for that we can't just ship the KDE 4 stuff)
15:27:24 <Kevin_Kofler> We can do it at the end if there's time, but I doubt it. ;-) Let's get started on the pressing matters.
15:27:41 <Kevin_Kofler> #topic PackageKit hif comps support (for Apper) status update
15:27:46 <Kevin_Kofler> heliocastro: Your turn. :-)
15:28:05 <heliocastro> Ok, parser done on xms files, sent to hughsie
15:28:27 <heliocastro> waiting for answer to see if i use it as an alternative inside backend
15:28:38 <heliocastro> if he not have time to implement inside libhif
15:28:59 <heliocastro> parser is fast, but get packages info will be slow
15:29:21 <heliocastro> comps.xml provides only package name, so we need to get the package name, then query for all packages
15:30:03 <heliocastro> Unless hawkey accept multiple packages query, it wil be slow
15:30:11 <heliocastro> That's current stage
15:31:16 <rdieter> thanks
15:32:32 <Kevin_Kofler> AppStream also gives us only names, doesn't it? So I can't see it being slower than AppStream operations.
15:32:42 <heliocastro> Kevin_Kofler: True
15:36:32 <heliocastro> Appstream was discarded as an alternative
15:36:35 <Kevin_Kofler> I think hy_query_filter_in is what you want to query all.
15:36:52 <heliocastro> Yep, will be something like that
15:37:01 <Kevin_Kofler> I agree, AppStream is a complement to comps, not a replacement.
15:37:50 <Kevin_Kofler> #chair jreznik
15:37:50 <zodbot> Current chairs: Kevin_Kofler dvratil heliocastro jgrulich jreznik ltinkl pino|work rdieter than
15:37:55 <heliocastro> So, basically is in the hands of hughsie the timing
15:38:24 <heliocastro> But i will not wait too much
15:38:33 <Kevin_Kofler> I hope we can get it sorted soon. Time is running short.
15:38:45 <heliocastro> Yes, he's not on today
15:38:49 <heliocastro> I tried to contact him
15:38:58 <heliocastro> But can't pass this week
15:39:49 <rdieter> move on?
15:39:58 <heliocastro> Yep
15:39:59 <Kevin_Kofler> If hughsie doesn't respond, I can push to both upstream and Fedora for libhif and PackageKit. (He gave me upstream push access and I'm a provenpackager in Fedora.)
15:40:14 <Kevin_Kofler> But I'd rather let him do the reviewing of your changes, it's his projects.
15:40:33 <rdieter> is there anyone else (upstream?) that can review it?
15:41:11 <Kevin_Kofler> There are a few people with push access, but they might not feel qualified to review this (especially because it's backend code).
15:41:22 <heliocastro> I just talked with hughsie and dantti
15:41:28 <rdieter> k
15:42:05 <Kevin_Kofler> Sending a pull request can't hurt.
15:43:26 <rdieter> as far as oxygen-gtk goes, I'll try to implement the suggestion from https://bugzilla.redhat.com/show_bug.cgi?id=1103496#c60 today
15:43:46 <Kevin_Kofler> #info comps XML parser done, waiting for feedback and integration into libhif from hughsie
15:44:03 <Kevin_Kofler> #topic oxygen-gtk status update
15:44:14 <Kevin_Kofler> #link https://bugzilla.redhat.com/show_bug.cgi?id=1103496#c60
15:47:17 <Kevin_Kofler> rdieter: Makes sense.
15:47:22 <rdieter> that's all as far as oxygen-gtk is concerned, can move on to other stuff (unless there are other questions or comments)
15:47:31 <Kevin_Kofler> I'd change process-working-symbolic to process-working, which is available in Oxygen.
15:48:03 <Kevin_Kofler> Otherwise, I think GTK+ will prefer process-working-symbolic from another theme (e.g. GNOME).
15:48:03 <rdieter> Kevin_Kofler: OK, I'll run it by you when I'm ready to commit
15:48:34 <Kevin_Kofler> (There's a special hack for -symbolic that makes it not follow the usual fd.o precedence rules, where it would try process-working and process in Oxygen before falling back.)
15:52:00 <Kevin_Kofler> #action rdieter will try the workaround from the link above.
15:52:19 <Kevin_Kofler> #topic KDE 4.14.3 status
15:52:26 <Kevin_Kofler> rdieter: I guess that one will be a short one?
15:52:59 <rdieter> yup, builds mostly done over the weekend, I composed bodhi updates this morning (currently pending for f20/f21)
15:53:07 <rdieter> and pushed/signed to kde-testing repos too
15:53:18 <rdieter> (though I haven't done any test upgrades yet personally)
15:53:59 <Kevin_Kofler> #info builds mostly done over the weekend, rdieter composed bodhi updates this morning (currently pending for f20/f21) and pushed/signed to kde-testing repos
15:54:07 <Kevin_Kofler> Thanks!
15:54:25 <Kevin_Kofler> #topic plasma-oxygen Qt 5 style packaging
15:54:41 <Kevin_Kofler> dvratil: So we need to agree on the package naming and on how to process with the review.
15:55:01 <rdieter> is there a review already?  what bug #?
15:55:05 <Kevin_Kofler> I'd really like a version for Qt 5 apps in a KDE 4 environments (my plasma-oxygen 5.0.2 package) in F20 and F21 ASAP.
15:55:20 <Kevin_Kofler> There isn't one, because
15:55:25 <rdieter> ok
15:55:30 <Kevin_Kofler> a. I don't know what name to put on it and
15:55:41 <dvratil> I thought about the name
15:55:44 <rdieter> any proposals?
15:55:53 <dvratil> but I don't know if kde-style-* is the right name, as it's not a KDE style
15:55:59 <dvratil> it's Plasma style :)
15:56:27 <Kevin_Kofler> b. I still don't know whether the plan is to review 5.0.2 now and import the current version for Plasma 5, including the Qt 4 style, later, or import the latest version and then just get the 5.0.2 package into the branches.
15:57:15 <Kevin_Kofler> dvratil: I think kde-style-oxygen can stay for the Qt 4 version (also when we'll build it from the new tarballs shipped with Plasma 5).
15:57:42 <Kevin_Kofler> By the way, it should be built as a %package -n kde-style-oxygen from the same SRPM, not as a separate SRPM.
15:58:12 <Kevin_Kofler> But we need a decent package split with decent names for the new stuff.
15:58:22 <rdieter> dvratil: what's the tarball name?
15:58:27 <dvratil> yep for Qt 4, not sure for Qt 5. I would actually be happy to see "kde-" prefix go from the Plasma 5 packaging, unless it's an upstream name, but that's different topic I guess
15:58:32 <rdieter> (not that it matters much)
15:58:32 <dvratil> rdieter:  oxygen-x.y.z.tar.gz
15:58:39 <rdieter> qt5-style-oxygen ?
15:58:47 <rdieter> or qt5-oxygen
15:58:55 <heliocastro> like this one
15:58:56 <Kevin_Kofler> I propose, for Plasma 5 environments:
15:59:09 <rdieter> or heck, we could just call it 'oxygen' too, but that's a bit generic/ambiguous
15:59:15 <Kevin_Kofler> Qt 4 style → kde-style-oxygen (as before) or qt4-style-oxygen (with Obsoletes/Provides)
15:59:23 <Kevin_Kofler> KWin 4 style → don't build / delete
15:59:33 <Kevin_Kofler> Qt 5 style → qt5-style-oxygen
15:59:34 <dvratil> rdieter: yep, feels bit too generic, that's why I added the plasma- prefix
15:59:43 <Kevin_Kofler> KWin 5 style → kwin-style-oxygen
16:00:07 <Kevin_Kofler> Cursor themes → oxygen-cursor-themes (replacing the KDE 4 ones with the same name)
16:00:29 <Kevin_Kofler> Sound theme → oxygen-sound-theme (does not conflict with the KDE 4 version from kde-runtime, which uses different file names)
16:01:02 <Kevin_Kofler> plasma-oxygen for the SRPM and for a metapackage can stay, I guess.
16:01:09 * rdieter cares less about kwin, it can leave out -style as far as I'm concerned, that doesn't need multilib'ing (does it?)
16:01:55 <dvratil> rdieter: no, but it's nice to have it split - drags in less stuff if you use KWin on LxQt for instance
16:02:04 <Kevin_Kofler> For Plasma 4 environments (F20 and F21 without the plasma-5 Copr), I'd only build qt5-style-oxygen, and from the 5.0.2 version (because 5.1+ change the look&feel).
16:02:20 <rdieter> dvratil: I agree it should be split, I just meant I'm ok with kwin-oxygen name without -style in there
16:02:37 <Kevin_Kofler> And more importantly, the Qt style shouldn't drag in KWin.
16:02:40 <rdieter> but don't object to -style either
16:02:45 <Kevin_Kofler> (not even KWin libs)
16:03:07 <Kevin_Kofler> We can do kwin-oxygen, yes.
16:03:41 <Kevin_Kofler> If we want to be verbose, I guess kwin-decoration-oxygen would be more accurate than -style-.
16:03:56 <heliocastro> No no
16:04:05 <heliocastro> kwin-oxygen is good enough
16:05:01 <dvratil> Kevin_Kofler: +1 to everything from me, sounds reasonable. So qt5-style-oxygen for F20 and F21 would be a new package with oxygen-5.0.2, and would be retired in F22, where a subpackage from plasma-oxygen would provide the up-to-date 5.x version? And it would be automatically updated to latest when people add my Copr to F20/21
16:05:23 <Kevin_Kofler> I can just call it plasma-oxygen.spec too and build only the %package -n subpackage.
16:06:00 <dvratil> makes sense
16:06:16 <dvratil> so should I put up the full plasma-oxygen.spec for review?
16:06:23 <heliocastro> +1
16:06:41 <rdieter> dvratil: yes, +1
16:06:49 <Kevin_Kofler> So, for dvratil's package: keep plasma-oxygen.spec name, add %package -n subpackages as follows: qt4-style-oxygen (Obsoletes/Provides: kde-style-oxygen and plasma-oxygen-kde4 or how it's called now, don't build the KWin 4 style at all), qt5-style-oxygen, kwin-oxygen, oxygen-cursor-themes, oxygen-sound-theme, make the main package a metapackage that Requires everything.
16:06:55 <Kevin_Kofler> Is that right?
16:07:20 <rdieter> and call the main pkg/module plasma-oxygen from the start, can avoid the need for renaming/retiring later
16:07:54 <dvratil> yep
16:08:04 <Kevin_Kofler> For my package, I use plasma-oxygen.spec, but with only %package -n qt5-style-oxygen and no main package.
16:08:20 <heliocastro> Good enough
16:09:17 <Kevin_Kofler> So we send dvratil's stuff to review for Rawhide and request F20 and F21 branches, but we don't build the new stuff there, but I import my spec instead.
16:09:49 <Kevin_Kofler> Only question: does plasma-oxygen from plasma-5 build in Rawhide right now or do we have to send other stuff (like kwin) through review first?
16:10:02 <dvratil> we need KWin first to get KWin style
16:10:05 <Kevin_Kofler> I guess we could build without the kwin-oxygen subpackage for now, but that's extra work.
16:10:37 <dvratil> I can submit KWin too, though. It does not depend on anything, and we'll need it sooner or later :)
16:10:51 <dvratil> *does not depend on anything else from Plasma 5 releases
16:10:57 <Kevin_Kofler> That probably makes more sense, yes.
16:11:26 <Kevin_Kofler> It'll just have file conflicts with kde-workspace until the full migration is done.
16:11:46 <dvratil> and kwin is split out of kde-workspace already, so it will even go as smooth upgrade
16:11:49 <rdieter> dvratil: will we be able to retire kde-workspace-4.x  then?  or will we need to keep some bits?
16:12:01 <Kevin_Kofler> Ah, right, so not even file conflicts.
16:12:09 <dvratil> rdieter:  we might need to keep some libs
16:12:12 <rdieter> I know lots of stuff depends on libworkspace for example
16:12:18 <rdieter> k
16:12:18 <dvratil> yep
16:12:25 <rdieter> we'll cross that bridge when we come to it
16:12:43 <Kevin_Kofler> Some stuff, we'll be able to just kill, i.e., it doesn't make sense to ship the old libkdecoration if we don't ship the matching version of KWin.
16:13:06 <Kevin_Kofler> But other stuff may still be needed.
16:13:24 <Kevin_Kofler> In theory, nothing from kde-workspace should be needed, but… :-(
16:14:35 <dvratil> I would like to split some more applications from kde-workspace and kde-runtime to %package -n now, so that we have smooth upgrade later on (and don't have to fight with Provides/Obsoletes/Conflicts and what not
16:14:39 <Kevin_Kofler> There used to be a lot of kde-workspace-devel BRs, some got fixed when libplasma moved to kdelibs (that said, stuff using libplasma is also suspicious – it works if they were only using libplasma as a canvas, but not if they're plasmoids for the desktop), but I think there are still kde-workspace-devel BRs left.
16:14:58 <rdieter> dvratil: +1, when/if you have ideas on new splits, I'll be happy to help make it happen
16:15:47 <dvratil> great. I'll write up some wiki/document to sum up what's needed
16:16:57 <Kevin_Kofler> #agreed for dvratil's package (Plasma 5 environment): keep plasma-oxygen.spec name, add %package -n subpackages as follows: qt4-style-oxygen (Obsoletes/Provides: kde-style-oxygen and plasma-oxygen-kde4 or how it's called now, don't build the KWin 4 style at all), qt5-style-oxygen, kwin-oxygen, oxygen-cursor-themes, oxygen-sound-theme, make the main package a metapackage that Requires everything
16:17:39 <Kevin_Kofler> #agreed for KDE 4 environments, use my 5.0.2 package, use plasma-oxygen.spec, but with only %package -n qt5-style-oxygen and no main package
16:17:53 <Kevin_Kofler> Or should I already put the metapackage there with only Requires: qt5-style-oxygen?
16:18:12 <Kevin_Kofler> IMHO, it's not really useful to do that, is it?
16:18:35 <dvratil> for easier maintenance, we could just have a full spec everywhere, and use if (fedoraVersion >= 22) ... ?
16:18:57 <Kevin_Kofler> No. We're going to use different Source0.
16:18:57 <dvratil> and keep the F20/21 version at 5.0.2
16:19:27 <Kevin_Kofler> So it doesn't make sense to %if 0%{?fedora} the specfile.
16:19:36 <dvratil> ok
16:19:38 <Kevin_Kofler> It'll just make a mess and we need to have different SRPMs anyway.
16:20:24 <Kevin_Kofler> 5.0.2 is also different in that it did not support building for Qt 4. That was only introduced for 5.1 so that the new look&feel can be backported to Qt 4 apps.
16:20:35 <dvratil> right, so build is different too
16:22:52 <Kevin_Kofler> #topic Applications not ported to Frameworks 5 yet
16:23:06 <Kevin_Kofler> heliocastro: So, do we want to say anything for that?
16:23:37 <heliocastro> Yep. We can try start tracking down what apps are missing that we're consider essentials
16:23:38 <Kevin_Kofler> IMHO, the plan is clear: Identify the stuff that MUST be ported (plasmoids, KWin decorations, etc.), get those ported or retired from Rawhide.
16:23:51 <Kevin_Kofler> Applications will work just fine if they keep using Qt 4.
16:23:56 <Kevin_Kofler> So we'll just ship them as Qt 4.
16:24:26 <heliocastro> But we need the list anyway
16:24:29 <dvratil> yep, it will be a step-by-step migration, as more applications are ported to Qt 5, we just update our packages
16:25:03 <Kevin_Kofler> We shipped Fedora 9 with KDE 3 versions of kdepim, kdewebdev (which is still KDE 3 because nobody successfully ported Quanta Plus), kdevelop and all the third-party apps (Amarok, Digikam, Krusader etc.).
16:25:09 <heliocastro> dvratil: As i said before, we can use this in our favor helping to port pushing fedora name on this effort
16:25:24 <Kevin_Kofler> Some of that stuff was on the spin, some in the repos.
16:25:30 <dvratil> and who is going to help with the porting? :)
16:26:20 <Kevin_Kofler> And I'd rather ship a stable KDE 4 version of an application that works than a buggy pre-alpha KF5 port.
16:26:27 <dvratil> +1 ^^
16:26:31 <heliocastro> Agreed
16:26:49 <Kevin_Kofler> We can ship beta ports if they work properly and have all the features, but not broken ports just to claim we ship everything KF5.
16:26:58 <jgrulich> most users won't notice that they are still using KDE 4 version of some apps anyway
16:27:12 <Kevin_Kofler> jgrulich: If we get the theming right, yes. :-)
16:27:50 <Kevin_Kofler> Some users might also notice the different settings directories, which affects shared components like the KatePart that no longer share settings (but then again a lot of those settings ended up in the per-app config anyway).
16:28:12 <Kevin_Kofler> But most will just notice that it's all Breeze or all Oxygen.
16:28:34 <heliocastro> Ok, but at least we can flip priority over qt5 apps
16:28:49 <heliocastro> Meaning, if an app has qt4 and qt5, we can choose qt5
16:29:01 <heliocastro> And avoid the hell of having both
16:29:11 <heliocastro> Considering stable
16:29:32 <dvratil> I would do that only if the applications is oficially released with double-qt support
16:29:41 <Kevin_Kofler> As an example of an unreleased port, I think Kompare from frameworks is probably shippable right now, it'll definitely be shippable from the first 15.04 prereleases. That said, it's also fine as a KDE 4 app. In any case, we should ship matching Kompare and KDevelop so we don't need 2 versions of libkomparediff2.
16:29:47 <heliocastro> dvratil: Yep, this
16:30:25 <dvratil> Kevin_Kofler:  is libkomparediff for Qt 4 and 5 coinstallable?
16:30:43 <Kevin_Kofler> dvratil: In that case, we'll want it built against Qt 4 on F20 and F21 (and F19 if we really want to update it there) and against Qt 5 on F22.
16:30:45 <heliocastro> kdevelop is not usable yet
16:31:03 <Kevin_Kofler> dvratil: Should be, and I can fix it if not. :-)
16:31:08 <dvratil> ok :)
16:31:42 <Kevin_Kofler> But I think we'll just ship matching Kompare and KDevelop.
16:31:50 <Kevin_Kofler> Kompare in 14.12 will be KDE 4.
16:32:03 <Kevin_Kofler> And KDevelop is also still KDE 4, the KF5 port is not ready yet.
16:32:31 <Kevin_Kofler> (Kompare theoretically is, but it was ported days before the feature freeze and KDevelop is also not yet releasing, so I decided to punt until 15.04.)
16:33:31 <Kevin_Kofler> That reminds me that I should merge frameworks into master now that 14.12 was branched.
16:33:55 <Kevin_Kofler> (Otherwise, I'd have to come up with a really good excuse for why I'm not shipping the port in 15.04. ;-) )
16:36:08 <heliocastro> Maybe i go back to my first app Ark to port it
16:36:11 <Kevin_Kofler> A related question is, what do we do with the apps that are already ported (in 14.12) on F20 and F21?
16:36:31 <Kevin_Kofler> Are we going to push 14.12 to F21? To F20? (Surely not to F19. :-) )
16:36:46 <Kevin_Kofler> And are we going to push it all or only the apps that are still KDE 4?
16:37:32 <Kevin_Kofler> In principle, shipping KF5 apps should be possible, if we make sure qt5-style-oxygen gets dragged in by something.
16:37:52 <Kevin_Kofler> (It'll still mess up things for people using custom widget styles, but…)
16:39:40 <Kevin_Kofler> We did get some complaints about the KDE 4 Dolphin that we shipped as an update to F8 and even F7, integration was not as perfect as we would have hoped. (There were also some bugs that I had to fix, like not picking up the double-click vs. single-click preference.)
16:40:15 <Kevin_Kofler> Hmmm, are people still reading or should we just defer this to next week? :-)
16:40:19 <Kevin_Kofler> We're WAY over time.
16:40:32 <rdieter> <nod>, defer/take-to-mailing list
16:40:50 <rdieter> or back to #fedora-kde :)
16:41:36 <heliocastro> I'm still reading :-)
16:42:10 <Kevin_Kofler> heliocastro: So, speaking of Ark, that app could really use some love. :-) A lot of the features from the KDE 3 Ark are still missing in the KDE 4 version. :-(
16:42:18 <Kevin_Kofler> For example, there's not even a right-click, Open with…
16:42:19 <dvratil> IIRC ltinkl is taking care of Ark
16:42:25 <heliocastro> Ohhh
16:42:29 <ltinkl> ye sort of :)
16:42:37 <heliocastro> We have a suicidal..errr...new developer
16:43:07 <Kevin_Kofler> But I think we can move that to #fedora-kde, too. :-)
16:43:09 <heliocastro> Two guys tried to jump on the new ark design, one german and another brazilian
16:43:18 <heliocastro> Ok, moving
16:43:24 <Kevin_Kofler> Thanks all for coming!
16:43:28 <Kevin_Kofler> #endmeeting