kde-sig
LOGS
14:04:40 <jreznik> #startmeeting kde-sig -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-11-09
14:04:40 <zodbot> Meeting started Tue Nov  9 14:04:40 2010 UTC.  The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:04:40 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:04:47 <jreznik> #meetingname kde-sig
14:04:47 <zodbot> The meeting name has been set to 'kde-sig'
14:04:56 <jreznik> #topic roll call
14:05:03 <jreznik> who's present today?
14:05:09 * thomasj is present
14:05:15 * nucleo present
14:05:15 <Kevin_Kofler> Present.
14:05:54 * than_ is present
14:06:21 * ltinkl present
14:06:56 <jreznik> #info thomasj nucleo Kevin_Kofler than_ ltinkl jreznik present
14:07:03 <jreznik> rdieter: ping
14:08:09 <jreznik> anything else to discuss?
14:08:41 <jreznik> kde 4.5.3, f13/qt 4.7.1, standalone QtWebKit
14:09:07 <Kevin_Kofler> There's also nucleo's point about the knetworkmanager-* subpackages.
14:09:09 <nucleo> rename knetworkmanager-* plugins to kde-plasma-networkmanagement-* or add them to main package if we have time
14:09:26 <jreznik> ah, sorry - I'll add it
14:10:33 <Kevin_Kofler> Let's start.
14:10:35 <jreznik> seems like rdieter is afk, should we start?
14:10:37 <Kevin_Kofler> We already lost 10 minutes.
14:10:50 <jreznik> #topic kde-4.5.3 status
14:11:08 <jreznik> than_, thomasj...
14:11:15 <thomasj> I'm against a Qt upgrade to 4.7 in F13. Given the last bug in RH BZ, that might/will get us more flames. Plus it will hand FESCo & co. more oil to burn.
14:11:20 <thomasj> whoops, wrong topic
14:11:22 <thomasj> heh
14:11:29 <Kevin_Kofler> Let's discuss 4.5.3 first.
14:11:51 <than_> we don't need to update qt 60 4.7 due webkit issue
14:11:51 <thomasj> 4.5.3 works very well in F14 so far. Only nepomuk service stub is still crashing on any login
14:12:16 <than_> i have working standalone qtwebkit for 4.6.x
14:12:25 <thomasj> than_++
14:12:30 <nucleo> I updated to 4.5.3 from updates-testing, works fine for me
14:12:33 <Kevin_Kofler> Can we discuss 4.5.3 first=
14:12:34 <Kevin_Kofler> ?
14:12:35 <nucleo> on F14
14:12:43 <Kevin_Kofler> Re 4.5.3, please get this out ASAP.
14:12:44 <than_> i have tested it well
14:12:47 <nucleo> *kde-testing
14:12:52 <than_> it works fine
14:13:01 <thomasj> than_, you're legend!
14:13:14 <than_> ok, let start witj 4.5.3 first
14:13:19 <Kevin_Kofler> It also has the fix for the classic menu regression (an issue due to a patch which should have been dropped for 4.5) and one for a Kompare annoyance.
14:13:49 <Kevin_Kofler> (Well, for Kompare, I need to look if I can fix it in a better way, but right now the fix is what I have, I also committed it to upstream trunk and 4.5 and it should fix the annoyance in most cases.)
14:14:26 <thomasj> 4.5.3 in F14, so far, is worth updates-testing, IMHO
14:14:54 <than_> is 4.5.3 already in update-testing?
14:14:59 <thomasj> Nope
14:15:01 <ltinkl> +1 for getting it into updates-testing, no problems here whatsoever
14:15:06 <jreznik> thomasj: only redhat-testing
14:15:11 <thomasj> yes
14:15:23 <than_> we should push 4.5.2 in update-testing ASAP
14:15:37 <thomasj> +1 ASAP
14:15:48 <Kevin_Kofler> +1 (but you mean 4.5.3, not 4.5.2 ;-) )
14:15:52 <rdieter> hi, sorry I was pulled away for a bit
14:15:53 <jreznik> #info ltinkl thomasj and than_ reports 4.5.3 to be ok to push to updates-testing
14:15:54 <than_> is there any dependency issue?
14:16:11 <Kevin_Kofler> IIRC, kde-plasma-yawp may need a rebuild.
14:16:14 <ltinkl> I've heard there was some problem with yawp
14:16:20 <Kevin_Kofler> (new soname for libweatherion)
14:16:21 <thomasj> Is already done AFAIK
14:16:30 <Kevin_Kofler> If that's already done, then push push push! :-)
14:16:33 <thomasj> At least rdieter built it for kde-redhat
14:16:42 <than_> ok, then is time for pushing into update-testing
14:16:53 <rdieter> koji list-tagged dist-f13-kde , koji list-tagged dist-f14-kde
14:17:02 <rdieter> gives the list of stuff to include in the update
14:17:34 <Kevin_Kofler> The stuff also needs to get tagged with koji tag-pkg dist-f14-updates-candidate (resp. f13).
14:17:42 * rdieter is tagging now
14:17:44 <Kevin_Kofler> (but anybody can do that, the updates-candidate tags are not locked)
14:19:56 <jreznik> ok, anything else? seems like we agreed it's time to push it to updates-testing
14:20:36 <rdieter> ok, all tagged.  who wants the task of issuing the updates?
14:21:07 <Kevin_Kofler> I can do it.
14:21:40 <jreznik> #info Kevin_Kofler to prepare update
14:22:07 <rdieter> Kevin_Kofler: thanks
14:22:37 <jreznik> #topic f13/qt 4.7.1
14:23:01 <Kevin_Kofler> I'm for a Qt 4.7.1 update for F13.
14:23:17 <Kevin_Kofler> And I don't give a darn about WebKit, I just want the new Qt. :-)
14:24:25 <thomasj> Kevin_Kofler, then update to F14 :p
14:25:29 <thomasj> A update to Qt-4.7.x in F13 will give us flames to death and will probably kill our reputation with FESCo.
14:25:29 * than_ is for qt-4.6.x for F13, we have now working standalone qtwebkit
14:25:35 <thomasj> So now flame me :D
14:26:08 <Kevin_Kofler> That bug is just one user who doesn't understand Fedora who's ranting.
14:26:09 <rdieter> than_: +1, now that we have a close-to-usable standalone qtwebkit, there's much less case to be made for 4.7.
14:26:13 <Kevin_Kofler> It's not even a valid bug report.
14:26:20 <Kevin_Kofler> We should just close it NOTABUG.
14:26:35 <thomasj> He has a point though.
14:26:36 <Kevin_Kofler> Any idiot can file rants on Bugzilla.
14:26:44 <rdieter> .bug 650993
14:26:46 <zodbot> rdieter: Bug 650993 Warning, Fedora is becoming a "rolling release" - https://bugzilla.redhat.com/show_bug.cgi?id=650993
14:26:47 <rdieter> you talking about ^^
14:26:49 <rdieter> ?
14:26:52 <Kevin_Kofler> Yes.
14:26:55 <thomasj> Yes
14:26:59 <Kevin_Kofler> rdieter: I don't understand why you didn't close that bug.
14:27:00 <jreznik> for me the top reason was qtwebkit and security updates
14:27:11 <Kevin_Kofler> Can I close it?
14:27:11 <jreznik> I believe qt 4.7 should just work
14:27:18 <rdieter> Kevin_Kofler: he did finally post one detailed problem, fwiw.
14:27:27 <rdieter> Kevin_Kofler: please don't
14:27:56 <jreznik> Kevin_Kofler: yep... and the problem should be reported as separate bug
14:27:58 <Kevin_Kofler> Oh, BTW, hint: koji list-tagged --quiet dist-f13-kde | sed 's/ .*$//g' | tr '\n' ' ' | sed 's/ $/\n/g' – gives the updates in Bodhi-friendly format.
14:28:04 <Kevin_Kofler> jreznik: Indeed.
14:28:14 <Kevin_Kofler> Valid issues should be filed as one bug report per issue.
14:28:18 <Kevin_Kofler> A general rant is clearly invalid.
14:28:29 <Kevin_Kofler> Bugzilla is not the forum for discussion about update policies.
14:28:54 <Kevin_Kofler> Catch-all bug reports are also very much useless because you can't track the issues in them.
14:28:54 <jreznik> back to the problem - qt update
14:28:59 <rdieter> Kevin_Kofler: true, if this one bothers you so much, I can remove your CC: on it.  but, I'd rather keep the dialog open for now.
14:29:18 <rdieter> jreznik: so, what do you think wrt qt?
14:29:23 <jreznik> rdieter: I agree with Kevin -> this should go to mailing list, not bugzilla
14:29:48 <Kevin_Kofler> jreznik: Except we already had ML threads and IRC discussions about this.
14:29:55 <Kevin_Kofler> Now that it's pushed it's too late to complain.
14:29:57 <than_> i agree with Kevin too
14:30:36 <than_> it should  belong to ML
14:30:37 <jreznik> rdieter: main reason - qtwebkit should be fixed by standalone package but I believe qt 4.7 should not be a technical problem - it should work and I bet it will work... I'm worried about political one :(
14:31:13 <Kevin_Kofler> jreznik: I'm willing to take up the fight.
14:31:15 <jreznik> Kevin_Kofler: yes, we had - so we should document it clearly and archive for next generations of trolls (and send link later)
14:31:23 <rdieter> jreznik: :)  let's focus on the technical.  if there's a justifiable technical case to be made, the politics can play themselves out
14:31:51 <Kevin_Kofler> It's required by the latest versions of several packages: Qt Creator etc.
14:32:08 <Kevin_Kofler> Also KDE trunk.
14:32:13 <jreznik> rdieter: qt quick support, qt mobile in 4.7, qt creator - it can help mobile phone devels a lot... but it's not related to fedora
14:32:30 <jreznik> Kevin_Kofler: we don't need KDE trunk building on F13
14:32:49 <rdieter> jreznik: though it would be nice
14:32:50 <Kevin_Kofler> Well, I'd want to push 4.6 when it'll be released, but I guess I'm alone there. ;-)
14:33:52 <rdieter> I'm officially torn, but based on the last discussions with FESCo, unless we could make a very strong case, they would likely deny/veto any plans for a f13/qt47.
14:34:25 <Kevin_Kofler> We don't ask them. I just file the update and we try to rush it out as quickly as possible to not give time for objections.
14:34:32 <rdieter> Kevin_Kofler: no
14:34:35 <jreznik> rdieter: I'd like to have update but as you said - it's bull's red flag for FESCo :(
14:34:59 <rdieter> so, is there a case to be made or not?  (and 'added features' doesn't count)
14:35:03 <jreznik> Kevin_Kofler: then we can be banned completely for future updates :( no
14:35:34 <jreznik> rdieter: if we can push standalone qtwebkit I don't see any strong case for update...
14:35:39 <than_> we just follow the rule here
14:35:57 <rdieter> jreznik: I think I agree.
14:36:09 <than_> jreznik: +1
14:36:10 <ltinkl> yup, let's try with the standalone webkit first
14:36:11 <rdieter> so given that, should I submit what I have for qtwebkit, for review?
14:36:21 <rdieter> or has anyone else worked on it more
14:36:23 <rdieter> ?
14:36:27 <jreznik> actually now F13 is Fn-1 and we decided to not touch Fn-1 too much
14:36:30 * Kevin_Kofler wants Qt 4.7 and later KDE 4.6 on F13 etc.
14:36:39 <jreznik> Kevin_Kofler: redhat-kde repo...
14:36:48 <than_> rdieter: yes, please
14:37:00 <rdieter> ok.
14:37:04 <Kevin_Kofler> (And I never liked that "stability proposal" and even less the even stricter Board "vision".)
14:37:14 <than_> rdieter: i have working srpm qtwebkit
14:37:30 <than_> i will send the patch to you
14:37:35 <rdieter> than_: thanks
14:37:38 <rdieter> #action rdieter to submit qtwebkit for pkg review
14:37:43 <Kevin_Kofler> And we had already decided to push Qt 4.7 to F13.
14:37:49 <than_> rdieter:np
14:37:50 <jreznik> Kevin_Kofler: it's not right place to complaint... I agree with some parts of stability proposals but not in the current state...
14:37:50 <thomasj> Kevin_Kofler, and everybody knows that since you wrote it already a billion times..
14:37:52 <Kevin_Kofler> So I think it's bad to backpedal now.
14:38:11 <jreznik> Kevin_Kofler: I'm just worried they ban as completely
14:38:18 <Kevin_Kofler> (I also think we shouldn't have sent that RFC to the devel ML, but just done it.)
14:38:21 <than_> rdieter: it's great if you can upload the standalone qtwebkit to redhat-kde-testing
14:38:24 <jreznik> and they don't like idea of updating Qt...
14:38:40 <Kevin_Kofler> (If you want something done, doing it first and asking for forgival later is always most effective.)
14:38:41 <than_> it's good for people who want to test
14:38:55 <jreznik> hey, let's back to topic
14:38:56 <rdieter> than_: we'll need to adjust qt packaging a bit to accomodate, but sure.
14:39:23 <than_> rdieter: yes, rebuilt our qt with qtwebkit disable
14:39:35 <than_> it's what we need
14:39:36 <Kevin_Kofler> than_: It's not that easy.
14:39:40 <jreznik> or jump to qtwebkit topic - then we can decide qt 4.7 fate
14:39:52 <rdieter> jreznik: +1 !
14:39:55 <Kevin_Kofler> If you disable QtWebKit in the Qt build, you end up with no QHelpSystem and Qt Assistant!
14:39:57 <jreznik> #topic standalone QtWebKit
14:40:05 <than_> Kevin_Kofler: where ist problem
14:40:17 <Kevin_Kofler> Those things require QtWebKit.
14:40:49 <than_> Qt Assistant does't really webkit
14:40:53 <rdieter> Kevin_Kofler: yuck, I'd hoped we could speed our qt builds by not building it, but we may have to do like phonon, and build it, but throw it away and not package the results.
14:41:06 <Kevin_Kofler> Actually QHelpSystem doesn't.
14:41:11 <Kevin_Kofler> But assistant-qt4 does.
14:41:17 <Kevin_Kofler> (That's what ldd tells me.)
14:41:18 <rdieter> (anyway, I'll test all that, of course)
14:41:49 <Kevin_Kofler> than_: Help files are HTML files, it needs a HTML renderer.
14:41:53 <Kevin_Kofler> And it uses QtWebKit for that.
14:41:55 <than_> Kevin_Kofler: it's easy to disable it here
14:42:05 <Kevin_Kofler> The old Assistant used something more primitive, but the new one uses QtWebKit.
14:42:20 <Kevin_Kofler> Maybe you can get it to build without it, but then it won't support CSS or anything.
14:42:27 <Kevin_Kofler> So the current documentation will look like crap.
14:42:28 <rdieter> than_: wouldn't that disable assistant too?  (I think that's the point Kevin_Kofler's making)
14:42:37 <jreznik> rdieter: but that probably means - you build it with old qtwebkit with newer one packaged and as it's still not completely abi/api stable... it could cause problems...
14:42:38 <rdieter> (or it'll be crippled)
14:43:00 <Kevin_Kofler> The reason they're using QtWebKit is because the stuff they used before had only very basic HTML support (subset of HTML 3.2 with no CSS).
14:43:15 <rdieter> jreznik: it's not?  then our issuing a f13/qtwebkit update could be hard too.
14:43:34 <than_> Kevin_Kofler: of course CSS won't work anymore without webkit
14:43:40 <rdieter> (though, we'd have the same problem with any qt-4.7 update as well)
14:43:40 <Kevin_Kofler> And I actually think a standalone QtWebKit update would be more disruptive to a stable release than just pushing Qt 4.7.
14:43:45 <jreznik> rdieter: maybe already it's - should be checked...
14:43:59 <than_> but i will check it
14:44:00 <jreznik> Kevin_Kofler: it's sounds like it
14:44:37 <jreznik> I'd prefer standalone webkit for rawhide only listening to the all issues
14:44:59 <rdieter> ok, first step:  review qtwebkit, adapt for use against qt-4.7 (rawhide)
14:45:18 <rdieter> *then* perhaps work on adapting for qt-4.6, and see how that goes
14:46:00 <rdieter> (all the while, attempting to keep testable stuff in kde-unstable)
14:46:01 <jreznik> rdieter: it opens qt 4.7 update for f13 again...
14:46:14 <rdieter> jreznik: perhaps, we'll see.
14:46:41 <jreznik> but I'd wait till we have it in Rawhide
14:46:41 <rdieter> but it seems qtwebkit is a prerequisite moving forward
14:46:46 <rdieter> right
14:46:50 <Kevin_Kofler> Though I guess technically it would probably be possible to rm -rf the bundled QtWebKit, cp -pr in an updated one and build that stuff.
14:47:11 <Kevin_Kofler> (but whether that works properly is another question)
14:47:16 <jreznik> I'd really like to see newer QtWebKit in our products as we try to care about security
14:47:26 <than_> Kevin_Kofler: it works
14:48:10 <than_> of course, but with more works
14:48:47 <than_> but as i said before i will check the dep in assistant
14:49:06 <than_> if we can drop webkit here
14:49:55 <jreznik> seems like we have a few issues that has to be checked before we can decide both qtwebkit build and qt 4.7 update -> move it ML and move on last topic as we're running out of time
14:50:33 <rdieter> move_on++
14:50:49 <jreznik> #info than to look on assistant dep
14:51:08 <jreznik> #info we have a few issues that has to be checked before we can decide both qtwebkit build and qt 4.7 update -> move it to ML
14:51:23 <jreznik> #topic rename knetworkmanager-* plugins to kde-plasma-networkmanagement-*
14:51:31 <nucleo> I noticed that knetworkmanager-openvpn, -pptp and -vpnc are missing in comps and I have added them to comps-f15.xml.in for now. But we don't have knetworkmanager so may be it is needed to rename plugins to kde-plasma-networkmanagement-* (and may be knetworkmanager-libs?). Other solution is to add plugins in main kde-plasma-networkmanagement package and drop openvpn, vpnc and pptp dependencies
14:51:59 <nucleo> or may be drop not all of dependencies
14:52:01 <Kevin_Kofler> I'd suggest renaming them.
14:52:15 <Kevin_Kofler> It's the path of shortest resistance.
14:52:27 <rdieter> Kevin_Kofler: more I think about it, that makes the most sense
14:53:06 <rdieter> (though it pains me to have pkgs with names so long... kde-plasma-networkmanagement-openvpn )
14:53:20 <rdieter> but I guess there's no way around htat
14:53:21 <rdieter> that
14:53:52 <jreznik> rename, it do not belong to main package (especially with dropped deps)
14:54:53 <nucleo> may be knetworkmanager-libs should be renamed too?
14:55:44 <rdieter> nucleo: yes
14:56:59 <rdieter> #agreed will rename s/knetworkmanager/kde-plasma-networkmanagement/  where needed
14:57:24 <rdieter> I can work on it, unless someone else has an itch?
14:58:25 <nucleo> I can try but may be need help with obsolete/provides
14:59:05 <jreznik> one heretic idea - do we really need -plasma- in name? kde-networkmanagement would be shorter and with changes plasma -> knm -> plasma or somehow like it...
14:59:29 <than_> rdieter: new qtwebkit srpm  is in http://than.fedorapeople.org/
14:59:51 <rdieter> jreznik: maybe
15:00:04 <jreznik> it's a core part for us now...
15:00:17 <rdieter> jreznik: or even just, plasma-  (no kde-)   :)
15:00:29 <than_> rdieter: please use this srpm for review
15:00:44 <jreznik> rdieter: but that means rename other plasma packages...
15:00:47 <rdieter> jreznik: let's continue naming standards after meeting (onlist whatever)
15:00:58 <jreznik> we're out of time now... let's continue later...
15:01:06 <rdieter> jreznik: other plasma packages are using kde-plasma, so you're suggestion changes things too. :)
15:01:18 <jreznik> #endmeeting