fedora-meeting
LOGS
15:06:43 <rdieter> #startmeeting kde-sig
15:06:43 <zodbot> Meeting started Tue Feb 26 15:06:43 2013 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:06:43 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:06:47 <rdieter> #topic roll call
15:06:51 <Kevin_Kofler> Present.
15:06:55 <rdieter> hi all, who's present today?
15:07:03 * jreznik is around
15:07:15 <jgrulich> present
15:07:19 * mbriza .
15:07:55 <than> present
15:07:58 <tdfischer> hola
15:08:15 <rdieter> #topic rdieter Kevin_Kofler jreznik  jgrulich mbriza than tdfischer present
15:08:21 <rdieter> #chair Kevin_Kofler jreznik  jgrulich mbriza than tdfischer
15:08:21 <zodbot> Current chairs: Kevin_Kofler jgrulich jreznik mbriza rdieter tdfischer than
15:08:33 <rdieter> #topic agenda
15:08:45 <rdieter> okie dokie, agenda, what to discuss today?
15:08:56 * rdieter can give update on qt5 packaging
15:09:25 <Kevin_Kofler> KDE 4.10 for F17?
15:10:25 <rdieter> if we have time, would like to hear from those who attended devconf2013
15:10:44 * jreznik attended devconf :)
15:11:00 * Kevin_Kofler too.
15:11:06 <rdieter> my brain is tickling about something we'd tabled from last week (or 2)
15:11:25 <jreznik> wasn't that kde 4.10 for f17?
15:11:30 <rdieter> except that discussion about said mystery topic was supposed to happen onlist
15:11:32 <jreznik> and Kevin_Kofler already put it on agenda
15:11:42 <rdieter> maybe
15:11:54 <rdieter> ok
15:12:08 <rdieter> let's start with that then
15:12:13 <rdieter> #topic KDE 4.10 for F17
15:13:02 <Kevin_Kofler> Somehow we don't use the mailing list nearly enough.
15:13:13 <rdieter> finally got packages done for testing early last week, http://lists.fedoraproject.org/pipermail/kde/2013-February/012298.html
15:13:26 <rdieter> not much followup or feedback yet though
15:14:28 <than> rdieter: i will update and test it on my f17 test machine today
15:14:31 <Kevin_Kofler> I'm going to have a look at libkdcraw to see what he had in terms of libjpeg support in F17 and whether I need to do anything to keep it from regressing.
15:14:37 <Kevin_Kofler> *what we had
15:14:47 <than> rdieter:  thanks for f17 build
15:15:10 <rdieter> along with kde-4.10 comes digikam-3.0 and calligra-2.6.x
15:15:16 <rdieter> fyi
15:15:34 <rdieter> (since those need rebuilding anyway, may as well bump to latest versions too)
15:15:49 <Kevin_Kofler> Unless you think it makes sense to ask for a libjpeg-turbo bump in F17 too. I'm afraid it might not be wildly popular, even though MAME in RPM Fusion would also benefit from it (it also wants jpeg_mem_src, which is why belegdol has been nagging for the update in F18 too).
15:16:13 <rdieter> Kevin_Kofler: can't hurt to ask, even if we know what the answer will likely be
15:16:46 <Kevin_Kofler> There's a custom jpeg_mem_src already in the libkdcraw build tree as part of the RawSpeed stuff, so I guess that workaround could be used everywhere.
15:17:27 <Kevin_Kofler> Or it might actually not matter whether we build that support in core LibRaw if RawSpeed is used, I'm not sure there, I must say.
15:17:28 <rdieter> yeah, not a *huge* deal
15:18:05 <Kevin_Kofler> As I said, I need to have a look, but had other more pressing issues to deal with.
15:18:25 <rdieter> my biggest worry will be the required sip/PyQt4 version bump, but we've done that before without too much fuss
15:18:32 <Kevin_Kofler> Yeah, right.
15:19:19 <rdieter> oh, and kdegames reviews are down to 2.  nucleo has done a majority of those reviews, gold star for him
15:19:28 <rdieter> left is ksirk and kolf
15:19:54 <Kevin_Kofler> KDE SC + Digikam + Calligra + the PyQt4 stack does have a bit of a "service pack" feeling… ;-)
15:20:03 <rdieter> very much so
15:21:28 <rdieter> ok, so more testing testing, and requests for feedback seems to be the name of the game for now
15:21:40 <Kevin_Kofler> Right.
15:22:19 <rdieter> another task: should we give fesco notice of our intentions wrt f17? (probably so)
15:22:43 <rdieter> any sucker^H^H^H^H^H volunteer to do that?
15:23:24 <Kevin_Kofler> Why bother? Let's just push it!
15:24:03 <rdieter> ok :)  anyone else with an opinion?
15:24:52 <than> it's ok with me, but mor testing and testing!
15:25:33 <jreznik> well, I have to say - I'm not very happy with such huge update, and I don't see a real reason for it
15:25:53 <jreznik> and if we want to go to fesco with that, we need arguments - a lot and strong I'd say
15:26:06 <Kevin_Kofler> Some people claim kdepim is worlds better in 4.10 than in 4.9.
15:26:22 <Kevin_Kofler> I haven't tried 4.10 yet, so to be honest, I can't really judge.
15:26:31 <rdieter> (kdepim is, fwiw, really).
15:26:47 <rdieter> that said, I largely agree with jreznik.  I don't feel strongly either way
15:27:05 <jreznik> Kevin_Kofler: for me - I don't see a big differences between kmail 4.9 and 4.10, but 4.9 really did the breakthrough
15:27:21 <rdieter> there was close to consensus that we wanted to push for it the past couple of meetings, iirc
15:28:19 <than> the benefit is we save a lot of backport fixes and only maintain on kde version for F17/F18
15:28:33 <ltinkl> the most important reason is we want our users to have the latest and best experience
15:28:35 <ltinkl> and also stable
15:28:59 <ltinkl> F17 users are no different from those on F18
15:29:20 <Kevin_Kofler> and we actually fix the bugs on F17 too. On F16 (and F12-F15 before that), some bugs just didn't get fixed because nobody bothered doing the backport.
15:30:18 <ltinkl> indeed and if F17 gets the latest kernel and xorg packages, I see why KDE should be any different
15:30:42 <ltinkl> we are not shipping experimental or unstable stuff
15:30:55 <jreznik> well, we already set our own policy - one update per release, even if you consider delay of f18, I don't see a big reason to do so
15:31:21 <Kevin_Kofler> (Speaking of backports to stable releases, rdieter, what about the kwebkitpart with translations for F17? You pushed it only to F18.)
15:31:24 <ltinkl> dealying F18 was not our fault
15:31:26 <rdieter> jreznik: true, but without the f18 delay, the liklihood of our seriously considering this would be much lower, imo.
15:31:57 <rdieter> Kevin_Kofler: the bug was filed on f18  :)
15:31:59 <jreznik> ltinkl: but it's out, it has the update...
15:32:11 <Kevin_Kofler> rdieter: But we want it fixed on F17 too.
15:32:14 <rdieter> Kevin_Kofler: it's not like it was a regression (we'd never shipped translations)
15:32:31 <rdieter> feel free to do the update then, i'm not opposed to it
15:32:59 <Kevin_Kofler> OK, I'll push it.
15:33:04 * jreznik is not strongly against but would like to see a real reasons - especially if someone wants to go to fesco with that :) "we are too lazy to backport is not a reason :D"
15:33:25 <rdieter> jreznik: some fixes can't be backported too, of course
15:33:30 <jreznik> Kevin_Kofler: well, first update to 4.10 and try it :)
15:33:45 <ltinkl> make
15:33:51 * jreznik thinks 4.10 is quite good
15:33:56 <ltinkl> (eheh, wrong windows :)
15:34:02 <rdieter> or backporting is a *lot* of work, rebasing is sometimes a risk, for relatively little gain
15:34:15 <Kevin_Kofler> Well, in principle everything can be backported. But if the backport is basically the whole diff between 4.9 and 4.10, it doesn't make sense to do it as a backport. ;-)
15:34:22 <jreznik> :D
15:34:40 <rdieter> so, looks like good candidates to champion this to fesco would be:  than, ltinkl, Kevin_Kofler
15:35:07 <Kevin_Kofler> Considering the "success" I've had at FESCo, I'd rather remove myself from that list. ;-)
15:35:18 <ltinkl> right, reminds of SUSE stable no backport policy: every dir having a huge 4.X_BRANCH.patch file
15:35:28 <ltinkl> that's nonsense
15:35:41 <Kevin_Kofler> Yeah, LOL. Though I've also seen that kind of stuff in RHEL SRPMs. ;-)
15:36:24 <ltinkl> if Fesco realy really wants us to obey that policy, we could always pull a similar approach
15:36:28 <rdieter> in short, the f18 delay is the game-changer here
15:36:33 <Kevin_Kofler> One example of where a backport is not reasonably possible is the infamous "krandr forgets display settings on reboot" bug with a handful duplicates.
15:36:34 <ltinkl> which would emphasize how ridicular that rule is
15:36:40 <rdieter> kde-4.9 is already eol upstream
15:36:50 <ltinkl> rdieter: good argument
15:36:59 <Kevin_Kofler> It's fixed by kscreen, it can't be backported to krandr, krandr would need a completely unwritten fix.
15:37:23 <rdieter> we have kscreen builds for f17 already... mind you. :)
15:37:37 <ltinkl> ypu but we won't get any new 4.9 release
15:37:55 <Kevin_Kofler> rdieter: Sure, it was just an example that has come to my mind.
15:38:07 <Kevin_Kofler> It's not directly related to 4.10.
15:38:11 <rdieter> than, ltinkl : looks like it's down to you 2
15:38:19 <Kevin_Kofler> But speaking of that, do we want to enable kscreen by default for F18 now? And F17? Or do we stick to keeping it (as default) F19 only?
15:38:49 <rdieter> Kevin_Kofler: last I'd asked dvratil, he wasn't willing to do that yet for f18
15:38:57 <Kevin_Kofler> OK
15:39:25 <Kevin_Kofler> I'm just getting a bit fed up of the duplicate reports about that krandr suckage. ;-) I just had to close another one last night.
15:39:25 <ltinkl> the last time you asked him was after he had several beers and a couple of whiskeys mind you ;)
15:39:47 <rdieter> ltinkl: heh, I should've tried harder to change his mind!
15:40:13 <rdieter> anyway, we don't have to decide *today* on who and how to tell fesco, but it needs to be done sooner or later
15:40:19 <dvratil> ok, let's do it. We now have enought experience with the upgrade path to do it smoothly :)
15:40:27 <rdieter> woo
15:40:29 <Kevin_Kofler> Though changing the default probably trashes saved settings, if krandr somehow did magically manage to remember them for somebody. ;-)
15:40:49 <than> before asking fesco, imo we need to test KDE F17 and get more feedbacks first
15:41:06 <ltinkl> than: iirc rdieter already did that on the ML
15:41:45 <than> ltinkl: i saw it but there's not much feedbacks from the ML !
15:41:52 <than> we need more!
15:42:20 <ltinkl> we could put it for a longer period in updates-testing... dunno
15:42:29 <than> and of course we need good arguments for fesco
15:42:30 <rdieter> true, I'll followup onlist asking for more testing/feedback
15:43:04 <rdieter> any final thoughts wrt kde-4.10?  I'd like to move on to our remaining topics while we have time
15:43:40 <Kevin_Kofler> move on ++
15:44:01 <rdieter> #topic qt5 packaging update
15:44:27 <rdieter> qt5-qtbase, q5-qttools, qt5-qtwebkit submitted for review, each have reviewers already
15:44:37 <rdieter> than doing qt5-qtbase is the most important one, obviously
15:44:43 <Kevin_Kofler> Great, I hope we'll soon have that through.
15:44:52 <Kevin_Kofler> (all of Qt 5)
15:44:54 <rdieter> i have most of the other modules done yesterday, will hopefully submit for review today or tomorrow
15:45:05 <rdieter> work in progress is @ http://rdieter.fedorapeople.org/rpms/qt/
15:45:29 <rdieter> make that http://rdieter.fedorapeople.org/rpms/qt5/
15:46:30 <rdieter> that's all I have on that, for now
15:46:43 <rdieter> I'll put intermediate builds into kde-testing as time allows
15:47:18 <rdieter> any questions/comments?
15:47:22 <Kevin_Kofler> Where's qtwidgets?
15:47:38 <tdfischer> its all qml now you know
15:47:45 <tdfischer> /s
15:47:47 <rdieter> Kevin_Kofler: qtbase I think
15:48:00 <Kevin_Kofler> Yeah, I see it there.
15:48:16 <rdieter> qt5-qtbase-x11 subpkg
15:48:32 <rdieter> following qt-x11 example
15:48:48 <Kevin_Kofler> Those modules still containing a bunch of libs, and especially qtbase mixing core and UI stuff, really make me wonder what the heck the modules are for…
15:48:53 <than> Kevin_Kofler: it'sincludee in qt-base
15:49:54 <rdieter> besides qtbase-x11 and qtbase sql driver subpkgs, I've not done much of any splitting of stuff ... yet.
15:50:01 <Kevin_Kofler> With Wayland coming, I wonder if we won't want to have qt5-qtbase-gui for most of the stuff and qt5-qtbase-x11 with only the xcb plugin. But with OpenGL dragging in the X11 stuff anyway, it doesn't make a lot of sense.
15:50:33 <rdieter> qttools has designer and assistant, where some finer splitting may make sense too
15:50:45 <Kevin_Kofler> So I guess having things as now is OK for now.
15:51:02 <Kevin_Kofler> Splitting -x11 can always be done later.
15:51:14 <rdieter> true
15:51:53 <Kevin_Kofler> (The linuxfb stuff in -x11 is a bit strange, but given that AFAIK the UI stuff all requires OpenGL and OpenGL in Fedora requires X11, I don't think we can do any better.)
15:54:35 <rdieter> ok, moving on...
15:54:42 <rdieter> #topic devconf2013 report
15:55:07 <rdieter> so, how was devconf?  i'm very jealous not making the trip this year, want to hear all about it
15:55:54 <Kevin_Kofler> Very interesting conference, though not much KDE-related stuff. Only a 1½ hour session about QML, in which dvratil had the balls to claim that QML would actually IMPROVE performance, something I have a really hard time believing. ;-)
15:56:15 <dvratil> :-D
15:56:26 <Kevin_Kofler> Quite some interesting Base OS talks too.
15:56:46 <Kevin_Kofler> And of course it was nice to meet some people again and some other people for the first time.
15:58:30 <dvratil> it's pitty we didn't have time for some little KDE hackfest this year
15:58:59 <rdieter> next year... :)
15:59:27 * rdieter wants to visit again, a little more confidence about not getting (completely) lost.
15:59:57 <Kevin_Kofler> Yeah, maybe next year we also have some new stuff to give 1 or 2 talks about, with Qt 5 and maybe even KDE Frameworks 5…
16:00:12 <sochotni> FYI Java SIG would like to take over this channel for nefarious purposes :-)
16:00:30 <rdieter> sochotni: ok, we'll wrap up shortly
16:00:57 <rdieter> #topic open discussion
16:00:59 <rdieter> thanks, any final comments before closing the meeting today?
16:02:15 <rdieter> ok then, thanks everyone
16:02:18 <rdieter> #endmeeting