15:16:29 <rdieter> #startmeeting kde-sig
15:16:29 <zodbot> Meeting started Tue Dec  8 15:16:29 2015 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:16:29 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:16:29 <zodbot> The meeting name has been set to 'kde-sig'
15:16:34 <rdieter> #meetingname kde-sig
15:16:34 <zodbot> The meeting name has been set to 'kde-sig'
15:16:38 <rdieter> #topic roll call
15:16:45 <rdieter> hi all, friendly kde-sig meeting, who's present today?
15:17:24 <dvratil> present
15:17:31 <tosky> hi
15:19:03 * Kevin_Kofler listening…
15:19:13 <than_> present
15:19:25 <rdieter> #info rdieter dvratil tosky Kevin_Kofler than_ present
15:19:30 <rdieter> #chair dvratil tosky Kevin_Kofler than_
15:19:30 <zodbot> Current chairs: Kevin_Kofler dvratil rdieter than_ tosky
15:20:24 <rdieter> #topic agenda
15:20:47 <dvratil> Plasma 5/ KF5 update update
15:20:52 <rdieter> off the top of my head, figured we could discuss: plasma-5.5 status, qt 5.6.0(beta) status
15:21:07 <rdieter> ah, kf5 release just happened too, yeah
15:21:08 * jreznik is listening, has important call in a few minutes
15:21:26 <rdieter> #info jreznik present (listening)
15:23:25 <rdieter> ok, let's start
15:23:36 <rdieter> #topic plasma5/kf5 status/update
15:23:42 <rdieter> dvratil: go ahead
15:23:56 <dvratil> so...plasma-5.5 is in rawhide and updates pending for F22 and F23
15:24:07 <dvratil> there are some issues with translations I believe that I still need to look into
15:24:30 <tosky> uhm
15:24:34 <tosky> compilation errors?
15:24:37 <dvratil> and someone send me a link to some last-minute commit that might need reverting in plasma-workspace
15:24:49 <rdieter> one issue onlist: plasma-5.5 seems to have lost/reset kickoff favorites
15:24:54 <rdieter> (I can confirm this)
15:25:15 <dvratil> hmm
15:25:18 <dvratil> that would be bad
15:25:24 <dvratil> rdieter:  do you mean the defaults?
15:25:32 <rdieter> my favorites used to have ~7-8 things, now I have one: dolphin
15:25:48 <rdieter> dvratil: I haven't tested defaults, my previous list of favorites seem to have been lost
15:26:03 <dvratil> hmm, so I need to check that too, could be caused by my patch for the defaults
15:26:17 <dvratil> the applet has been rewritten completely in QML, which means the old patch no longer appled
15:26:23 <rdieter> the defaults patch from 5.4 appears to be unchanged (or did I miss something?)
15:26:27 <rdieter> ah, nevermind
15:26:38 <rdieter> Seems I missed that
15:27:20 <dvratil> ok, so we need to look into those soon(ish) I guess
15:27:35 <dvratil> I probably won't be able to do so until tomorrow evening
15:28:04 <rdieter> Wrt the favorites, I'll try to do a bit more testing, and file a bug today (both downstream and upstream, if appropriate)
15:28:39 <rdieter> otherwise, plasma-5.5 has been a breeze for me
15:28:46 <dvratil> same here :)
15:29:00 <rdieter> (and even using qt 5.6.0 beta here)
15:29:16 <dvratil> for KF5 - 5.17 tarballs are on depot since last night, I'll kickoff a build tonight and hope for the best, otherwise I'll see what I manage to do tomorrow - for rawhide at least, F22/23 probably on Friday
15:29:18 <rdieter> though the latter still seems to have problems with > 1 display
15:29:22 <dvratil> :(
15:29:42 <rdieter> (or so I've heard, I only use/test single display systems myself so far)
15:30:04 <rdieter> jreznik was grumbling yesterday (and heliocastro too I believe)
15:30:20 <dvratil> jreznik is grumbling all the time about multihead ;-)
15:30:35 <rdieter> heh
15:30:36 <dvratil> I'm stuck with only one screen now, hard to test multiscreen support with that :)
15:31:26 <rdieter> anything else plasam-5.5 or kf5-5.17 related?
15:31:34 <dvratil> nothing from me
15:31:41 <rdieter> any notable changes wrt 5.17?
15:31:59 <dvratil> no new frameworks, no notable changes
15:32:06 <rdieter> k, moving on
15:32:49 <rdieter> #topic qt 5.6.0 (beta)
15:33:35 <rdieter> so, between helio, myself, and jgrulich, got qt 5.6.0 (beta/snapshot) into rawhide recently
15:33:45 <dvratil> \o/
15:33:50 <rdieter> after testing in copr for awhile
15:34:34 <rdieter> so far so good
15:34:40 <jgrulich> sorry I'm late, I'm here too
15:34:40 <dvratil> are the rawhide builds complete? I got some dependency errors when building gammaray last night
15:34:46 <rdieter> #info jgrulich present
15:34:48 <rdieter> #chair jgrulich
15:34:48 <zodbot> Current chairs: Kevin_Kofler dvratil jgrulich rdieter than_ tosky
15:35:06 <rdieter> dvratil: I thought all done
15:35:19 <dvratil> ok, maybe I was too early
15:35:21 <rdieter> as far as I knew
15:35:26 * dvratil tries again now
15:35:37 <rdieter> dvratil: if problems persist, poke us after meeting
15:37:00 <rdieter> reminds me, I have to get helio to document how he generates the snapshot tarballs
15:37:26 <rdieter> so others can help, and to have verifiable sources
15:38:05 <rdieter> so plans are to keep copr updated to approximately match what's in rawhide
15:38:23 <rdieter> https://copr.fedoraproject.org/coprs/g/kdesig/Qt5/
15:38:39 <rdieter> (right now, it's a wee bit out of sync, but we can fix that over the coming days)
15:39:20 <rdieter> anything else 5.6.0 related?
15:40:56 <rdieter> k, moving on
15:41:01 <rdieter> #topic open discussion
15:41:20 <dvratil> jgrulich: how are the PIM builds going?
15:41:53 <rdieter> ah, relatedly, we still need to purge anything depending on qt4 akonadi, yes?
15:42:08 <jgrulich> I'm building kdepim right now, seems that rebuild of kf5-akonadi against new gcc in rawhide works
15:42:15 <dvratil> cool
15:42:30 <jgrulich> I mean I'm building it locally first
15:42:36 <dvratil> rdieter: if it's optional, then just disable it, if it depends on kdepimlibs, but not on Akonadi, then it's fine
15:42:46 <rdieter> and iirc, we want some sort of kde4-compat akonadi-less kdepimlibs4
15:43:19 <rdieter> the newer kdepimlibs is kf5 based, right?
15:43:43 <dvratil> the tarball is called kdepimlibs, we package it as kf5-akonadi, because that's the only thing that it really contains
15:43:54 <rdieter> ah, sneaky
15:43:57 <dvratil> "kdepimlibs" will go away eventually
15:44:05 <rdieter> worksforme
15:44:34 <dvratil> hmm, I had some specfiles with stripped-down kdepimlibs somewhere, but I can't find it :(
15:45:09 <rdieter> dvratil: is it more than just omitting the akonadi bits?
15:45:49 <rdieter> then we need to go through the list of stuff that currently depends on kdepimlibs-akonadi, and come up with a plan to deal with those
15:47:08 <Kevin_Kofler> I'd say revert everything (with Epoch bumps where needed) to a pre-Akonadi version like 4.3.x.
15:49:39 <danofsatx> hi all, sorry I'm late. I was on the road.
15:49:54 <rdieter> #info danofsatx present
15:50:08 <dvratil> rdieter: actually I think it might be better to build kdepimlibs4 WITH akonadi libraries, just without Akonadi server
15:50:27 <dvratil> that way we can have things like KNode(4) back
15:50:28 <rdieter> dvratil: interesting, ok, we can try that
15:51:00 <dvratil> it's actually even easier to do that, since you only need to disable everything in akonadi's CMake and only build the one tiny private library
15:51:12 <rdieter> dvratil: so... adjust akonadi.spec to build only libs and omit the server ?
15:51:17 <dvratil> yeah
15:51:28 <dvratil> the library itself is co-installable with akonadi5
15:51:41 <rdieter> k, seems like a reasonable minimialist initial approach
15:51:44 * dvratil has to run now, sorry guys
15:51:56 <rdieter> of course, stuff that actually needs akonadi won't work right
15:52:10 <rdieter> but that's what probably has been or should be ported anyway
15:52:40 <rdieter> last topic I had in mind, was dealing with a f23 qt bug
15:52:51 <Kevin_Kofler> That's why I'm saying revert to 4.3.x (or enterprise4).
15:52:55 <rdieter> .bug 1279265
15:52:56 <zodbot> rdieter: Bug 1279265 qmake-qt4, libtool and others require redhat-hardened-cc1 and break compilation - https://bugzilla.redhat.com/1279265
15:53:18 <rdieter> short term, we can a dep to -devel: Requires: redhat-rpm-config
15:53:24 <Kevin_Kofler> But as long as you keep KNode working, I don't care all that much how you do it.
15:53:35 <rdieter> long term, can consider stipping RPM_OPT_FLAGS from default qmake
15:53:44 <rdieter> and inject them into packaging other ways
15:54:06 <rdieter> my first attempt with qt.spec to do that: http://paste.fedoraproject.org/298615/44958648
15:54:16 <rdieter> (borrowing a bit from opensuse's libqt4.spec)
15:55:15 <rdieter> any feedback on that would be appreciated... I'll take it onlist too
15:55:57 <rdieter> for example, packaged qt4 software should already be using %qmake_qt4 macro that sets QMAKE_CFLAGS_RELEASE and friends
16:00:24 <rdieter> looks like we're close to out of time, will close meeting soon, if no other comments
16:01:13 <danofsatx> none from the peanut gallery
16:02:54 <rdieter> ok, thanks everyone
16:02:57 <rdieter> #endmeeting