15:10:45 <rdieter> #startmeeting kde-sig
15:10:45 <zodbot> Meeting started Tue Feb 24 15:10:45 2015 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:10:45 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:10:49 <rdieter> #meetingname kde-sig
15:10:49 <zodbot> The meeting name has been set to 'kde-sig'
15:10:53 <rdieter> #topic roll call
15:11:03 <rdieter> hi all, friendly kde-sig meeting, how's present today?
15:11:06 <Kevin_Kofler> Present
15:11:39 <tosky> hi
15:12:08 <than> present
15:12:15 <jgrulich> hi
15:12:23 <rdieter> dvratil: ping
15:12:29 <dvratil> hi all
15:13:36 <rdieter> pino|work, danofsatx : ping
15:13:40 <pino|work> me
15:14:03 <rdieter> #info rdieter Kevin_Kofler  tosky  than jgrulich dvratil pino|work present
15:14:15 <rdieter> #chair Kevin_Kofler tosky than jgrulich dvratil pino|work
15:14:15 <zodbot> Current chairs: Kevin_Kofler dvratil jgrulich pino|work rdieter than tosky
15:14:20 <rdieter> #topic agenda
15:14:30 <rdieter> alright, what to discuss today?
15:15:18 <dvratil> I can give a quick update about KF5 and Plasma 5 update
15:15:22 <dvratil> and the kde-workspace strip down
15:15:53 <Kevin_Kofler> A general F22 KDE status update would be welcome too, I guess.
15:16:26 <rdieter> ok, that's all related , let's start with that
15:16:32 <Kevin_Kofler> Any known blockers? Freeze exceptions? "Nice to have but can go in as an update" things (such as kcm_*-kf5)?
15:16:37 <rdieter> #topic F22/Plasma5 status updates
15:16:40 <rdieter> dvratil: go ahead
15:16:52 <dvratil> so, I'm building Plasma 5.2.1 right now
15:17:08 <dvratil> which will hopefully solve all the GCC5-related problems
15:17:36 <dvratil> and we have KF5 5.7.0 in testing, would be nice if I could get karma, so I can update the Copr too
15:17:43 <rdieter> <nod>, for now, we pretty much have to ignore most bug reports against f23 until mass rebuild is done
15:18:13 <rdieter> ignore = assume it's gcc5 breakage
15:20:04 <ltinkl> rdieter: do you think the dbus related startup bug is also the same prob?
15:20:25 <rdieter> ltinkl: depends if you're talkign about f22 or f23
15:20:30 <rdieter> if f23, then yes :)
15:20:37 <ltinkl> f23 yes
15:21:01 <rdieter> at least until after mass rebuild is done and/or we have more evidence
15:21:35 * rdieter karma'd kf5-5.7 updates
15:22:11 <rdieter> dvratil: how about kde-workspace ?
15:22:41 <rdieter> at brno hackfest, dvratil started in on stripping it down for f22+
15:22:53 <dvratil> I put back the kcm_colors and fixed conflict with the one from plasma-desktop, so if there's nothing else I can send it for review today
15:22:59 <dvratil> (still need to finish one regex)
15:23:37 <rdieter> yay, I suggested for f22+ we purposely no longer keep branches in sync, since it's going to be much different and smaller
15:24:16 <rdieter> f22+ wil diverge from < f22 branches, that is
15:24:59 <Kevin_Kofler> I guess we can do that.
15:25:03 * heliocastro here
15:25:15 <heliocastro> ( sorry, lost summertime )
15:25:25 <Kevin_Kofler> My kdebase 3.5.x that could be built both as a full kdebase for F8 and as a very stripped-down kdebase3 for F9 was a bit extreme. :-)
15:25:31 <rdieter> late last week I started to work on minor comps/kickstart fixes, but the lack of successful live images made that hard
15:25:52 <rdieter> #info heliocastro present
15:25:54 <rdieter> heliocastro: hi :)
15:26:58 <Kevin_Kofler> How are we with the KF5 ports of things such as KCMs?
15:27:06 <Kevin_Kofler> And plasmoids?
15:27:20 <Kevin_Kofler> kcm_systemd recently released 1.0.0, a KF5 port, I already built it for Rawhide and F22.
15:27:21 <rdieter> there's quite a few kcm's not yet ported, I filed bugs for a few of the more visible ones
15:27:22 <ltinkl> Kevin_Kofler: all the relevant kcms are in plasma-desktop
15:27:32 <Kevin_Kofler> ltinkl: Not really, no…
15:27:40 <ltinkl> Kevin_Kofler: which ones are you missing?
15:27:52 <Kevin_Kofler> See the tracker. :-)
15:27:58 <rdieter> https://bugzilla.redhat.com/show_bug.cgi?id=plasma5
15:28:19 <Kevin_Kofler> Last I checked we were missing quite a few KCMs, plasmoids etc.
15:28:35 <ltinkl> Kevin_Kofler: we already ported print-manager with jgrulich
15:28:43 <Kevin_Kofler> Also, how do we handle kioslaves, such as kio_gopher?
15:28:50 <Kevin_Kofler> We should really ship both versions there.
15:28:53 <rdieter> ltinkl: ported upstream, but is it packaged downstream yet?
15:29:06 <Kevin_Kofler> (kio_gopher is ported upstream already.)
15:29:10 <rdieter> .bug 1135563
15:29:12 <zodbot> rdieter: Bug 1135563 kde-print-manager: support plasma5 (RFE) - https://bugzilla.redhat.com/1135563
15:29:18 <Kevin_Kofler> There's also kio_ftps (not to be confused with sftp).
15:29:18 <rdieter> ^^ add comments there
15:29:30 <Kevin_Kofler> (No idea what the upstream porting status is for kio_ftps.)
15:29:51 <rdieter> I personally haven't looked at plasoids at all yet
15:30:20 <ltinkl> rdieter: meh, http://download.kde.org/stable/applications/14.12.2/src/print-manager-14.12.2.tar.xz still has the KDE 4 version
15:30:22 <Kevin_Kofler> kioslaves are also not tracked on our tracker yet. :-(
15:30:32 <rdieter> ltinkl: maybe 15.04 ?
15:30:36 <ltinkl> rdieter: but I think it's been merged to master already so the next release should have it
15:30:47 <rdieter> the first beta should be coming in a week or 2
15:30:55 <ltinkl> rdieter: yup, most probably
15:30:56 <Kevin_Kofler> For the "plasma-scriptengine-python needs to be removed", isn't that just a matter of adding Obsoletes: plasma-scriptengine-python (and -ruby) to plasma-workspace?
15:31:00 <rdieter> ok, we can wait for that then
15:31:17 <rdieter> Kevin_Kofler: that's part of the kde-workspace work I think
15:31:20 <ltinkl> rdieter: yup http://commits.kde.org/print-manager/0accaed93c6113a33717d7f176d2df96261143a1
15:31:48 <rdieter> Kevin_Kofler: it will Obsoletes everything we no longer want (including that)
15:32:03 <ltinkl> and kde-connect should make a kf5 based release too, soon
15:32:19 <rdieter> goodie
15:32:27 <ltinkl> see https://albertvaka.wordpress.com/2015/02/23/releasing-kde-connect-code-in-edition/
15:33:03 <danofsatx> sorry, I'm here - meetings at $DAYJOB
15:33:07 <tosky> ltinkl, rdieter: if you were talking about print-manager, yes, it will be in 15.04
15:33:15 <tosky> as kf5 version, I mean
15:33:19 <rdieter> tosky: yes, thanks
15:33:29 <rdieter> #info danofsatx present
15:33:33 <rdieter> danofsatx: hi
15:33:39 <Kevin_Kofler> 15.04 will also have KF5-based libkomparediff2 and kompare. We'll need to coordinate shipping that with KDevelop though.
15:33:48 <ltinkl> apart from the kioslaves, that basically leaves us with apper and kcm_colord not ported yet
15:34:02 <ltinkl> I might start looking into the latter soon
15:34:10 <Kevin_Kofler> If KDevelop is not ready, we'll have to stick to the 14.12 version, or ship both versions of libkomparediff2 (they should be parallel-installable in principle).
15:34:41 <ltinkl> tosky: konversation already releases in kf5 flavor, doesn't it?
15:34:47 <rdieter> .bug 1194644
15:34:48 <heliocastro> kdevelop is far from be ready
15:34:49 <zodbot> rdieter: Bug 1194644 kf5 colord-kde - https://bugzilla.redhat.com/1194644
15:35:05 <rdieter> ltinkl: ^^ this one?  add comments there when you have anything to add
15:35:30 <rdieter> yes, konversation has a kf5 release, and Sho_ asked me to update it, I just haven't yet
15:35:30 <Kevin_Kofler> heliocastro: So stick to Kompare from 14.12, there isn't really anything new in the 15.04 version apart from the KF5 port.
15:35:43 <Kevin_Kofler> That, or ship both libkomparediff2 versions.
15:35:52 <ltinkl> rdieter: k, will take that big
15:35:53 <ltinkl> bug
15:35:53 <rdieter> I should add that (kf5 konversation) to the plasma5 tracker
15:35:59 <rdieter> ltinkl: ok, thanks!
15:36:01 <ltinkl> rdieter: it's there already
15:36:15 <ltinkl> https://bugzilla.redhat.com/show_bug.cgi?id=1193913
15:36:36 <rdieter> k, good. my brain stack space is too small
15:36:40 <tosky> ltinkl: I think konversation is still a beta
15:36:46 <rdieter> tosky: yes
15:37:13 <rdieter> Sho_ mentioned a final release should happen prior to f22 freeze
15:37:59 <Kevin_Kofler> How do we handle the kioslaves if we want to ship both versions?
15:38:04 <rdieter> the only other biggish item is ktp stuff, but that's supposedly coming along with 15.04 too
15:38:13 <Kevin_Kofler> kio5_gopher? kio_gopher5? kf5-kio_gopher?
15:38:30 <ltinkl> gopher? O_o
15:38:31 <heliocastro> tosky: konverstaion is more than ok already, i use it on my primary irc client already, is good enough to add
15:38:36 <rdieter> I think we reserve kf5- prefix only for real frameworks
15:38:46 <heliocastro> Kevin_Kofler comes from the rock ages :-)
15:38:54 <Kevin_Kofler> ltinkl: It was one of the first kioslaves that got ported upstream. :-)
15:39:22 <ltinkl> bet my socks half people in this channel never heard about gopher before :)
15:39:28 <rdieter> I'd be ok with a -kf5 postfix though, or inserting a 5 in there somewhere
15:39:29 * heliocastro bets that half of the people here never touched a gopher like process in their life
15:39:33 <ltinkl> heliocastro: xD
15:39:35 <tosky> well, not the first one, the main set was already ported :)
15:39:43 <Kevin_Kofler> Gopher is not a process, it's a protocol.
15:39:58 <rdieter> Kevin_Kofler: in this context, does kde4/kf5 versions build from the same sources?
15:40:06 <dvratil> I think we can easily have kio_gopher5 or kio5_gopher sounds OK
15:40:16 <heliocastro> Kevin_Kofler: I know, a process meaning DOING something using gopher
15:40:17 <Kevin_Kofler> I don't know, I guess not, but I'm not sure.
15:40:20 <tosky> rdieter: of kio-gopher or for any program?
15:40:31 <tosky> rdieter: usually the two versions are on different branches
15:40:32 <Kevin_Kofler> heliocastro: You just browse it like you'd browse a web page.
15:40:37 <Kevin_Kofler> gopher://www.calcforge.org/1/
15:40:38 <rdieter> tosky: in the context of kio stuff
15:40:42 <Kevin_Kofler> (for example)
15:40:49 <Kevin_Kofler> Same content as http://www.calcforge.org:70/
15:41:00 <Kevin_Kofler> (thanks to the multiprotocol server pygopherd)
15:41:24 <ltinkl> Kevin_Kofler: funny how it opens in dolphin here (which doesn't know what to do with it) and Google Chrome just puts a Google search on it :D
15:41:28 <Kevin_Kofler> Hmmm, or kio_gopher-kf5 maybe?
15:41:47 <Kevin_Kofler> I think we agreed on -kf5 suffix for most other KF5 ports outside of KF5 itself (where kf5- prefixes are used).
15:41:55 <dvratil> actually, upstream is calledk kio-gopher, so kio-gopher-kf5?
15:42:08 <heliocastro> Seriously, are we debating gopher ?? o.O
15:42:11 <Kevin_Kofler> The current package already uses the underscore though.
15:42:27 <rdieter> heliocastro: gopher is just an example :)
15:42:27 <dvratil> yeah, but my eyes bleed seeing kio_gopher-kf5
15:42:30 <Kevin_Kofler> heliocastro: The same goes for other third-party kioslaves, such as ftps.
15:42:40 <Kevin_Kofler> But gopher is the one I want to get in first. :-)
15:43:00 <rdieter> ok, seems there's multiple folks in favor of -kf5 postfix, if there are no objections, let's go with that
15:43:09 <heliocastro> +1
15:43:15 <danofsatx> +1
15:43:15 <Kevin_Kofler> dvratil: Well, there has been some bikeshedding over the dash-vs.-underscore issue, and it hasn't been settled, we have packages using both. :-(
15:43:54 <rdieter> any other f22/plasma5 related issues or topics worth discussing today?
15:43:55 <Kevin_Kofler> IMHO, kio_* and kcm_* are how the files are named, so those are the correct names, everything with kio-* or kcm-* in the name is a typo and needs to be renamed. :-)
15:43:58 <dvratil> Kevin_Kofler: inconsistent use of "-" or "_" between packages sucks, but OK...but inconsistent use inside package name? come on! :)
15:44:26 <Kevin_Kofler> kio_gopher is the name, -kf5 is the suffix, distinguishing is actually a feature here.
15:45:08 <Kevin_Kofler> Or do you want me to call it KIoGopher-kf_5? ^^
15:45:35 * dvratil just went blind
15:45:41 <rdieter> ah, while we're mentioning related updates, qt 5.4.1 landed upstream recently, and jgrulich graciously offered to work on updating our packaging
15:45:49 <dvratil> yay!
15:46:42 <dvratil> btw I have an awesome patch that improves XCB-XRandR integration, I think it would be nice to have it in Fedora, since it really improves user experience when fiddling with screens, but it will land in 5.6
15:46:55 <rdieter> +1
15:47:03 <Kevin_Kofler> So let's backport it.
15:47:17 <rdieter> i noticed, https://codereview.qt-project.org/#/c/107052/
15:47:24 <dvratil> rdieter:  that's the one :)
15:47:28 <Kevin_Kofler> I hate the long delivery cycles for fixes in those upstreams. We're still shipping 5.4 and 5.5 is already frozen.
15:47:45 <Kevin_Kofler> We'd really want such improvements to get into 5.4 (!), not 5.5 and clearly not 5.6.
15:47:55 <rdieter> except I think some work needs to happen to make this an smani's related fixes play nice with each other
15:47:56 <Kevin_Kofler> The upstreams are way too inflexible there.
15:47:56 <tosky> dvratil: is it the one you mentioned during the post-devconf dinner?
15:48:16 <Kevin_Kofler> KDE is getting better with the 1-month KF5.n cycles, but Qt is still as boneheaded as ever.
15:48:18 <dvratil> tosky: maybe, I don't really remember what I mentioned two weeks ago :)
15:48:38 * heliocastro reading the patch
15:49:01 <rdieter> slightly offtopic, did my own codereview submission last week, https://codereview.qt-project.org/#/c/106514/  (fixing qt-4.8.x build for gcc5)
15:49:16 <Kevin_Kofler> Yay!
15:49:22 <rdieter> my own *first* submission that is
15:50:00 <rdieter> not sure what's supposed to happen now, since thiago's comment (postive feedback mostly) almost a week ago
15:50:51 <Kevin_Kofler> Somebody is supposed to give it a "+2", Qt doesn't merge fixes without a "+2" no matter how many "+1" reviews they got.
15:51:06 <dvratil> rdieter:  I think you can merge now,
15:51:14 <Kevin_Kofler> (Did I yet mention that it's a corporate bureaucratic hell? (Still, despite "Open Governance"…))
15:51:24 <rdieter> dvratil: merge... how?
15:51:33 <heliocastro> dvratil: Nice patch, but adding symbols on library not make our qt too incompatible ?
15:51:34 <dvratil> there should be a button.. "Merge Patch Set 3 to Staging"
15:51:36 <rdieter> click the "merge patch set to staging" button?
15:51:41 <rdieter> ok, yay
15:51:52 * rdieter pushes button, hoping nothing explodes
15:52:18 <dvratil> heliocastro: it's a plugin, no public symbols
15:52:30 <Kevin_Kofler> heliocastro: Also, we don't care about ADDED symbols.
15:52:30 <dvratil> heliocastro: public ABI is not affected
15:52:35 <Kevin_Kofler> Only REMOVED symbols are a problem.
15:52:43 <heliocastro> Kevin_Kofler: Yes, we care
15:52:44 <Kevin_Kofler> We care only about people running third-party binaries on our Qt.
15:52:58 <Kevin_Kofler> Running our binaries on third-party Qt is Not Our Problem™. :-p
15:53:12 <Kevin_Kofler> (and I wouldn't even care about the third-party binaries thing either, but that's just me)
15:53:14 <heliocastro> Kevin_Kofler: What happens if any developer uses fedora to develop his application and end up to have a non functional app on any other distro with Qt ?
15:53:43 <Kevin_Kofler> The app will be non-functional on 90+% of the other distros anyway because nobody ships that new a glibc.
15:53:46 <rdieter> Kevin may not care, but we do need to care about that use-case too
15:53:57 <rdieter> if at all possible
15:54:06 <Kevin_Kofler> Building on Fedora will not give you a portable binary.
15:54:08 <heliocastro> But since is not the case, i do  +1 for dvratil plugin
15:54:35 <Kevin_Kofler> You need to build on CentOS (an as old one as possible) if you want that.
15:55:08 <Kevin_Kofler> So trying to make our Qt forward-binary-compatible (as opposed to backwards) with upstream / other distros is really a big waste of our time.
15:55:59 <Kevin_Kofler> Stuff built on Fedora 23+ (and maybe also on F22, depending on whether they also added any old-ABI symbols) will also need libstdc++ from GCC 5, there too, most other distros will not be shipping that for a while.
15:56:17 <heliocastro> Or again "If you use Qt or KDE applications, user Suse or even Kubuntu, Fedora is incompatible"
15:56:42 <Kevin_Kofler> I can see why you'd want to be backwards-compatible with upstream (proprietary blobs such as Skype, ewww!), but forward compatibility is really useless in Fedora.
15:57:02 <heliocastro> This mentality is what made everyone on the Qt or KDE approach thinking on other distros instead of Fedora
15:57:05 <Kevin_Kofler> heliocastro: Again, as long as we only ADD symbols, using third-party binaries WILL work.
15:57:08 <rdieter> can we stay on topic please?
15:57:09 <Kevin_Kofler> Only REMOVING symbols can break them.
15:57:11 <heliocastro> Ok ok
15:57:21 <heliocastro> +1 on dvratil code
15:57:40 <rdieter> I think each of your cases has been made, and it's clear no one's minds will be changed (not here in this meeting anyway)
15:58:36 <rdieter> our hour is almost up, any final comments before ending the meeting?
15:58:44 <Kevin_Kofler> And even if we don't add any non-upstream symbols, the mere fact that our Qt is newer than most other distros' will make binaries built on Fedora not work on the others.
16:01:24 <rdieter> ok, thanks everyone!
16:01:26 <rdieter> #endmeeting