15:06:34 #startmeeting kde-sig -- http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2011-03-15 15:06:34 Meeting started Tue Mar 15 15:06:34 2011 UTC. The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:06:34 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:06:38 #meetingname kde-sig 15:06:38 The meeting name has been set to 'kde-sig' 15:06:45 #topic roll call 15:06:49 who's present today? 15:07:33 Present. 15:07:47 than, jreznik, SMParris1, kde*foo : ping 15:08:11 * thomasj is here 15:08:13 * jreznik is here, sorry 15:08:22 (ah everybody is late) 15:08:47 * than present 15:09:06 #info rdieter Kevin_Kofler thomasj jreznik than present 15:09:15 #topic agenda 15:09:34 not much for our agenda today, just a bug review for gpsd dep in kdebase-workspace 15:09:46 I can give a status report for f14/kde-4.6 15:09:51 * Kevin_Kofler had a meeting that just finished at the university. 15:09:52 anything else? 15:09:57 please add kde-4.61 for f14 15:10:23 The NM chaos maybe? 15:10:44 Though I'm not sure there's much to add from our side… 15:10:47 Kevin_Kofler: there's no news, not sure there's any point in rehashing it more 15:10:55 at this point 15:11:14 but we can discuss it at the end, if anyone has more comments 15:11:35 but we should have plan - I'm not sure we can win here 15:12:54 I don't see ltinkl, he knows best about how this would affect solid 15:13:21 anyway, let's get started 15:13:26 #topic kde-4.6.x for f14 15:13:53 quick status update: I've got builds up through kdepimlibs done in dist-f14-kde target 15:14:08 so far. I'll pick up from there, in my free time today. 15:14:19 Unfortunately, yet another regression popped up, in PyKDE4. :-( 15:14:36 Kevin_Kofler: bugzilla? 15:14:57 rdieter: do you need help? I know I promised it yesterday :) 15:15:03 than: https://bugzilla.redhat.com/show_bug.cgi?id=684419 15:15:20 jreznik: sure, thanks! 15:15:35 rdieter: please ping us if you need help 15:15:45 #info rdieter has kde-4.6.x stack up through kdepimlibs built for dist-f14-kde target 15:15:56 We also still haven't decided what to do about the Konsole issue: do we revert the change which disables tab closing? 15:16:22 Some people say it's a bugfix, others say it's a regression. 15:16:43 It's really some of both. :-( 15:17:20 -0.5 for konsole revert, I think the bug impact is worse than the perception of a regression. 15:18:26 jreznik, than : it'll likely be another 2-3 hrs before I'll have a chance to look at it, so if either of you want to jump in to do git merging and submit builds before then, much appreciated 15:19:00 rdieter: ok i will take care of it 15:19:15 rdieter: ok 15:19:37 .bug 657002 15:19:39 than: you or me? to not play on one small playground :) 15:19:40 rdieter: Bug 657002 kde-4.6 tracker - https://bugzilla.redhat.com/show_bug.cgi?id=657002 15:19:43 fyi too, our kde-4.6 tracker bug 15:19:44 There's going to be more than the usual kde* stack to build: rebuilds for the new sip and new kdevplatform/kdevelop. 15:20:06 FWIW, we could push KDevelop first (it needs only 4.5.2 or something), but at this point it's not worth it anymore. 15:20:11 Kevin_Kofler: we need to a list of such packages 15:20:21 yep, I've got all those in kde-testing currently. I'll help compose the list after meeting 15:21:01 rdieter: please send us the list 15:21:21 and rebuilds wrt kdegraphics soname bumps => digikam, kipi-plugins, and ... koffice(krita) too I think 15:21:42 secretly waiting to do digikam-1.9/kipi-plugins-1.9 updates for that 15:22:08 #chair Kevin_Kofler than jreznik thomasj 15:22:08 Current chairs: Kevin_Kofler jreznik rdieter than thomasj 15:22:22 have to go afk for a few minutes, brb 15:23:34 perfect time to grab a coffee meanwhile :) 15:25:20 ok, anything else wrt kde-4.6.x/f14 ? 15:26:29 next topic please 15:26:30 #topic kdebase-workspace requires gpsd -- https://bugzilla.redhat.com/show_bug.cgi?id=684476 15:26:38 .bug 684476 15:26:40 rdieter: Bug 684476 kdebase-workspace requires gpsd - https://bugzilla.redhat.com/show_bug.cgi?id=684476 15:27:21 cwickert asked us to look at this, looks doable, but I'm not sure if the minimal savings are worth splitting out plasma-geolocation 15:28:28 cwickert: Any comments? 15:28:29 gpsd is a small package... it makes sense not to have gpsd if you dont' have gps but we're not gentoo... 15:28:38 i don't see the need to split it 15:28:40 otoh, I'm not sure if geolocation support is useful for most users 15:29:30 so, consider me officially torn and on the fence on this one. +0 15:29:30 I'm going to try to stay neutral because I promised to cwickert that I'll put this up in the meeting, but you know what I think of such subpackages. ;-) 15:30:46 gpsd is about 630k 15:30:50 rdieter: question is - is it just gps geolocation or it supports ip location etc... one of my students has been working on geolocation service and I think it supports both 15:31:18 jreznik: that's two different plasmoids 15:31:29 one for IP, one for gps 15:31:33 It's 2 different dataengines. 15:31:37 ok 15:31:44 The plasmoid(s) using them are the same, I suppose. 15:31:49 I wasn't sure, just raised concern 15:32:03 plasma-geolocation-ip vs plasma-geolocation-gps 15:32:59 sounds like than is -1, how about jreznik, rnovacek ? 15:33:27 -1 I think it doesn't worth the work 15:34:00 I'm going to say 0, I'm not going to stop people from doing the split if they really think it's useful, but I don't see a concrete need given the small size of gpsd+deps. 15:34:39 cwickert: any other reason to split it (I don't count need for people without gps) 15:34:40 (And also given that it's not unusual for hardware support packages to get installed even on machines which don't have such hardware due to deps.) 15:38:32 #info tentative rejection (wontfix) of bug #684476 , pending any new information or feedback 15:38:48 #topic open discussion 15:38:51 jreznik: no other reason except it is stupid IMHO 15:38:58 With update to 4.6 lost and found menu appeared in kickoff. Maybe remove somehow Nepomuk..controller from there? 15:39:23 nucleo: ah, file a bug please 15:39:43 in kde on redhat? 15:39:58 againast nepomukcontroller, we need to fix it's .desktop Categories 15:40:17 blocking 657002 15:40:21 bug please 15:40:21 Right. 15:40:31 nucleo: rh bz 15:40:46 FYI, these are now filed for GTK+ 3 support: 15:40:53 kcm-gtk: https://bugs.launchpad.net/ubuntu/+source/kcm-gtk/+bug/734979 (thanks rdieter) 15:41:02 krdb: https://bugs.kde.org/show_bug.cgi?id=268567 15:41:22 * rdieter sees pre-upgrade showing in Lost&Found on f15alpha box too. 15:41:22 No idea when or if anybody upstream will act on it. Maybe we should consider sending patches. 15:41:53 rdieter: Ugh, file a bug against preupgrade, too… 15:42:08 Kevin_Kofler: shouldn't be too hard to grok the new gtk3 conf format, and write it out 15:42:19 hugo told that no plans yet for making oxygen-gtk3 release 15:42:42 but I wonder if the kcm-gtk gui should have separate dialog for gtk2/gtk3 15:43:04 (esp since there are so few gtk3 themes atm, much less common gtk2/gtk3 ones) 15:43:05 It should have a separate theme selection. 15:44:55 As jreznik hinted earlier, there's value in coming up with a contingency plan for f15/nm-0.9 15:45:02 any news on the NM 0.9 cause? :) 15:45:19 ltinkl: we have to wait for fesco meeting 15:45:24 I don't think it's our job to have a contingency plan. 15:45:29 We aren't the ones breaking stuff. 15:45:31 jreznik: which is? 15:45:39 but I'm not sure we can win this battle... 15:45:40 We shouldn't be too flexible there. 15:46:03 Kevin_Kofler: but what can we do - it's network or no network... 15:46:17 No, it's broken deps => spin not composable => release blocker. 15:46:29 They cannot release with NM 0.9. 15:47:03 Kevin_Kofler: so we will end without release... 15:47:07 that's borderline absurd, fesco could very well decide to go forward, and that means just dropping plasma-networkmanagement 15:47:28 which would be very unfortunate, but not the end of the world 15:47:28 for me it's a clear blocker as well, dunno what else could be 15:47:39 and THEY are the ones thah have to fix it 15:47:47 .bug 687869 15:47:49 nucleo: Bug 687869 'Nepomuk file indexing controller' in 'lost and found' menu - https://bugzilla.redhat.com/show_bug.cgi?id=687869 15:47:52 ltinkl: +1 15:48:24 We aren't the ones making incompatible changes post-freeze here. 15:49:03 I thought someone submitted a NetworkManager08 package. 15:49:13 having said that, I do welcome the changes NM 0.9 introduces 15:49:15 tibbs: they did, but it Conflicts: NetworkManager 15:49:32 The NetworkManager08 solution means you can't install KDE and GNOME at once. 15:49:38 And not even just the workspace! 15:49:45 tibbs: it would mean you couldn't eg. install KDE and Gnome on one machine 15:49:48 Even kdebase-runtime and pidgin would conflict, for example. 15:50:11 we don't know yet how bad solid is affected by nm-0.9 necessarily, do we? 15:50:15 (because solid-networkstatus would be built against 0.8 to be compatible with kde-plasma-networkmanagement and Pidgin against 0.9) 15:50:30 I thought the primary impact was using plasma-networkmanagement vs nm-applet? 15:50:34 rdieter: We can't build kdebase-runtime against 0.9 if we require 0.8 in the workspace. 15:51:05 yup, and that would mean dropping kde-plasma-networkmanagement 15:51:15 maybe compat 08 package could help - rename all conflicting files and dbus services with 08 suffix... than easy patch should do the job... but probably two nms on one machine could be disaster too 15:51:17 I wasn't aware it would conflict. That does kind of render it pointless. 15:51:28 FWIW, solid-networkstatus would be fairly easy to fix, kde-plasma-networkmanagement isn't. 15:51:39 Kevin_Kofler: yep 15:51:40 You can't have 2 NMs at once. 15:52:00 You could make them parallel-installable, but only one would actually be working, so… :-/ 15:52:26 You'd have to chkconfig (or whatever it's called in systemd) stuff whenever you want to boot into a different DE, and the network status checks will likely be non-functional. 15:52:26 Kevin_Kofler: there's no system connections support in current plasmoid - so it's not easy to port it 15:52:43 jreznik: Yes, that's the problem. 15:52:44 and I saw nm-applet patch for 0.9 and it's a huge one (but not very complicated) 15:52:55 but without system connections, we're completely screwed 15:52:58 would it really be the end of the world if plasma-networkmanagement weren't used (by default) for one release? 15:53:05 There's supposedly a system connection support patch from Pardus, has anybody looked at that? 15:53:08 so the only one option is to nm-applet... 15:53:11 rdieter: Yes. 15:53:20 * rdieter doesn't think so 15:53:27 And it's not just a matter at default, it wouldn't be shippable at all! 15:53:29 Kevin_Kofler: someone commented that Pardus does not use NM... but nobody was sure 15:53:52 jreznik: I think they use wicd 15:54:08 jreznik: I tried to find it.. no success, navigating their (mostly Turkish) website doesn't help much 15:54:40 rdieter: I think so... and it can be used by plasmoid - so probably some people just thought it supports nm system connections... 15:55:05 as I said - I see only obsolete nm-applet as possibility 15:55:14 we shipped fedora-kde using nm-applet before, we could do it again. 15:55:29 (I'm sure nobody is going to work on nm-applet once there's gnome-shell one) 15:55:39 rdieter: Pardus doesn't use wicd, at least not that I'd know of. It used to use its own network manager, no idea what they use now. 15:55:49 jreznik: other spins need it too, not just us 15:56:04 http://www.pardus.org.tr/eng/projects/network-manager/index.html 15:56:11 rdieter: it's just dirty solution and nm-applet is really one of the worst UIs ever designed - next one is current plasmoid :D 15:56:21 Yeah, they still have their own network manager. 15:56:29 So their code is probably not of any use for us. :-( 15:56:33 nice namespace collision there 15:56:48 rdieter: other spins need it too but you know, it's gnome and no one... so other spins probably will need an own solution soon 15:57:25 rdieter: Why I think shipping nm-applet as the only solution (as I said, it's not just a matter of "default") is not acceptable: 15:57:34 fwiw, I've been testing the latest nm-applet from koji 15:57:38 * It's GTK+ 3. We don't have theming support for GTK+ 3 yet. It'll look like crap. 15:57:49 * It uses gnome-keyring, which sucks in KDE. 15:58:01 (It also doesn't support things like passwordless wallets etc.) 15:58:29 the default gtk3 theme is relatively small, we can add it 15:58:42 rdieter: We don't have a good way to set it as the default for the user, either. 15:58:47 gnome-keyring just needs a small patch on f15, and it works (as well as it can on != gnome) 15:58:57 Plus, it'll still look bad because it's very different from Oxygen or the Plasma theme. 15:59:27 We'd also deviate from upstream and all other distros by not shipping the proper KDE solution. 15:59:32 looking different and working is far from a release blocker 15:59:44 We shouldn't be too flexible there! 15:59:55 It's not our job to work with people who break freeze policies. 16:00:01 We need to get the policies enforced. 16:00:02 I'm not saying it's an awesome option, but please don't deny that it exists. 16:00:06 Not use ugly workarounds. 16:00:15 We shouldn't even put this on the table. 16:00:17 it's a step back at this point 16:00:21 You already said too much! 16:00:24 ltinkl: +1 16:00:55 ok, looks like our meeting time is up anyway. 16:01:04 well previously I was against shipping the plasma applet because it was broken 16:01:16 but now the situation is very different 16:01:41 I would say - no rules for gnome guys, no rules apply anymore for us... it's an easy solution 16:01:48 yup, let's continue in #fedora-kde 16:02:07 #endmeeting