15:09:53 #startmeeting kde-sig 15:09:53 Meeting started Tue Nov 12 15:09:53 2013 UTC. The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:09:53 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:09:57 #meetingname kde-sig 15:09:57 The meeting name has been set to 'kde-sig' 15:10:04 hola everyone 15:10:08 #topic roll call 15:10:11 hi 15:10:24 Present. 15:11:49 than, dvratil, mbriza, kde*foo : ping 15:11:59 hi 15:14:22 #info jgrulich Kevin_Kofler dvratil rdieter present 15:14:27 #chair jgrulich Kevin_Kofler dvratil 15:14:27 Current chairs: Kevin_Kofler dvratil jgrulich rdieter 15:14:33 #topic agenda 15:14:48 what to discuss today? I can do kde-4.11.3 status 15:15:09 4.12 Beta? 15:16:36 alright, sounds like a good start. 15:16:40 #topic kde-4.11.3 status 15:17:01 pinged folks earlier in #fedora-kde and went ahead and queue'd what we had in -testing for stable updates 15:17:36 Good. 15:17:49 on related topic, phonon-4.7 stuff had a few wrinkles ironed out, submitted fresh builds for -testing earlier today 15:19:25 that's all I have on that 15:19:46 And KDevelop 4.5.2 is now queued for stable. 15:21:07 alrighty moving on .. 15:21:13 #topic kde 4.12 beta 15:21:16 Kevin_Kofler: ? 15:22:00 So, that thing has been released for a while, shouldn't we try to get it into Rawhide? 15:22:48 It's going to be hard to get 4.12 ready if we don't take advantage of the betas to do the usual packaging changes, review requests if any, etc. 15:22:50 it's probably more a matter of finding someone (or someones) with time to do it 15:24:36 Yeah. I used to do some of those updates in the past, but I'm not really in touch with the current processes now that we need to work with scripts etc. 15:24:51 personally, i may have time tomorrow (slight), or this weekend 15:24:51 (No, I'm not going to bump the hundreds of packages by hand.) 15:25:34 I can help if you need someone to look at individual packages (fixing builds, rebasing patches etc.). 15:25:40 i have a helper build-it.sh script, where you can just do: ./build-it.sh 15:26:03 that does the basic updating, sans patch management/rebasing 15:26:15 That helps when everything goes fine, yeah… :-) 15:26:30 ok, let's see how tomorrow goes (for me), else weekend it is 15:26:36 It's still a pain when there is anything that needs fixing, but I doubt we can make that any easier. 15:26:57 15:27:14 only minor gotcha is to find/fix any assumptions where kde version = kde-workspace version 15:27:23 since that will on longer be true 15:27:36 Yeah, upstream is really doing everything they can to make packaging a PITA. 15:27:53 First the split tarballs and now that. 15:29:21 ok, well, anything on 4.12 ? 15:29:40 anything else, that is 15:29:53 * jreznik is listening 15:29:57 I think pretty much everything that links to anything from kde-workspace (and maybe even some stuff that doesn't ;-) ) has a versioned BR kde-workspace >= %{version} and possibly also a versioned runtime Requires. 15:30:26 These all need to be fixed (I guess BR kde-workspace >= 4.11 and Requires >= the version detected at runtime). 15:31:01 (detected at build time, I mean) 15:31:10 yeah, for the latter I was thinking of putting in a _kde4_workspace_version macro somewhere 15:31:48 In the Frameworks world, we'll need to cope with EVERYTHING having a separate version, like in GNOME. THAT will be a PITA. 15:32:08 Some developers have admitted the workspace thing is a way to force us to get used to that nonsense. 15:32:32 So we'll need _*_version macros for every package? 15:32:34 heh :( 15:32:54 Or we just do what most packages do and ignore the runtime >= constraint, just desupporting selective upgrades. 15:33:07 if that is so, I guess we could whack them will clue sticks as retribution 15:33:23 s/will/with/ 15:33:36 Kevin_Kofler: yeah 15:33:37 We should try again to get them to use symbol versioning. 15:34:25 Even if they don't actually use the versioning the intended way (as versioning with different version supported), just the fact to ASSIGN a version (which could even be automatically copied from the @since annotations) to every symbol would solve the problem for us. 15:34:38 15:34:43 (because RPM then adds dependencies on the library name + symbol version (ignoring the symbol name).) 15:34:49 even that would be an improvement over the status quo 15:35:11 And using symbol versioning that way would not change anything for the targets that don't support it. 15:35:31 We should try to sell that to them for the new KF5 world. 15:35:48 I've been tempted to implement something like that downstream, but big downside is that it means we are now abi-incompatible with everyone else 15:36:02 I guess I'll try to write something up (nag me if I forget), but maybe somebody ELSE should send it, given how "popular" I am on mailing lists. ;-( 15:37:12 * rdieter has no idea what you're talking about, your rock star status is untouchable :) 15:38:06 I think a good idea would be recepted, regardless of who it comes from 15:38:40 I think if you sign on that proposal, that'll help though. :-) 15:38:46 But first we need to write it up. 15:39:16 ok, definitely count me in 15:39:34 We'd sign our names then, and I hope we'll get support from other RPM-based distros, and maybe deb ones too if that also helps dpkg. 15:39:50 we could spin it like... if you're screwing us with inconsistent versioning, at least do this to minimize the damage... kind of thing 15:41:04 Yes, but rather worded like "Because the Frameworks will by their nature have separate version numbers, this becomes important. In the past, we used the following approach: … but now that will not scale anymore." 15:41:07 :-) 15:41:08 debian ... not sure, they already track symbol versions themselves in many places, but I doubt this will hurt things from their perspective 15:41:44 Kevin_Kofler: your wording sounds much better 15:42:01 I can sound diplomatic when I'm not too angry. ;-) 15:42:12 heh 15:42:40 when you're tempted to use words like crappy and braindead, you know the line has probably been crossed. :) 15:42:51 ^^ 15:43:16 So I should rather use words like sh…y and f…king? ;-) 15:43:50 har, anyway, anything else on the 4.12 topic? 15:44:04 Speaking of betas, there's also a KDevelop 4.6 beta. 15:45:07 #topic open discussion 15:45:27 and... I just queue'd a fresh batch of qt5 5.2.0 beta builds for f20-testing 15:45:38 So one more thing: Do we really want KMix to give noisy volume feedback by default? 15:45:47 these, in particular (re)set qreal on arm to be double (intead of float) 15:46:10 I'm a bit torn, I see why setting the volume is the one place making noise is justified, but I'm also not sure our users will like the noise. 15:46:18 Kevin_Kofler: i'm biased toward yes 15:46:39 esp after a bit of feedback on test day 15:46:41 Re qreal on ARM, yay, finally! 15:47:30 That will allow us to stop worrying about ARM-only issues in the Qt 5 future. 15:48:12 fortunately, not much stuff is built against qt5 yet, so the abi break is relatively easy to deal with 15:48:23 Having a typedef that is always double except on one platform where it is float was a constant source of trouble. 15:49:49 it was a bit interesting fixing some of the code that assumed qreal = double 15:50:05 for various definitions of "interesting" 15:50:28 too bad we can't fix qt4 the same way. :-/ 15:50:52 (though most of the issues there have been fixed already) 15:52:34 Well, I guess we could, if we ignore ABI compatibility with other distros and the LSB, and do a mass rebuild after that. :-) 15:53:00 But I don't think it's a good idea. 15:54:26 Qt 5 is the right time to do it. 15:54:31 * rdieter will close meeting in 2 min, if there's nothing else to discuss 15:56:38 thanks everyone! 15:56:41 #endmeeting