15:10:52 #startmeeting kde-sig -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2011-10-18 15:10:52 Meeting started Tue Oct 18 15:10:52 2011 UTC. The chair is rdieter_laptop. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:10:52 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:10:59 #meetingname kde-sig 15:10:59 The meeting name has been set to 'kde-sig' 15:11:04 #topic roll call 15:11:08 hi, who's all here today? 15:11:09 Present. 15:11:20 * rnovacek is here 15:11:48 * chuckf is here 15:11:48 than : ping 15:11:51 * than is here 15:12:12 #info rdieter Kevin_Kofler rnovacek chuckf than present 15:12:18 chuckf: hi 15:12:30 #topic agenda 15:12:48 no meeting page/agenda prepped ahead-of-time, so what to discuss today? 15:12:58 F16 final polishing (change deadline coming Monday). 15:13:16 apper testing 15:13:34 how is F16 KDE coming along at this point? 15:14:15 rdieter_laptop: security state 15:14:27 rdieter_laptop: on agenda 15:14:32 than: in particular? kdeutils? other? 15:15:16 rdieter_laptop: CVE-2011-3365 in kdelibs/kdelibs3 and CVE-2011-2725 kdeutils 15:15:28 Seeing how Apper is faring so far, I'm not sure it's a good idea to rush it into the F16 release… 15:15:41 And the thing is, I'm not sure whether we can pull it off as a post-release update either… 15:16:05 ok, got those topics tabulated, let's move on 15:16:11 Though it's not really a bigger change than the kde-plasma-networkmanagement nm-compat → nm09 switch we did in F15. 15:16:17 #topic f16 status/polish 15:16:32 So, what exactly is needed here? 15:16:47 I see the kde-settings and kdepim/kdepim-runtime updates are now queued for stable. 15:16:51 in general I think we're in really good shape, no serious issues or blockers remain, that I'm aware of. 15:17:11 A live-kickstarts change is needed to go back to not starting Nepomuk on the live image. 15:17:23 Kevin_Kofler: already done 15:17:28 OK 15:17:38 I'd also like the akonadi change to go back to MySQL as default to go into the release. 15:18:01 (because Akonadi won't switch the backend by default if its default changes after installation) 15:18:05 Kevin_Kofler: why not sqlite? 15:18:15 https://admin.fedoraproject.org/updates/FEDORA-2011-14281 currently in -testing 15:18:33 than: Slower and does not support concurrent access, so everything blocks while using Akonadi with SQLite. 15:19:27 I built an update for kde-plasma-networkmanagement to 0.9 beta1 (= 0.8.80), it now has karma +1 (from a proventester, even) and I queued it to stable. 15:19:32 now that we have good backend switching (per user in kdebase-runtime kcm and globally via site-specific /etc/xdg/akonadi/akonadiserverrc), my objections to switching back to sqlite are withdrawn 15:19:34 Kevin_Kofler: i though it's fixed long time ago 15:20:30 now, when/if we do all ack going back to mysql, I think I would still like to use sqlite on the live image (requiring a minor kickstart modification) 15:20:37 than: AFAIK, they said that SQLite is simply not thread- or concurrency-safe. 15:21:06 rdieter_laptop: But we aren't going to start up Akonadi by default anyway, are we? 15:21:16 rdieter_laptop: +1, mysql on livecd is overkill 15:21:17 so yeah, while sqlite (still) has a lower runtime footprint, it's definitely slower 15:21:41 Kevin_Kofler: sure, but when/if any akonadi-using app is launched (like konversation)... 15:21:57 Konversation triggers firing up Akonadi?! 15:22:20 * Kevin_Kofler starts wondering why we bothered doing all this work to not start it by default if everything requires it anyway. 15:22:23 it hooks into kaddressbook to lookup irc nicks with adressbook entries 15:22:42 I just didn't want akonadi starting on initial login 15:23:01 (IMHO, starting Akonadi and Nepomuk by default is the right thing to do, even on the live image. It's also why I enabled it in spin-kickstarts without a second thought. But then you complained…) 15:23:15 have you actually tried using the livecd? 15:23:28 Not starting Akonadi on login just makes any app using it take longer to start up. :-/ 15:23:33 with both enabled (esp with akonadi/mysql), it was very painfully slow 15:23:41 now, it's quite fast 15:23:55 Kevin_Kofler: true, it's a perception thing 15:24:28 we've discussed it before, ideally, if we could come up with some way of pre-initializing these db's, that would help a bunch too 15:24:43 but that never materialized 15:25:20 The akonadi update https://admin.fedoraproject.org/updates/FEDORA-2011-14281 needs karma in any case. 15:25:44 We will not be able to push it before the change deadline if it doesn't get at least 1 positive karma point. :-( 15:26:05 so, now that we have fairly robust runtime/site switching of akonadi backend, I personally don't have any strong preference either way about default (my site/machines will use sqlite, regardless) 15:26:26 Kevin_Kofler obviously favors mysql, as does upstream. 15:26:32 other opinions? 15:27:07 I guess I'd have to say I still have a slight preference for sqlite, it's smaller and safer for most use-cases. 15:27:37 I'm for sqlite for livecd and mysql otherwise 15:28:00 than: ? 15:28:46 +1 for mysql as upstream does 15:29:04 ok, let's just karma++ what we have, and be done with it. 15:29:27 * rdieter_laptop will make the spin-kickstars mod to use sqlite on kde-live 15:30:03 Karma'd by executive decision and queued for stable. 15:31:00 anything else f16 status/polish -wise? 15:31:11 Another update I'd really like to see in F16 Final is the Qt one: https://admin.fedoraproject.org/updates/FEDORA-2011-14348 15:31:21 * update from a snapshot to an official RC 15:31:33 * fix for building stuff against qlist.h 15:31:36 oh, yeah, meant to mention that one too. 15:31:40 * fix for running Qt under GNOME 15:31:41 lot's of good stuff there. 15:31:57 test/karma please 15:32:11 * fix for leaked FDs when printing (memory/resource leak, plus can trigger SELinux denials if the thing then execs another process). 15:32:24 Kevin_Kofler: +1 15:32:45 i will test it and give karma+ 15:33:02 It has 1 karma, the threshold is set to 2, so it should get one more. (We could lower the threshold to 1, but I'd rather not do that.) 15:34:11 ok, let's move on 15:34:16 What may or may not be fixed is the crash in KWrite settings. 15:34:21 #topic security stuff 15:34:26 (It is reported no longer reproducible.) 15:34:28 than: ? 15:34:57 CVE-2011-3365, input validation failure in KSSL 15:35:24 it's fixed in kdelibs3 for f14/f15/f16/rawhide 15:35:53 woo 15:36:07 rdieter_laptop: is the issue fixed in kdelibs for f16/f15/f14? 15:36:20 rdieter_laptop: i saw it in the changelog 15:36:30 than: f16 yes, f15/f14 still in updates-testing 15:36:37 Fixed upstream for F16/Rawhide, fix backported for F14/F15. 15:36:42 great 15:37:02 * rdieter_laptop saw the kdeutils/ark patches show up in bz today too 15:37:12 i'm working on CVE-2011-2725 15:37:14 And I backported it for kdelibs3, thanks to than for fixing a syntax error (copied and pasted multiple times) and building it. 15:37:19 will finish it today 15:37:37 arg, glibc-2.14.90-12.999 got karma'd to stable updates. :( 15:37:43 means qt will FTBFS now. 15:37:47 Kevin_Kofler: thanks for you patch! 15:37:54 s/you/your 15:38:22 I guess I'll tag an older glibc into f16-override if I have to 15:38:36 rdieter_laptop: Wait, it's still pending… 15:38:46 If we get enough -1 votes, we might overturn it. 15:39:10 ok, didn't know that could happen 15:39:37 * rdieter_laptop is ok with f16-override tagging, the stuff that glibc fixes is nice too 15:39:42 Well, it has +5, I think we need to get it to -3 to get anything to happen, if that works at all. :-( 15:39:59 (It had +6, I voted it down.) 15:40:10 moving on... 15:40:12 #topic apper testing 15:40:31 https://admin.fedoraproject.org/updates/FEDORA-2011-14262 15:40:40 got apper in rawhide and f16-updates-testing. 15:40:56 (It's annoying that testers vote up updates with already reported and -1'd regressions.) 15:41:02 it works fairly ok, but some quirks remain, I'll file some bugs today (for tracking purposes) 15:41:27 installing standalone rpms sometimes crashes apper-sentinel 15:41:34 So what do we do with Apper in F16? 15:41:56 I think rushing it into the release is going to be a bad idea if it has issues remaining, but how nice is pushing it as a post-release update? 15:41:57 I tried to do some updates with apper and it works ok 15:42:12 and today (once) apper notified me of availble updates, but clicking on it's systray icon did nothing (I saw something flash in taskmanager, but it was very fast) 15:42:19 It's not just a name change, they also switched to a new version of the PackageKit Qt bindings and made some UI changes. 15:42:49 so, the basic functionality generally works, I'm ok with working through the growing pains 15:42:53 But then again, as I said in the introduction, we did something similar to kde-plasma-networkmanagement in F15. 15:43:02 dantti was going to test it today and get back to me 15:43:19 (and here too, we might get pressured, I don't know for how long rhughes plans to supports the old PackageKit-Qt 1 bindings) 15:43:43 (They're already gone in upstream PackageKit 0.7.) 15:43:51 (but F16 is still on 0.6, I think) 15:44:07 dantti isn't going to support the older stuff much anymore, we may as well push forward 15:44:25 KPK 0.6.x has been out of support for a while already, really. 15:44:35 What was missing was just a stable release of Apper, and that's there now. 15:44:50 so, test test test. have I mentioned test? 15:45:00 The problem is that we didn't manage to get it tested early, so now F16 is coming and there are issues. :-( 15:45:02 the mustard indicates progress! 15:45:48 yeah, dantti was a little late releasing, and our reviewing it took a little longer than expected... 15:46:25 I'd still propose sticking with it, at least until we find anything blocker-worthy 15:46:51 sorry about the delay with the review, I'm quite busy nowadays 15:47:15 no worries, everyone's busy. 15:47:25 The reviewing wasn't the real delay, getting it packaged and submitted for review in the first place was. (dannti had asked us at least twice to package up snapshots.) 15:47:37 why can't we push it later in f16 update (when it's well tested)? 15:47:52 Kevin_Kofler: really? I asked him about a snapshot, and I thought he said to wait... 15:47:57 oh well, doesn't matter now. 15:47:59 But dannti was too busy to do a release earlier and we were too busy to get this though review earlier. 15:48:27 than: we could I suppose... 15:48:51 I'd rather not though, if we can avoid it. it's much easier to make the switch now than post-release. 15:49:32 * rdieter_laptop wonders, is the kpk -> apper switch release notes worthy? 15:49:45 I'm worried about shipping the release with a broken updater… 15:49:47 rdieter_laptop: yes, but it's little riskant 15:50:07 Kevin_Kofler: updating works 15:51:16 I'd rather base the decision on the results of testing. can we at least try it? 15:51:26 Are we sure it works for everyone? 15:51:35 Things like: 15:51:36 and today (once) apper notified me of availble updates, but clicking on it's systray icon did nothing (I saw something flash in taskmanager, but it was very fast) 15:51:45 don't sound encouraging to me at all. 15:51:55 Kevin_Kofler: easy enough to work around that (e.g. run apper by hand did work) 15:52:01 We don't want our users to not be able to update to a working version. 15:52:18 Kevin_Kofler: +1 15:52:26 when is the change deadline ? 15:52:26 TBH, I think Apper is F17 material. 15:52:32 Monday. 15:53:25 ok, if we don't have confidence by friday, let's revert back to kpk for f16 ga 15:54:31 (what I propose) 15:54:54 anyone else able to help test besides me? 15:56:04 rdieter_laptop: i will test it 15:56:50 (running short on meeting time), is that plan agreeable? 15:57:14 yes 15:57:18 rnovacek: +1 15:57:37 +1 15:57:53 ok, let's give it shot. thanks everyone. 15:57:56 #endmeeting