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