15:14:49 <Kevin_Kofler> #startmeeting KDE SIG Meeting
15:14:49 <zodbot> Meeting started Tue Jul  1 15:14:49 2014 UTC.  The chair is Kevin_Kofler. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:14:49 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:14:53 <Kevin_Kofler> #meetingname kde-sig
15:14:53 <zodbot> The meeting name has been set to 'kde-sig'
15:14:59 <Kevin_Kofler> #topic Roll call
15:15:01 * jgrulich is present
15:15:03 * Kevin_Kofler is present, who else?
15:15:06 <than> present
15:15:11 <pino|work> me
15:15:25 <rdieter> here
15:15:36 * jreznik is here (sorry for long time absence...)
15:16:16 <mbriza> here
15:16:37 <tosky> here
15:17:30 <Kevin_Kofler> danofsatx-work: Ping?
15:18:23 <Kevin_Kofler> #chair jgrulich than pino|work rdieter jreznik mbriza tosky
15:18:23 <zodbot> Current chairs: Kevin_Kofler jgrulich jreznik mbriza pino|work rdieter than tosky
15:18:26 <Kevin_Kofler> #info jgrulich, Kevin_Kofler, than, pino|work, rdieter, jreznik, mbriza, tosky present.
15:18:29 <Kevin_Kofler> #topic Agenda
15:18:54 <Kevin_Kofler> So, what to discuss this week?
15:18:58 <rdieter> kde-4.13.x for f20 status update
15:20:46 <Kevin_Kofler> Qt 5.3.x status update, too…
15:20:58 <Kevin_Kofler> #topic KDE 4.13.x for F20 status update
15:21:07 <Kevin_Kofler> rdieter: Your turn.
15:22:58 <rdieter> ok, quick update: built most of it overnight, and the last couple are finishing up in koji now
15:23:35 <rdieter> when done, will put it all in kde-unstable for some quick smoke-testing.  if all well, will move over to kde-testing, and then start prepping a bodhi update
15:25:39 <rdieter> that's it for me
15:25:47 <tosky> rdieter: is it all fine on the policy point of view - second big update for a released version of Fedora? Is it fine from the "F20 longer life" point of view?
15:27:50 <rdieter> tosky: good questions, I guess I vaguely recall a week or 2 ago when discussing this, I think I said I'd consult fesco (I forgot)
15:29:09 <tosky> rdieter: are you willing to send this email, please? So that, by the time the packages are ready, it would be possible to push them
15:29:32 <rdieter> I can, but will be pretty busy today... I would appreciate if someone could help with this task.
15:32:35 <rdieter> any other questions or comments (or offers of help)? :)
15:33:07 <rdieter> pending the fesco thing, I'll amend the plan I mentioned to leaving these in kde-unstable, until we get the ok to move forward on the rest.
15:33:28 <tosky> not that I don't want to help, but I think that this task is better suited for someone who is already known by Fesco, has better knowledge of the processes, knows what should be written for the request
15:34:42 <rdieter> yeah, that helps.
15:35:03 <tosky> putting it in other words, I think that giving me (for example) instruction on how to do this would take more time that doing it directly most likely, but I can be proven wrong :)
15:35:19 <rdieter> waiting probably means a delay of a week or 2, and then kde-4.13.3 will be here by then
15:37:04 <rdieter> tosky: it's mostly a matter of informing them of our (hopeful) plans, and explaining why we're doing it.
15:40:20 <rdieter> sounds like not much else to say here, move on?
15:40:51 <Kevin_Kofler> IMHO, we shouldn't bother asking FESCo at all.
15:40:56 <Kevin_Kofler> Just push it and be done with it.
15:41:17 <Kevin_Kofler> F20 is still the latest Fedora release, the exception we already have is valid for that.
15:41:33 <Kevin_Kofler> (It's not our fault that F21 is taking forever.)
15:42:08 <rdieter> true, being an exceptional case.  still, I feel an obligation to inform them of whats going on at least
15:42:53 <rdieter> and help address any questions or concerns they may have
15:47:01 <rdieter> let's move on... time is running
15:47:12 <rdieter> #topic Qt-5.3.x status update
15:47:57 <rdieter> jgrulich: ??
15:48:14 <rdieter> and/or Kevin_Kofler
15:48:43 <jgrulich> not sure what you want to hear from me, qt 5.3.1 is done
15:49:08 <Kevin_Kofler> What I can report is that I made a scratch build with my old-xcb patch and fixed the compile errors in it.
15:49:12 <rdieter> just give a status update
15:49:14 <Kevin_Kofler> jgrulich tried it and it seems to work.
15:49:57 <rdieter> some folks here may not be familiar with the xcb-xkb issue you mention, can you give a little background?
15:50:01 <Kevin_Kofler> IMHO we should get that patch in, it fixes the bundling of libxkbcommon (which is not allowed) and it also fixes the regression that xkb support is lost.
15:51:12 <rdieter> (or maybe that is enough)
15:51:19 <Kevin_Kofler> Without the patch, on F19 and F20, Qt decides that libxcb-xkb and libxkbcommon are too old. Thus, Qt builds with a bundled libxkbcommon and then also defines QT_NO_XKB, using the fallback code using less powerful APIs.
15:51:51 <Kevin_Kofler> (Avoiding QT_NO_XKB without the patch would require building also with the bundled libxcb, something we really don't want to do.)
15:52:03 <rdieter> my position is to consult with Qt upstream about this (first), prior to any downstream reverting/patching
15:52:18 <Kevin_Kofler> My patch reverts some changes so that the older version of libxcb-xkb and libxkbcommon work again.
15:52:48 <Kevin_Kofler> I'm trying to submit this thing to Gerrit now, I already submitted a patch there once, but I don't remember the procedure exactly (only that it was a bit of a PITA, but it's doable).
15:53:04 <Kevin_Kofler> I didn't get around to it yesterday, I hope I get it done today.
15:53:32 <rdieter> Pretty sure they will reject the patch as-is.  doesn't it basically revert many recent changes?
15:53:43 <danofsatx-work> im here, finally. sorry, busy morning....
15:54:04 <rdieter> I hadn't taken a close look at it
15:55:01 <Kevin_Kofler> It reverts the changes that port the code from the existing APIs to new ones only available in the latest versions of xcb and xkbcommon, yes.
15:55:16 <Kevin_Kofler> That's the point, you have to do that if you want to compile against the old versions.
15:55:35 <Kevin_Kofler> And yes, I'm also pretty sure they'll reject the patch, which is why I'm complaining that much about you wasting my time that way.
15:55:42 <Kevin_Kofler> Just merge the patch in F19 and F20 and be done with it.
15:55:48 <rdieter> I didn't ask you to submit the patch
15:55:57 <rdieter> I asked you to consult with upstream about the issue in general
15:55:58 <Kevin_Kofler> We only have to carry it until F20 EOL, then the problem is gone.
15:57:30 <Kevin_Kofler> What do you expect upstream to respond? It's not their job to review distro patches.
15:57:35 <rdieter> imo, informing them of the consequences of requiring such very new xcb/xkb versions, and hearing what they have to say about it
15:58:08 <pino|work> there could be solid reasons why they required a newer xkbcommon
15:58:30 <Kevin_Kofler> pino|work: But if it's not there, we have to do with what's there, it's as simple as that.
15:58:58 <Kevin_Kofler> Using a bundled copy is a no go, and disabling XKB support is even worse. The builds that are now in updates-testing actually do both.
15:59:22 <Kevin_Kofler> Why would what worked in 5.2.x not be good enough for our 5.3.x builds?
15:59:28 <pino|work> and who tells you that won't create regressions? that's why asking upstream (as opposed to just drop a patch) is the first step
15:59:48 <rdieter> right, a majority of their target linux audience has been results (the "even worse" case)
15:59:58 <rdieter> has bad results... I mean
16:00:20 <Kevin_Kofler> pino|work: Why would reverting to the code that worked before create regressions?
16:00:32 <Kevin_Kofler> The builds that we have now in testing (without my patch) create regressions!
16:00:36 <Kevin_Kofler> (No more XKB support!)
16:00:48 <Kevin_Kofler> Those builds are broken and should not even have reached testing, let alone stable.
16:00:57 <pino|work> if they require a new versions of xkbcommon using its api, then there should be a reason, no?
16:01:17 <Kevin_Kofler> They only care about their bundled copy, they updated that and so they require the new version.
16:01:21 <Kevin_Kofler> That's how I read the commit messages.
16:01:39 <pino|work> hence the "ask upstream"
16:01:39 <danofsatx-work> ok, I'm supposedly here, but with the kded4 memory leak I'm having I have a +2 minute lag in Konversation
16:01:48 <Kevin_Kofler> Support for system libraries is only an afterthought there, they build their official binaries using bundled everything (xcb, xkbcommon and also a lot of other stuff).
16:01:55 <Kevin_Kofler> They don't care about distros using system libraries.
16:02:11 <Kevin_Kofler> pino|work: Then go ahead and talk to them…
16:02:22 * rdieter still thinks if 10% of the ranting about the qt bundled libraries was spent in composing an email to upstream, this would've been resolved long ago :-/
16:02:27 <Kevin_Kofler> I'm fed up of this.
16:03:16 <rdieter> I dont understand why you're so resistant to talking to them.
16:04:28 <rdieter> anyone else agree or disagree with my prerequiste to contacting upstream?  ( Kevin_Kofler disagrees, obviously)
16:04:50 <jgrulich> I agree
16:04:53 <pino|work> i agree
16:04:56 <Kevin_Kofler> Because 1. it's yet another mailing list I'd have to subscribe to (and then figure out how to disable mail delivery to prevent it spamming my inbox – do they even use Mailman at Qt? And are they on Gmane? All the mailing lists I use except the very-low-volume kde-packager are.), 2. I still don't understand what I'm supposed to ask and how and 3. with my people skills, I'm probably the worst person to talk to
16:04:57 <Kevin_Kofler> upstream…
16:05:16 <rdieter> they're on gmane
16:05:39 <Kevin_Kofler> That'd be 1., now what about 2. and 3.?
16:05:59 <rdieter> gmane.comp.lib.qt.devel I believe
16:06:47 <rdieter> inform them that the raised requirements for system libraries, and created a situation where a majority of downstream distros essentially ship with xkb support disabled (or greatly hindered).  or something like that
16:07:00 <Kevin_Kofler> "Why the fuck are you requiring a fucking useless new version of xkbcommon from yesterday evening just because you fucking updated your fucking bundled copy to that fucking version, when the old fucking code just fucking worked, fuck???" surely can't be it. ^^
16:07:26 <rdieter> just state facts, minus cursing, and you're 90% there. :)
16:08:56 <rdieter> and why using all bundled libraries are bad, both from a policy and bugs (different bundled libxcb stuff and apps linked against older libxcb can lead to symbol conflicts)
16:08:58 <Kevin_Kofler> And my position is that the patch needs to go into the Fedora builds "yesterday", the current ones are a total no go, and so we should just merge it NOW.
16:12:00 <Kevin_Kofler> All this talking is just wasting everyone's time. Don't ask, do. (Same for the KDE update and FESCo…)
16:12:51 <pino|work> this is not talking
16:13:03 <rdieter> yes, collaboration is sometimes annoying, but its still worth doing
16:13:34 <pino|work> if upstream is using some version of a library, then at least knowing why they do (in case you think it's wrong) should be a first step before cutting stuff
16:16:35 <Kevin_Kofler> pino|work: Then why don't you ask them if you think it's important?
16:17:11 <Kevin_Kofler> From my point of view, I made things work and I'm fed up that you guys are reluctant to merge my patch and would rather ship a broken build just because.
16:17:19 <pino|work> moving to me your responsability (as in doing the work on qt5 & xcb) doesn't work
16:17:29 <Kevin_Kofler> My responsibility is to make the Fedora builds work.
16:17:34 <Kevin_Kofler> It's not upstream's responsibility.
16:17:36 <pino|work> yeah, we know you are fed up with anybody not thinking exactly as you do
16:17:47 <Kevin_Kofler> So it doesn't make sense to talk to upstream about what we ship in Fedora.
16:17:59 <pino|work> now please do start being *collaborative*, and stop this useless ranting, thanks
16:18:10 <pino|work> and you are still not getting the point
16:18:18 <rdieter> Kevin_Kofler: I'm sorry you feel that way, but I vehemently disagree
16:18:26 <Kevin_Kofler> I'm fed up with people wasting my time and putting rocks on my road when I try to do actual work.
16:18:56 <Kevin_Kofler> And now I'm off to watch Argentina vs. Switzerland, which is surely more interesting than this discussion which isn't getting anywhere…
16:18:59 <rdieter> you know and understand the requirements here, your choice
16:20:14 <rdieter> you can choose to talk to upstream, and then we can evaluate the need for downstream patches .... or not
16:21:11 <rdieter> #topic open discussion
16:21:23 <rdieter> we're already a bit over time, any other comments or thoughts before we end the meeting?
16:22:59 <Kevin_Kofler> There's no need to talk to upstream to evaluate the need for downstream patches.
16:23:11 <Kevin_Kofler> You just have to look at the build.log of the builds that you ship to see that they're broken.
16:23:31 <Kevin_Kofler> Your nonsense post makes no sense whatsoever.
16:24:16 <rdieter> I wouldnt mind being wrong or if I were in the minority here.  But I'm not (yet).
16:25:45 <rdieter> I may end up talking with upstream about this too eventually, someone should.  I was hoping that someone would be you, who already cares and understands the issues involved.
16:26:27 <rdieter> ok, no new topics, let's wrap things up.  Thanks everyone!
16:26:29 <rdieter> #endmeeting