15:00:18 #startmeeting KDE SIG Meeting 15:00:18 Meeting started Tue Jul 30 15:00:18 2013 UTC. The chair is Kevin_Kofler. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:18 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:23 #meetingname kde-sig 15:00:23 The meeting name has been set to 'kde-sig' 15:00:41 #topic Role call 15:00:49 The usual: Who's present? 15:00:52 * nucleo here 15:00:53 here 15:01:50 dvratil, jreznik, than: Ping? Meeting time! 15:01:53 here 15:02:04 here 15:02:20 * ltinkl is here 15:02:23 * jreznik is around 15:02:42 #chair nucleo rdieter than dvratil ltinkl jreznik 15:02:42 Current chairs: Kevin_Kofler dvratil jreznik ltinkl nucleo rdieter than 15:02:57 #info Kevin_Kofler, nucleo, rdieter, than, dvratil, ltinkl, jreznik present. 15:03:03 #topic Agenda 15:03:17 So what's there to discuss? nucleo proposed Qt 4.8.5, which makes sense. 15:03:19 Anything else? 15:03:41 KDE-4.11 status 15:04:24 postgress regession with qt-4.8.5 15:05:45 #topic Qt 4.8.5 15:05:58 Let's start with that, and the PostgreSQL regression is part of that IMHO. 15:05:59 maybe arm as primary 15:06:14 nucleo: We can't really do anything about that, can we? 15:06:20 can't 15:06:23 (It's been forced on us just as on everybody else.) 15:06:47 https://bugreports.qt-project.org/browse/QTBUG-30076 15:06:50 That nonsense is going to make all our builds 3 to 1000 times slower. :-( 15:07:11 the qt-postgresql thing, "PostgreSQL driver inserts extra backslashes on PostgreSQL 9.1 and newer" 15:07:26 this regression breaks Akonadi with postgresql 15:07:37 we are not able to append \SEEN flag 15:07:59 should we just just revert commits to the postgresql driver? 15:08:24 Indeed, I'd suggest just reverting the offending commit. 15:09:04 +1 if we want to push qt-4.8.5 15:10:09 http://paste.fedoraproject.org/29025/96996137 is the one, I think 15:10:09 dvratil: is it a bug in postgresQL? 15:10:23 they've changed behavior 15:11:08 Warning 15:11:09 This change can break applications that are not expecting it and do their own string escaping according to the old rules. 15:11:15 (from postgreq; changelog) 15:11:45 I can try reverting that commit to our qt packaging. 15:12:00 Yes please. 15:12:06 rdieter: great 15:12:08 the question is, does it break the akonadi database? 15:12:18 but what commit? There was no change in Qt that would cause that 15:12:35 it's change in PostgreSQL behavior that just breaks Qt's SQL driver 15:12:46 It's a change in Qt 4.8.5. 15:13:04 dvratil: this one I think, http://paste.fedoraproject.org/29025/96996137 15:13:12 Supposedly made to accomodate a change in PostgreSQL, but the thing is, Akonadi works on F19 with 4.8.4 and not with 4.8.5. 15:13:37 At least that's what users of Akonadi-PostgreSQL told us. 15:13:38 not sure how best to resolve this, long-term though 15:14:09 %if 0%{?fedora} < first version with PostgreSQL ≥ 9.1 15:14:11 apply patch 15:14:15 %endif 15:14:16 ? 15:14:20 s/apply/revert/, sorry. 15:14:33 no need, the patch already only changes escaping when used against newer postgresql 15:14:37 Not sure what the right way to treat 9.1+ is though. 15:14:46 Well, then the patch is just broken. :-) 15:15:20 it's postgresql-9.1+ that changed escaping, this qt commit is supposedly just an adaptation to that change 15:16:13 as I understand things anyway. 15:16:16 But it breaks more than it fixes, it seems. 15:16:20 from Akonadi POV, another possible fix is to modify our default DB config to switch the option back to OFF 15:16:50 (because the change is about enabling standard_conforming_strings option by default since 9.1 15:17:06 so if we explicitly disable it in Akonadi config, Akonadi should be happy 15:17:16 not sure about other apps though 15:18:16 imo, short-term anyway, I will revert the commit for < f20, since it is a regression/change-in-behavior of the postgrsql driver if we update qt-4.8.4 => qt-4.8.5 15:19:09 is that agreeable? 15:19:47 rdieter: +1 15:20:09 oki 15:20:11 alternatively, we could just simply unconditionally revert the commit too 15:20:22 Assuming what users told us is correct (that things work fine with 4.8.4), +1 to reverting the Qt commit. 15:20:59 +1 revert 15:21:53 * dvratil will try to write a correct patch for the driver 15:22:04 (no guarantees though) 15:22:07 ok 15:25:09 #agreed revert the Qt commit for now 15:25:19 #action dvratil will try to write a correct patch for the driver 15:25:48 And I assume we agree to push Qt 4.8.5 to updates-testing as soon as that's resolved / worked around, right? 15:25:55 agreed 15:26:43 Any objections, or can I file an #agreed for that too? 15:27:05 no objection 15:27:32 did anyone have a preference whether to unconditionally revert, or just for < f20 ? 15:27:44 #agreed push Qt 4.8.5 as soon as the PostgreSQL regression is resolved / worked around (by reverting the patch) 15:28:05 I'd just do it unconditionally. 15:28:52 ok. (I can see arguments for both ways) 15:29:01 yes revert it unconditionally before we have a correct fix in drive 15:30:28 * rdieter committed fix to qt.spec, building now 15:30:55 #info rdieter committed a fix (unconditional reversion of the offending patch) to qt.spec, building now 15:31:04 I think that's all for this one, let's move on. 15:31:13 #topic KDE 4.11 status 15:32:54 4.10.97 is mostly in rawhide now, except for new package splits 15:33:28 kdenetwork work-in-progress: http://rdieter.fedorapeople.org/rpms/kdenetwork/ 15:33:53 #info 4.10.97 is mostly in rawhide now, except for new package splits 15:33:59 still todo includes: kdeadmin, kdesdk, kdeutils I think 15:34:07 #info kdenetwork work-in-progress 15:34:11 #link http://rdieter.fedorapeople.org/rpms/kdenetwork/ 15:34:37 rdieter: I think you're right. 15:34:43 #info still todo includes: kdeadmin, kdesdk, kdeutils 15:38:15 The thing is, this is really a blocker for pushing 4.11 anywhere (except Rawhide). 15:38:31 We're missing almost half of the SC now. 15:40:29 isn't kdeutils a meta package? 15:41:01 and it's already splitted in 4.10 15:41:20 oh, right, true 15:41:20 Must be another one then… There were 4 modules split in 4.11. 15:41:53 kdeadmin, kdesdk, kdenetwork 15:42:13 and the last one? 15:42:13 These ones sure, but that's 3, I know there are 4. 15:42:42 kdetoys 15:42:50 nucleo: Thanks. 15:42:52 #undo 15:42:52 Removing item from minutes: 15:42:59 #info still todo includes: kdeadmin, kdesdk, kdetoys 15:43:58 rdieter: i will help to add the missing stuffs 15:44:47 #action than will help adding the missing stuff 15:44:51 i will start to work on this next week 15:45:06 thanks 15:45:07 OK 15:45:14 Thanks +1. :-) 15:45:15 rdieter: np :) 15:45:33 I think that's all about 4.11. 15:45:37 #topic Open discussion 15:45:43 Anything else to discuss? 15:46:03 fyi, f17 going eol today. rest in peace. :) 15:46:31 rdieter: :-) 15:47:13 * Kevin_Kofler upgraded to F18 last weekend (despite the extreme heat). 15:47:42 * rdieter worked with dgilmore yesterday to make sure we had the karma for f17 kde-4.10.5 to get pushed stable first 15:48:06 Did it get actually pushed though? Last I checked it didn't. :-( 15:48:20 Kevin_Kofler: push got killed overnight 15:48:31 its been resumed and will go out soon 15:48:39 * rdieter yays 15:48:40 dgilmore: OK, thanks for the update. 15:49:00 logrotate restarts apache which will kill running pushes 15:50:07 naughty logrotate 15:50:49 (For those non-Europeans in here, when I mean "extreme heat", I mean "above 100°F" kind of extreme. :-) ) 15:52:19 Kevin_Kofler: about 35c is getting hot 15:52:25 above 15:52:39 its only the US that uses F 15:53:21 We had up to 38-39°C in most of Austria. 15:54:09 Still over 30°C in the night when I was forced to the the Fedora upgrade due to impending EOL. But hey, I'm not complaining, it's not really feasible to support releases for ages when one releases every 6 months. 15:54:23 s/to the the/to do the/ 15:55:36 When we're starting to talk about the weather, it's a sign that we're running out of discussion topics. :-) So… 15:55:41 #endmeeting