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