15:01:23 <jreznik> #startmeeting kde-sig -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2011-05-03
15:01:23 <zodbot> Meeting started Tue May  3 15:01:23 2011 UTC.  The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:23 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:40 <tertl3> hello
15:02:38 * Kevin_Kofler added Fedora 15 status as the first agenda item.
15:02:42 <jreznik> #meetingname kde-sig
15:02:42 <zodbot> The meeting name has been set to 'kde-sig'
15:02:48 <Kevin_Kofler> It's certainly the most important thing to discuss right now.
15:02:51 <jreznik> #topic roll call
15:02:55 * ltinkl is here
15:02:56 <Kevin_Kofler> Present.
15:03:01 <jreznik> hi, who's present today?
15:03:09 * rnovacek is here too
15:03:11 <rdieter> here
15:03:12 * jreznik is present obviously
15:03:19 <than> here
15:03:26 <jreznik> Kevin_Kofler: good idead - F15 status
15:03:30 * nucleo here
15:03:44 <jreznik> #chair ltinkl Kevin_Kofler rnovacek rdieter than nucleo jreznik
15:03:44 <zodbot> Current chairs: Kevin_Kofler jreznik ltinkl nucleo rdieter rnovacek than
15:04:10 <jreznik> #info ltinkl Kevin_Kofler rnovacek rdieter than nucleo jreznik present
15:04:50 <jreznik> #topic agenda
15:05:00 <jreznik> anything else to be added to agenda?
15:05:26 <than> jreznik:  4.6.3 status
15:05:59 <nucleo> Administration menu now looks as "System settings" and it not translated in other languages
15:06:31 <ltinkl> 4.6.3 should be out tomorrow
15:06:35 <jreznik> nucleo: bug?
15:06:40 <jreznik> ok, let's start
15:06:49 <jreznik> #topic Fedora 15 status
15:06:52 <nucleo> jreznik: I dpn't know where this bug
15:06:55 <jreznik> aka hot topic
15:07:49 <Kevin_Kofler> So the F15 change deadline is very soon.
15:08:13 <Kevin_Kofler> I've done some kde-plasma-networkmanagement testing, basically we should be good to go.
15:08:39 <ltinkl> yup me too, works fine except the dreaded vpn
15:08:50 <Kevin_Kofler> Right, https://bugzilla.redhat.com/show_bug.cgi?id=699786 is the only point of worry.
15:09:03 <ltinkl> the VPN connections at least show up but they can't be activated
15:09:18 * jreznik tried to poke jklimes, he said, he take a look but has other work too, so...
15:09:22 <Kevin_Kofler> It was decided in the blocker meeting that this is not a blocker, in fact they don't even want it as a freeze override.
15:09:42 <Kevin_Kofler> So if we can't get this sorted out by the change deadline, it'll have to go out as a 0-day update.
15:09:45 <ltinkl> worse yet, dbcw doesn't seem to care at all about this bug
15:09:58 <Kevin_Kofler> (or later update, but that'd suck :-( )
15:10:19 <Kevin_Kofler> Indeed, there has been no movement on fixing this, which is what annoys me the most.
15:11:08 <Kevin_Kofler> I get the feeling that this whole compat API hack was just a way to stop opposition to the late incompatible NM changes and now they aren't doing ANYTHING to maintain it.
15:11:15 * rdieter regrets a bit not fighting a bit harder against nm-0.9
15:11:20 <Kevin_Kofler> Not even fixing bugs.
15:11:23 <Kevin_Kofler> rdieter: Same here.
15:11:53 <Kevin_Kofler> kde-plasma-networkmanagement upstream is also getting new features, which dcbw has no plans to implement in the compat API.
15:11:57 <ltinkl> yup, got the same impression
15:11:59 <jreznik> rdieter: yep... and maybe not fighting against it but more fighting to have compat code working or to invest the time to port knm to 0.9
15:12:15 <Kevin_Kofler> We already can't use the current snapshot, at least not without hiding/disabling parts of its features.
15:12:27 <ltinkl> that will only get worse over the time
15:12:43 <jreznik> they are talking about nm 0.9 and opensuse factory, I recommend them staying with 0.8 as they can (and break g-s)
15:12:47 <Kevin_Kofler> The compat API doesn't support system settings (which is particularly stupid because that's a required step to getting the port to 0.9 running).
15:13:38 <jreznik> #info F15 deadline is very soon
15:13:43 <rdieter> so, what do we do about it?  1.  nothing, aka status quo  2.  other?
15:14:03 <Kevin_Kofler> At this stage, we can't do much other than "1. nothing".
15:14:05 * rdieter dares suggest considering an option 2:  use nm-applet
15:14:22 <jreznik> #info kde-plasma-nm is in a relatively good shape except VPN support (https://bugzilla.redhat.com/show_bug.cgi?id=699786)
15:14:48 * rdieter suspects our "how to use nm-applet instead of knm" wiki page hits are going to go up otherwise
15:15:09 <jreznik> rdieter: for VPN support so we have to document it in known issue
15:15:10 <jreznik> s
15:15:23 <Kevin_Kofler> jreznik: Yes, document VPN trouble in known issues.
15:15:32 <than> jreznik: +1
15:15:34 <Kevin_Kofler> Hopefully we can get it fixed in an update ASAP.
15:15:41 <Kevin_Kofler> But it should be documented in any case.
15:16:02 <ltinkl> yup, with more pressure on dbcw to fix the VPN issue
15:16:09 <jreznik> #info nm-compat issues - not everything is implemented there, we have to hide some features in current snapshots (or use older ones + backport)
15:16:15 <Kevin_Kofler> -1 to nm-applet. Too late for such a change, and it's the best way to ensure we'll never get native KDE NM support working, not now, not in F16.
15:16:17 * apodtele wonders if VPN is more common than dual monitors
15:16:35 <Kevin_Kofler> Last time we used that workaround, it took us many releases to get rid of it.
15:16:36 <jreznik> ltinkl: can you try to poke him, I tried jklimes but ...
15:16:46 <jreznik> Kevin_Kofler: +1 for -1
15:16:47 <ltinkl> jreznik: ye
15:16:59 <Kevin_Kofler> Also because there kept being objections "but nm-applets supports XYZ, current KNM doesn't", with ever-changing XYZ.
15:17:03 <jreznik> apodtele: it is
15:17:59 <rdieter> Kevin_Kofler: that's why I think knm is a losing game, *unless* we can ever find someone (us or others) to help maintain it properly
15:18:16 <rdieter> as it is, it's largely only barely supported and maintained
15:18:21 * than uses command line to activate VPN
15:19:20 <Kevin_Kofler> Anything else about F15?
15:19:29 <Kevin_Kofler> Is nucleo's menu issue a change in F15?
15:19:47 <nucleo> .bug 701693
15:19:49 <zodbot> nucleo: Bug 701693 "Administration" menu item is shown as "System Settings" - https://bugzilla.redhat.com/show_bug.cgi?id=701693
15:19:55 <mcepl> than: cannot resist ... situation on Gnome is not that much better ... openswan is still CLI only :(
15:19:59 * mcepl runs away
15:20:02 <jreznik> rdieter: it's up to us probably as we don't have any possibility... nm-applet is going to die I expect...
15:20:15 <Kevin_Kofler> I'm also seeing "System Settings" on F15 nightlies, I have Administration on F14 (at least the de_AT translation is Administration, I don't know what the original en_US is).
15:20:31 <jreznik> mcepl: yep, I heard Gnome upstream is not happy with current NM-shell state
15:20:32 <rdieter> jreznik: part of the 'nm-0.9' debate was that nm-applet wasn't going anywhere
15:20:40 <Kevin_Kofler> jreznik: Xfce and LXDE need some kind of applet.
15:20:42 <apodtele> a well documented workaround from -than- is better than nm-applet
15:21:02 <jreznik> rdieter: but do you believe it with desktop guys working on it without use in their desktop?
15:21:31 <rdieter> jreznik: you do have a point there
15:22:00 <Kevin_Kofler> I expect it to get maintained by Xfce/LXDE folks eventually, but not necessarily more actively than the KDE stuff.
15:22:26 <Kevin_Kofler> GNOME is going to stop caring about it soon.
15:22:27 <jreznik> actually knm is quite a well maitained now - lamarque is working really hard
15:22:39 <ltinkl> ...and he will stop as he got a new job
15:22:47 <ltinkl> as he just announced yesterday
15:22:53 <jreznik> ltinkl: ay
15:22:53 <Kevin_Kofler> There's already talk about getting rid of fallback mode in favor of gnome-shell on LLVM Gallium/Mesa software rendering.
15:23:09 <jreznik> Kevin_Kofler: makes sense
15:23:42 <Kevin_Kofler> jreznik: Also Lamarque already announced before that that he isn't interested in 0.9 at this time, he expects others to do that work. :-(
15:24:16 <jreznik> #info we are going to use knm in F15 with documented known bugs and guide how to use nm-applet
15:24:28 <jreznik> ok, anyone volunteer to update known bugs?
15:25:53 <jreznik> anyone? :D
15:26:05 <jreznik> I can take care then...
15:26:41 <jreznik> #action jreznik to document VPN issues as known bug
15:26:51 <jreznik> everything for F15?
15:26:54 <apodtele> ask -than- about the command line solution.
15:27:20 * jreznik uses VPN in command line too :)
15:27:26 <jreznik> #topic 4.6.3
15:28:24 <than> jreznik: we should add the document for command line solution
15:28:50 <Kevin_Kofler> About that "System Settings" menu: https://bugzilla.redhat.com/show_bug.cgi?id=701693#c1
15:30:37 <Kevin_Kofler> So re 4.6.3, the release got delayed, there's still no kdeedu and kdeplasma-addons tarballs.
15:30:50 <Kevin_Kofler> kdeedu in particular appears to be a PITA to spin because the code got scattered across git modules. :-(
15:32:12 <Kevin_Kofler> So the big question is: Can we get 4.6.3 into F15 GA? Or is it too late for that (i.e. should we wait for 0-day updates)?
15:32:34 <Kevin_Kofler> The schedule is quite tight, unfortunately.
15:32:48 <ltinkl> how much time left?
15:33:48 <than> Kevin_Kofler: it's better to wait for 0-day update
15:33:50 <Kevin_Kofler> Final Change Deadline is May 9.
15:33:56 <than> it's too late
15:34:05 <Kevin_Kofler> than: rdieter wanted to get this into GA last I asked him.
15:34:15 <Kevin_Kofler> But that was before the added delays with kdeedu tarball spinning.
15:34:23 <jreznik> it depends on kdeedu
15:34:37 <jreznik> I'd prefer GA instead of 0-day
15:34:52 <jreznik> it's annoying to download whole sc first day after install
15:34:54 <Kevin_Kofler> The thing is, if this isn't in testing by approx. May 5, there's no way it'll make it to stable in time.
15:34:55 <rdieter> starting to look like it's too late to me too
15:35:00 <ltinkl> me too, we will see if Dirk rolls out the tarballs in time
15:35:10 <Kevin_Kofler> Unless we use a stablekarma of 1 and karma it up fast, but…
15:35:14 <ltinkl> xD
15:35:25 <than> in my opinion it's risky because  it's not yet tested well
15:35:32 <rdieter> no need to rush it anymore, take our time and test it thoroughly
15:35:52 <Kevin_Kofler> Yeah, I'm not sure that shipping this with less than 3 days of testing (i.e. fast karma) would be a good idea.
15:36:04 <rnovacek> I'm +1 for more testing
15:36:10 <Kevin_Kofler> 3 days are already tight when there's no time after that to fix regressions.
15:37:03 <jreznik> so big 0day update :(
15:37:12 <apodtele> 4.6.2 is a good release
15:39:12 <jreznik> so we all agreed we don't want 4.6.3 for F15?
15:39:42 <rdieter> yes
15:39:57 <than> jreznik: +1
15:40:25 <jreznik> #agreed not to push 4.6.3 to F15, release it as 0-day update
15:40:28 <Kevin_Kofler> I'm going to abstain, I always like pushing the latest and greatest, but I also see that it's very risky and rushed here.
15:40:49 <jreznik> #info reasons are: kdeedu is still not yet ready, few days for testing and fixing possible regressions
15:41:00 <Kevin_Kofler> It's not ideal not to have the current upstream version on the images, but schedules are what they are. :-(
15:41:22 <jreznik> Kevin_Kofler: I agree, I hate big 0-day updates but it's life
15:41:59 <Kevin_Kofler> So what do we do for https://bugzilla.redhat.com/show_bug.cgi?id=701693 ?
15:41:59 <jreznik> we don't have to hurry now, any ETA on 4.6.3? except kdeedu
15:42:17 <Kevin_Kofler> Should I build a new kdelibs 4.6.2 build for F15 without the patch which adds that System Settings menu.
15:42:32 <Kevin_Kofler> It's also very confusing in that System Settings menu != System Settings application (which is under Settings).
15:42:46 <apodtele> does not have to be 0-day -- all I care is .bug 699024
15:42:51 <Kevin_Kofler> There won't be an "Administration" menu either without that patch, by the way.
15:43:05 <Kevin_Kofler> Upstream menu structure has just "Settings".
15:43:08 <than> Kevin_Kofler: we  go with upstream' s menu structure
15:43:50 <than> Kevin_Kofler:  go ahead
15:44:24 <Kevin_Kofler> OK, will do.
15:44:30 <than> Kevin_Kofler: thanks
15:45:23 <apodtele> .bug 699024
15:45:25 <zodbot> apodtele: Bug 699024 Krandrtray does not save position of second display - https://bugzilla.redhat.com/show_bug.cgi?id=699024
15:45:36 <Kevin_Kofler> apodtele: Is that filed upstream already?
15:45:45 <Kevin_Kofler> If not, please file it at https://bugs.kde.org/
15:45:49 <apodtele> yes, https://bugs.kde.org/show_bug.cgi?id=248563
15:45:54 <rdieter> yes, there's an ongoing dialog
15:46:01 <rdieter> (no fixes or patches though)
15:46:22 <apodtele> this is where we are making some progress. I hope 4ernov is working on it
15:47:15 <jreznik> #info regarding https://bugzilla.redhat.com/show_bug.cgi?id=701693 Kevin_Kofler is going to go with upstream's menu structure as than suggested
15:47:39 <Kevin_Kofler> Next topic?
15:48:18 <jreznik> #topic bluedevil drags in pulseaudio
15:49:13 <jreznik> .bug 701181
15:49:15 <zodbot> jreznik: Bug 701181 bluedevil drags in pulseaudio through dependencies - https://bugzilla.redhat.com/show_bug.cgi?id=701181
15:49:24 <jreznik> .bug 700155
15:49:27 <zodbot> jreznik: Bug 700155 why does bluedevil require pulseaudio ? - https://bugzilla.redhat.com/show_bug.cgi?id=700155
15:49:45 <Kevin_Kofler> This is oget's topic.
15:50:27 <rdieter> I think we've got a reasonable suggestion/work-around in making a -core subpkg
15:50:44 <Kevin_Kofler> I think that's really ugly.
15:50:48 <jreznik> we have to assure that pulseaudio-module-bluetooth is installed on default system
15:51:00 <Kevin_Kofler> All the real code would be in -core and the main package would be a dummy metapackage.
15:51:11 <rdieter> bluedevil would Requires: bluedevil-core pulseaudio-module-bluetooth
15:52:14 <Kevin_Kofler> I think that's a very ugly workaround and wonder if it's worth it.
15:52:18 <jreznik> rdieter: you mean bluedevilaudioactionplugin.so to be out of -core package but in bluedevil + requires?
15:52:38 <rdieter> bluedevil would be an empty metapackage, with just the above Requires:
15:52:46 <jreznik> rdieter: ah, ok
15:52:48 <rdieter> bluedevil-core would have all the real files/contents
15:53:13 <rdieter> so, bluedevil-core => for those who don't want the extras (like pulseaudio), bluedevil for everyone else (default)
15:53:24 <jreznik> it would be nice if we could subpackage bd modules but I tried it and they are still exposed in UI -> crash
15:54:33 * jreznik is getting older and less gentooist than before, pa is now part of fedora...
15:54:49 <jreznik> I can do it but I don't like this solution, looks hackish :)
15:54:54 <Kevin_Kofler> I must say I'm against the metapackage hack, I think we need to just accept PA as a dependency.
15:55:04 <Kevin_Kofler> gnome-bluetooth has been requiring PA for 2 years now.
15:55:11 <Kevin_Kofler> (for the exact same reason)
15:56:20 <rdieter> it's a minimal change, that'll buy some goodwill from those who really want it.
15:57:08 * jreznik was PA hater some time ago too,  now it just works...
15:57:22 <jreznik> still, any better option?
15:57:49 <jreznik> what if someone installs bd-core? and then try to connect Audio?
15:57:49 <Kevin_Kofler> The only other option I see is "do nothing, it's a requirement, period".
15:57:53 <rdieter> either that ... or rely on comps
15:57:58 <Kevin_Kofler> (i.e. what gnome-bluetooth has done)
15:58:00 <rdieter> or do nothing
15:58:03 <jreznik> should we patch BD to show message???
15:58:11 <jreznik> (at least)
15:59:02 <Kevin_Kofler> So we have:
15:59:04 <rdieter> if you mean, option: drop requirement, and patch BD to show message about installing the dep for extra functionality
15:59:08 <rdieter> ?
15:59:10 <Kevin_Kofler> option 1: do nothing (status quo)
15:59:27 <Kevin_Kofler> option 2: use the metapackage hack, with a -core subpackage with the real code
15:59:33 <Kevin_Kofler> option 3: drop the dependency entirely
15:59:49 <rdieter> personally, I'd prefer comps, but upgraders miss out then
15:59:52 <jreznik> rdieter: even for bluedevil-core (if someone installs it, it let's him without audio without explaining what's wrong)
15:59:53 <Kevin_Kofler> I'm definitely against 3, I can accept 2, but I'd prefer 1.
16:00:22 <rdieter> jreznik: bluedevil-core wouldn't be in comps, so only someone who knows what they're doing would be installing it anyway
16:00:29 <jreznik> Kevin_Kofler: we can't drop it (as I said - it's exposed in UI, just do nothing, it's not acceptable)
16:00:35 <rdieter> everyone else would get the fully functional bluedevil
16:01:05 <jreznik> rdieter: you know people :) and for pa haters, it has to be documented somewhere
16:01:32 <rdieter> I suggest those who want the split, help with the documentation
16:02:26 <jreznik> it's just overhead that leads to just broken BD but I'm not against it... let's comment it in BZ
16:02:40 <jreznik> users first :)
16:03:27 <jreznik> #info Bluedevils needs pulseaudio-module-bluetooth to support audio features correctly
16:04:21 <jreznik> ok, we are out of time
16:04:31 <jreznik> so what's the decision here?
16:05:08 <Kevin_Kofler> My preference is still to just keep the dependency.
16:05:17 <jreznik> #info we consider creating -core subpackage with real functionality and bluedevil metapackage that pulls required packages
16:06:04 <jreznik> that't the whole problem - for consistency - do we want to be open to non default setups in the future? see PA, Gstreamer...
16:06:30 <jreznik> it's overhead, leads to bugs but makes some users happy
16:06:55 * Kevin_Kofler thinks we should focus on making things work out of the box for our users and include the required dependencies for that.
16:07:28 <jreznik> let's end here -> #fedora-kde
16:07:38 <jreznik> thanks for coming guys!
16:07:42 <jreznik> #endmeeting