15:08:31 <rdieter> #startmeeting kde-sig
15:08:31 <zodbot> Meeting started Tue Jun 17 15:08:31 2014 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:08:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:08:35 <rdieter> #meetingname kde-sig
15:08:35 <zodbot> The meeting name has been set to 'kde-sig'
15:08:40 <rdieter> #topic roll call
15:08:48 <rdieter> hi all, who's present for today's kde-sig meeting?
15:08:54 <pino|work> o/
15:09:03 * jgrulich is present
15:09:07 <Kevin_Kofler> Present.
15:09:52 <than> present
15:10:28 <danofsatx-work> presents? where?
15:11:04 <rdieter> #info pino|work jgrulich Kevin_Kofler than danofsatx-work present
15:11:16 <rdieter> #chair pino|work jgrulich Kevin_Kofler than danofsatx-work
15:11:16 <zodbot> Current chairs: Kevin_Kofler danofsatx-work jgrulich pino|work rdieter than
15:11:41 <rdieter> #info ltinkl sends regards, busy moving
15:12:08 <rdieter> #topic agenda
15:12:16 <rdieter> ok, what to discuss today?
15:12:35 <Kevin_Kofler> Presence/absence stats and consequences?
15:13:01 <Kevin_Kofler> http://repo.calcforge.org/temp/Meeting%20attendance.html
15:14:16 <jgrulich> dvratil is on PTO today, so he won't attend the meeting today
15:14:29 <rdieter> #info dvratil regards too, on PTO
15:15:41 <rdieter> do we need to discuss kde-4.13.x updates for F20?  I forget if we had a consensus on whether to move forward with that or not
15:16:12 <jgrulich> definitely +1 for kde-4.13.x for F20
15:16:47 <rdieter> any other agenda topics?  else, lets' get started...
15:17:02 <Kevin_Kofler> rdieter: We didn't have a consensus, I was the only one writing anything on the topic last week.
15:17:12 <jgrulich> Qt 5.3.1 update?
15:17:55 <rdieter> #topic presence/absense meeting stats (and consequences)
15:18:01 <rdieter> Kevin_Kofler: go ahead
15:18:20 <Kevin_Kofler> So, please look at the HTML table I made: http://repo.calcforge.org/temp/Meeting%20attendance.html
15:18:40 <rdieter> and, https://lists.fedoraproject.org/pipermail/kde/2014-June/013631.html
15:18:41 <Kevin_Kofler> Some stats are less than stellar (and that's just presence, ignoring lateness).
15:19:20 <Kevin_Kofler> One meeting canceled entirely (2014-04-22, thus the missing column), one (2014-06-10) with only 5 out of 11 voting WG members present.
15:19:38 <Kevin_Kofler> And the best of all: a voting WG member who didn't attend a single meeting.
15:20:39 <Kevin_Kofler> It's not the time either, I don't see him on IRC at any other time of the day either, nor is he actively participating in discussions elsewhere (ML etc.).
15:21:46 <Kevin_Kofler> So I proposed on the ML to replace siddharts (Siddharth Sharma) with danofsatx in the WG. (I hope danofsatx-work is OK with being nominated like that. :-) )
15:21:58 <danofsatx-work> wow, I need to fix my email - I missed that one entirely.
15:22:14 <jgrulich> I guess ltinkl put Siddhart to the list of WG members because he was quite active on our redhat-kde internall IRC channel
15:22:20 <danofsatx-work> I'm fine with it, I'd love to lend more than just my opinion ;)
15:22:43 <rdieter> agreed, though as I mentioned onlist, I'd prefer if siddhart could respond to thd thread and simply commit to doing better.  lacking that, +1
15:22:43 <jgrulich> I agree with that, so +1 from me
15:23:11 <Kevin_Kofler> There were also 2 +1 votes from ltinkl and from me on the ML.
15:24:20 <Kevin_Kofler> jgrulich: We really need people to be active on the public channels though.
15:24:21 <danofsatx-work> the only caveat, however, is that I am *not* a developer.
15:24:43 <Kevin_Kofler> danofsatx-work: Have a look at who's sitting in the other WGs, there are also non-developers in there.
15:24:57 <danofsatx-work> I know, I just wanted to make that clear to y'all
15:25:29 <Kevin_Kofler> In fact AFAIK we were the only WG with only developers/packagers on the roll.
15:25:45 <rdieter> any other opinions?  pino|work?  than?
15:26:08 <rdieter> if you'd like more time to think, that's ok, please do so onlist and followup on the thread there
15:26:13 <than> it's fine with me, +1
15:26:16 <pino|work> somebody tried to contact siddarth directly?
15:26:42 <jgrulich> pino|work: probably no, I haven't seen him on our IRC for a while
15:27:22 <Kevin_Kofler> At this point, it'd be at least 14 weeks (provable lower bound) until he can possibly reach a 50% attendance…
15:27:24 <rdieter> I can, I think he's siddvicious@fpo
15:29:56 <rdieter> otherwise, I think we can probably wrap up the topic here and continue onlist this week, and have some sort of resolution by next week's meeting
15:30:15 <rdieter> any final comments before moving on?
15:30:40 <Kevin_Kofler> To be honest, I'd also seriously consider replacing jreznik by somebody more dedicated to KDE. Don't get me wrong, I know jreznik (I've even met him personally several times), he did a lot of stuff for KDE on Fedora, but these days he has too many things on his plate unfortunately. :-(
15:31:18 <rdieter> I can reach out to him too in the same vein, ask if he can commit to more regular attendance or is just too busy these days.
15:32:07 <Kevin_Kofler> For everyone else, I'd really like to not have to ping you individually almost every week. :-(
15:32:14 <Kevin_Kofler> This gets boring really quickly.
15:33:24 <danofsatx-work> I'm here when I can, but I have a day job that interferes ;)
15:33:24 <rdieter> moving on...
15:33:33 <Kevin_Kofler> It's just annoying when there's a meeting time at 15:00 UTC and I find myself virtually "running after" half of the people supposed to attend the meeting at 15:15 UTC.
15:33:51 <rdieter> #topic F20 kde-4.13.x updates, ready?
15:34:24 <rdieter> I dont recall for sure if we'd reached consensus on moving forward with kde-4.13.x updates for F20, any caveats or objections, concerns at this point?
15:34:57 <jgrulich> I've been using it since 4.13.0 and it seems to be perfect, no issues spotted
15:35:04 <rdieter> My main concern is probably the nepomuk->baloo transition , as far as stability goes
15:35:17 <Kevin_Kofler> IMHO, +1 to 4.13 for F20, but also IMHO, kcm-balooadv is a requirement (and should get dragged in on upgrades one way or the other, too).
15:35:23 <rdieter> (stability as in 'stuff has changed')
15:35:30 <Kevin_Kofler> Last I checked, it was still stuck under review. :-(
15:36:38 <rdieter> ok, we'll consider that a blocker
15:36:52 <rdieter> (I agree)
15:37:55 <rdieter> .bug 1090615
15:37:58 <Kevin_Kofler> Let me know if you can't find a reviewer, I'll see if I find some time.
15:37:58 <zodbot> rdieter: Bug 1090615 kde-4.13 Tracking bug - https://bugzilla.redhat.com/1090615
15:37:58 <rdieter> tracking bug, fyi ^^
15:38:32 <rdieter> .bug 1097384
15:38:37 <zodbot> rdieter: Bug 1097384 Review Request: baloo-kcmadv - Baloo Desktop Search Advanced configuration module - https://bugzilla.redhat.com/1097384
15:38:37 <rdieter> currently, the only blocker ^^
15:39:07 <rdieter> I'll try to raise the issue onlist this week too, make a call for more testing, and bugs filed if neccessary
15:39:23 <rdieter> and move kde-4.13.x f20 builds from kde-unstable to kde-testing
15:39:35 <rdieter> (currently at 4.13.1)
15:42:03 * rdieter will move on in a bit if there are is no other feedback
15:42:23 <than> rdieter: +1 for moving
15:43:34 <Kevin_Kofler> Yeah, move on…
15:43:36 <rdieter> moving on...
15:43:40 <rdieter> #topic Qt-5.3.1
15:43:52 <rdieter> jgrulich: ^^
15:43:56 <rdieter> go ahead
15:44:13 <jgrulich> Qt 5.3.1 should be released today (at least according to the schedule)
15:44:24 <jgrulich> I'll do the update probably tomorrow when tarballs are out
15:45:09 <rdieter> jgrulich: I can reopen the f20-kde f19-kde koji targets if that would be helpful
15:45:47 <rdieter> (and this should probably replace the existing 5.3.0 builds in updates-testing, should resolve most of the important issues raised so far)
15:46:07 <jgrulich> rdieter: with those do I have to submit build overrides or how this should help me?
15:46:25 <rdieter> jgrulich: no buildroot overrides necessary, those targets are self-updating like rawhide
15:46:36 <jgrulich> rdieter: that would be definitely better
15:46:47 <rdieter> but... you'll have to manually tag the builds into ...-updates-candidate before submitting to bodhi
15:47:19 <rdieter> I think even chain-build should work here, just remember:  fedpkg build --target f20-kde
15:47:28 <Kevin_Kofler> Right.
15:47:34 <Kevin_Kofler> Chain builds work in custom targets.
15:47:53 <rdieter> (there was a time when chain-build didnt work, but that was fixed.  yay)
15:48:04 <jgrulich> perfect, sounds much easier
15:48:50 <rdieter> k, koji targets enabled.  should be ready by the time tarballs land
15:49:18 <jgrulich> I'll try to build it locally and then I can use chain-build when I already know the correct order https://fedoraproject.org/wiki/KDE_updates#Qt5
15:49:30 <Kevin_Kofler> And yes, don't forget the "koji tag-pkg f20-updates-candidate $yourbuilds", or Bodhi will not accept the packages for updates.
15:49:45 <jgrulich> ok
15:49:49 <Kevin_Kofler> The updates-candidate tags are open, everyone can tag into them, not just Koji admins.
15:50:48 <Kevin_Kofler> (The tags Bodhi then actually pushes to are protected though, so you can't tag something directly into stable updates. ;-) )
15:50:57 <rdieter> one last improvement/optimization not implemented yet, is sse2-optimized libQt5Gui builds
15:51:02 <rdieter> .bug 1103185
15:51:04 <rdieter> see also ^^
15:51:06 <zodbot> rdieter: Bug 1103185 Qt 5.3.0 defaults to sse2 x86 support - https://bugzilla.redhat.com/1103185
15:51:17 <rdieter> sse2-optimized i686 libQt5Gui builds, tha tis
15:51:45 <rdieter> but that's just a nice-to-have feature, imho, not a blocker
15:51:51 <Kevin_Kofler> Do we have that http://repo.calcforge.org/temp/qtbase-opensource-src-5.3.0-old-xcb.patch already applied?
15:52:35 <Kevin_Kofler> It should make things fully functional with F19's and F20's old libxcb(-xkb) and libxkbcommon, by reverting some changes that rely on the new APIs.
15:52:37 <rdieter> I didn't apply it.  I already gave my opinion that I want upstream feedback first
15:52:54 <Kevin_Kofler> I recommend applying this to the F19 and F20 builds, not Rawhide (though in theory it should work everywhere).
15:53:05 <Kevin_Kofler> I think pushing the F19 and F20 builds out without this is a horrible idea.
15:53:17 <Kevin_Kofler> You get basically no xkb support without this patch.
15:53:30 <Kevin_Kofler> IMHO, it's much safer to ship builds with the patch than without.
15:54:08 <rdieter> I want some effort made to upstream this, and not have to carry this downstream forever
15:54:45 <Kevin_Kofler> You won't have to carry this forever, only until F20 EOL.
15:55:09 <Kevin_Kofler> F21+ doesn't need this.
15:55:26 <rdieter> we do qt5 el6 builds too, fyi, but you don't care about that.
15:55:41 <rdieter> (i assume)
15:55:57 <rdieter> epel-7 is affected too, I believe
15:56:11 <jgrulich> I would like to also include dvratil's patch once it pass the review https://codereview.qt-project.org/#/c/83580/
15:56:19 <Kevin_Kofler> I have no idea whether RHEL 6 even has a usable libxcb-xkb at all to begin with…
15:56:53 <than> jgrulich: +1
15:56:53 <Kevin_Kofler> Anyway, if you want to ship your EL builds with no xkb support, that's your decision…
15:56:54 <rdieter> Kevin_Kofler: it does, well, configure and its buildsys uses it at least.
15:57:17 <rdieter> jgrulich: it's been merged, I see no reason why not
15:57:43 <Kevin_Kofler> rdieter: What version's buildsys? 5.3's without my patch doesn't accept any xcb-xkb older than 1.10.
15:57:54 <Kevin_Kofler> (see the first hunk of my patch)
15:58:27 <jgrulich> ah, that's probably the old review, he has a newer version of this patch, which fixes some introduced regressions
15:58:59 <jgrulich> https://codereview.qt-project.org/#/c/87091/ ← this is the new one
15:59:24 <Kevin_Kofler> As for efforts to get this upstreamed, do you really think upstream will want a patch that reverts their deliberate changes to make use of new APIs?
16:01:25 <rdieter> Kevin_Kofler: when the changes introduce functionality loss on a majority of deployed linux systems in the wild, yes, I'm sure they'd like to hear abou tit
16:01:25 <Kevin_Kofler> I can put it into their Gerrit system, but I feel that it's going to be a gigantic waste of time… :-( But if you insist, I'll do it.
16:01:54 <Kevin_Kofler> Only when building using system libraries…
16:01:56 <rdieter> I just want feedback, obviously the past as-is very likely is not acceptable
16:02:03 <rdieter> the patch...
16:02:15 <Kevin_Kofler> They bundle everything, even libxcb, and if you build with their bundled crap, things "just work".
16:02:28 <Kevin_Kofler> But there are many reasons we don't want to do that.
16:02:39 <Kevin_Kofler> Upstream, on the other hand, probably doesn't care about supporting old system libs.
16:02:46 <rdieter> wait, I thought you implied above functionality loss when using the bundled libraries
16:03:13 <Kevin_Kofler> You had builds with bundled libxkbcommon and not bundled libxcb.
16:03:27 <Kevin_Kofler> (which is already an unacceptable violation of our bundling rules)
16:03:40 <Kevin_Kofler> (another reason why this patch MUST go in!)
16:03:44 <Kevin_Kofler> Those already lose functionality.
16:04:00 <rdieter> yes, that's one weird/bad situation I want upstream to comment on
16:04:04 <Kevin_Kofler> The only way to get full functionality would be to also enable the bundled libxcb, which is a horrible idea (symbol conflicts…).
16:04:29 <Kevin_Kofler> Yet, I think that's the only setup upstream really cares about (or they wouldn't bundle libxcb to begin with).
16:04:30 <rdieter> I'm pretty sure they might not be aware of the implications of the choices they made here
16:04:50 <Kevin_Kofler> As I said, the path needs to be in Fedora, like YESTERDAY.
16:05:30 <rdieter> seems Kevin_Kofler and I fundamentally disagree, any other opinions?
16:05:38 <Kevin_Kofler> The only reason I didn't commit it yet is because 1. I had hoped you or jgrulich would test it locally and 2. there was the SSE2 issue at the same time (which is still not resolved).
16:06:08 <Kevin_Kofler> (It's not resolved because all other qt5-* packages, in fact probably ALL packages built using qmake-qt5, need to be rebuilt.)
16:06:13 <rdieter> I honestly don't know how to test this
16:06:31 <rdieter> Kevin_Kofler: the sse2 issue will get fixed when 5.3.1 lands
16:06:42 <rdieter> well, all the core qt5 packages anyway at least
16:06:51 <rdieter> can deal with the rest after
16:06:53 <Kevin_Kofler> Does it build? Does the build.log look right (no bundled libraries, no QT_NO_XKB etc.)? Does keyboard input work?
16:07:10 <rdieter> keyboard input works now :-/ without your patch
16:07:24 <Kevin_Kofler> It should keep working. :-)
16:07:33 <rdieter> ok, ie, no horrible regressions
16:09:08 <rdieter> looks like we're going over time, to sum up my stance: I won't block it, but I would greatly prefer some upstream feedback on this xkb/xcb issue prior to any downstream patching.
16:09:57 <rdieter> (and pretty sure other distros would appreciate that too)
16:11:31 * rdieter will close meeting in 2 min
16:11:34 <Kevin_Kofler> I can throw it to the lions… uh… Qt Gerrit and see what happens. :-)
16:12:32 <rdieter> probably starting a thread on upstream ml would be a better way to get feedback first
16:12:56 <rdieter> your patch just essentially reverts recent commits, right?
16:13:05 <rdieter> back to the way it was...
16:14:11 <rdieter> http://lists.qt-project.org/mailman/listinfo/development
16:15:39 <Kevin_Kofler> rdieter: More or less, yes. Though the reversion is somewhat forward-ported to adjust to other changes in the same file.
16:16:13 <Kevin_Kofler> The thing is, patches from the ML cannot be merged without going through Gerrit…
16:16:52 <rdieter> ok, whichever you think will get some upstream position outlined, and ideally some upstream fix implemented
16:16:54 <Kevin_Kofler> (because of CLA technicalities)
16:17:10 <rdieter> I don't care how it happens
16:17:58 <rdieter> thanks everyone, let's wrap up
16:18:10 <danofsatx-work> I will not be at the meeting next week due to RH300 class.
16:18:10 <rdieter> #endmeeting