15:05:50 <rdieter_work> #startmeeting kde-sig -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2011-04-26
15:05:50 <zodbot> Meeting started Tue Apr 26 15:05:50 2011 UTC.  The chair is rdieter_work. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:05:50 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:05:54 <rdieter_work> #meetingname kde-sig
15:05:54 <zodbot> The meeting name has been set to 'kde-sig'
15:05:59 <rdieter_work> #topic roll call
15:06:03 <rdieter_work> hi, who's present today?
15:06:08 <Kevin_Kofler> Present.
15:06:47 <rdieter_work> than : ping
15:07:34 <than> present
15:07:38 * ltinkl present
15:07:54 <rdieter_work> looks like jreznik may be busy/out today
15:08:09 <rdieter_work> #chair Kevin_Kofler  than ltinkl
15:08:09 <zodbot> Current chairs: Kevin_Kofler ltinkl rdieter_work than
15:08:16 <rdieter_work> #info rdieter Kevin_Kofler than ltinkl present
15:08:26 <rdieter_work> #topic marble-1.1
15:08:37 <rdieter_work> old business, from last week's agenda, Kevin_Kofler, give a status report?
15:08:43 <rdieter_work> on marble
15:09:00 <Kevin_Kofler> So I build kdeedu-4.6.2-2.fc1[456] packages with Marble 1.1.0 included.
15:09:00 <rdieter_work> http://dot.kde.org/2011/04/18/marble-11-released
15:09:08 <Kevin_Kofler> It's working fine for me on F14.
15:09:18 <Kevin_Kofler> The F15 version is now stable in F15.
15:09:23 <rdieter_work> me too (mostly) on f15, modulo one initial crash using plasma-desktop-marble
15:09:40 <Kevin_Kofler> Upstream claims it's binary-compatible, but we have that issue rdieter is reporting.
15:09:40 <rdieter_work> digikam ok
15:10:18 <Kevin_Kofler> Another thing: Does "Download new maps" work for anyone in Marble? I hadn't had it work with 1.0 and it's still not working with 1.1.
15:10:35 <Kevin_Kofler> It only says that it's loading data and spins forever, nothing shows up.
15:11:04 * rdieter_work tries, says "Loading data..." (spinner)
15:11:17 <Kevin_Kofler> (Is that because no data is available? Or is the server not responding? It's just a standard KHNS3 dialog…)
15:11:20 * than did not see marble 1.1 build for f15
15:11:30 <Kevin_Kofler> than: kdeedu-4.6.2-2.fc15
15:12:16 * jreznik_n900 is here, sorry late from mobilr
15:12:17 <rdieter_work> looks like it doesn't work alright, I'd be tempted to suspect the ghns server first
15:12:27 <rdieter_work> #info jreznik_n900 present too
15:12:32 <rdieter_work> #chair jreznik_n900
15:12:32 <zodbot> Current chairs: Kevin_Kofler jreznik_n900 ltinkl rdieter_work than
15:12:37 <Kevin_Kofler> Yeah, I don't think it's our package's fault.
15:12:57 <Kevin_Kofler> I wonder what's up with that Plasma crash.
15:14:57 <rdieter_work> I'll make sure to have -debuginfo handy in case I see anything else bad happen
15:15:56 <rdieter_work> anyway, so far so good, a qualified success
15:16:48 <rdieter_work> I guess we can move on then
15:17:06 <rdieter_work> #topic PackageKit-related dependencies, https://bugzilla.redhat.com/show_bug.cgi?id=694169
15:17:16 <rdieter_work> .bug 694169
15:17:18 <zodbot> rdieter_work: Bug 694169 phonon dependencies prevent running a reasonable Fedora without PackageKit - https://bugzilla.redhat.com/show_bug.cgi?id=694169
15:17:38 <rdieter_work> mostly about whether to hard-code PackageKit-plugin-gstreamer into phonon-backend-gstreamer or not
15:17:56 <rdieter_work> we discussed it before
15:18:16 <rdieter_work> at the time, one reason to hard-code it was to avoid a phonon crasher when the plugin was not present
15:18:24 <rdieter_work> that has since been fixed
15:18:40 <rdieter_work> so, does that change anyone's minds?
15:18:57 <Kevin_Kofler> I still think the dependency should stay, for upgrade path reasons.
15:19:04 * rdieter_work is tempted
15:19:07 * thomasj wonders why comps isn't a solution. Comps can be edited for older versions than F15 as well. Anyone who has the dep installed won't get hurt, anybody else fresh installing the same.
15:19:43 <Kevin_Kofler> Anaconda will use the F14 GA comps, not the latest comps-f14 in git.
15:19:59 <Kevin_Kofler> Plus, people don't necessarily update every day.
15:20:00 <rdieter_work> comps is a solution, but for f14 would be less than ideal
15:20:00 <thomasj> That's bad.
15:20:22 <Kevin_Kofler> And finally, people are also upgrading from F13, where we don't have the new Phonon.
15:20:27 <rdieter_work> f14/comps only gets used when updates repo is enabled
15:20:44 <thomasj> But still i don't see the problem re upgrade path. Probably i'm blind.
15:20:47 <jreznik_n900> dep is ok for me
15:21:01 <jreznik_n900> but we should be consistent - anywhere - we support freedom elsewhere or nowhere
15:21:10 <rdieter_work> thomasj: upgraders will miss out on the new feature, that new installs would enjoy
15:21:24 <Kevin_Kofler> thomasj: People will not get PackageKit-gstreamer-plugin installed if there's no dep on it.
15:21:46 <Kevin_Kofler> PackageKit is only an indirect dep, PackageKit-gstreamer-plugin is what we need the dep for.
15:21:48 <rdieter_work> otoh, upgraders didn't have the feature before, so it's not like it's a regression ...
15:21:52 <thomasj> Ok, got it, pardon the interruption.
15:22:36 <jreznik_n900> but it is a new f15 feature, technically not a regression in fact
15:23:12 <rdieter_work> given all that, I do have a slight preference for keeping things flexible and removing the hard dep.  seems I may be the only one here that thinks so though
15:24:10 <rdieter_work> than: ?
15:24:39 <rdieter_work> ltinkl: too, any opinion?
15:24:50 <ltinkl> no strong opinion
15:25:28 <rdieter_work> this is another good candidate if we had soft dependencies
15:25:48 <Kevin_Kofler> +1, we really need soft deps… :-(
15:26:25 <jreznik_n900> Kevin_Kofler, yeap
15:26:33 <jreznik_n900> no strong opinion
15:26:59 <rdieter_work> so, by my count so far, we have 2 in favor of status-quo/hard-dep, 1 for soft/comps, and 1 undecided
15:27:01 <jreznik_n900> it is nice to be flexible but we have to support one default
15:27:06 <Kevin_Kofler> Also of note is that GNOME currently also drags in PackageKit in F15.
15:27:18 <Kevin_Kofler> But that might get changed.
15:27:32 <rdieter_work> Kevin_Kofler: true, but I also don't think that should necessarily affect our decision making
15:27:42 <Kevin_Kofler> (gnome-settings-daemon → … → PackageKit)
15:28:34 <rdieter_work> seems like we'll stick with what we have then, for better or worse.
15:28:55 <rdieter_work> any final comments before we move on to open discussion?
15:30:44 <rdieter_work> #info kde-sig affirms to keep pk-plugin-gstreamer dependency in phonon-backend-gstreamer
15:30:50 <rdieter_work> #topic open discussion
15:30:54 <rdieter_work> anything else for today?
15:31:19 * jreznik_n900 does nt use pkgkit but it is still present in system, I dont care
15:31:59 <Kevin_Kofler> So one FYI is that my GSoC proposal got accepted, so unless something really bad happens, I'll be working on Plasma dependency extraction and PackageKit integration during the summer.
15:32:39 <rdieter_work> yay, I guess that ties in with our previous discussion, we may end up dragging in pk anyway. :)
15:33:01 <Kevin_Kofler> :-p
15:33:06 <rdieter_work> though ideally, it'll be something that'll get used if present, else not, but we'll see how the implementation goes
15:33:18 <Kevin_Kofler> We'll see.
15:34:09 <Kevin_Kofler> Another FYI: I sent a mail to NetworkManager-owner and kde-plasma-networkmanagement-owner to discuss the issue of the compat API only being coded to the exact featureset of last month's kde-plasma-nm snapshot.
15:34:24 <rdieter_work> #info Kevin_Kofler gsoc proposal on plasma/packagekit integration was accepted
15:34:49 <Kevin_Kofler> New snapshots have support for system connections and Bluetooth tethering (and ad-hoc connections / bridging got fixed, I don't know whether that works in the compat API either), and IPv6 support is coming soon.
15:35:04 <rdieter_work> dcbw may not want to hear all that. :)
15:35:28 <Kevin_Kofler> I'm not sure about IPv6, but I know system connections and Bluetooth tethering are missing from the compat API. :-(
15:35:49 <rdieter_work> depends on how fast the race to nm09 native plasma-nm comes along
15:36:03 <Kevin_Kofler> Yeah, that'd really be the optimal solution.
15:36:28 <Kevin_Kofler> But so far I can't see much going on in the nm09 branch of kde-plasma-networkmanagement, except for merges from master (i.e. from the 0.8 codebase).
15:36:40 <rdieter_work> or whatever we end up using (ltinkl's proof of concept nm09 ui)
15:37:24 <Kevin_Kofler> Maybe I can spare some time to work on that stuff too, but I'm always trying to do too many things…
15:37:33 <ltinkl> well the nm09 branch is not something we want to ship atm, not before the "big rewrite"
15:37:58 <Kevin_Kofler> ltinkl: Well, I'd like the nm09 branch to get made working and then ship that, at least for F15 updates.
15:37:59 <rdieter_work> Kevin_Kofler: yeah, on the one hand, < nm-0.9 support is really a dead-end , but is where most upstream work is going, for better or worse
15:38:05 <Kevin_Kofler> Major changes are not welcome in F15.
15:38:11 <ltinkl> Kevin_Kofler: that would be nice
15:38:22 <ltinkl> Kevin_Kofler: but be prepared the code is a mess :)
15:38:38 <Kevin_Kofler> The main issue is that I'm not familiar with NM or kde-plasma-nm code at all.
15:38:51 <ltinkl> ideally, the nm09 branch should not be running against the compat layer
15:38:55 <Kevin_Kofler> So I'd waste quite some time getting familiar with the mess before even getting started doing anything. :-(
15:39:27 <Kevin_Kofler> The compat layer needs to go away.
15:39:31 <rdieter_work> anyone have contact with jklimes, are they still working on it?
15:40:30 <rdieter_work> I'd previously assumed yes, but the lack of news/updates or activity in nm09 branch worries me
15:40:42 <ltinkl> I think he stopped working on it after dbcw promised to take care of the compat issues
15:40:51 <Kevin_Kofler> rdieter_work: +1, same here…
15:40:59 <Kevin_Kofler> The problem is, the compat solution is only temporary.
15:41:01 <rdieter_work> yikes
15:41:18 <Kevin_Kofler> We need this sorted out for F16 at the very least.
15:41:19 <ltinkl> which reminds me, we should nag dbcw to at least fix the VPN connections in the compat interfaces
15:41:52 <ltinkl> I'll try to talk to him once he comes online
15:41:53 <rdieter_work> ltinkl: file bugs (if not already), and I'll work to get them visibility
15:42:08 <ltinkl> rdieter_work: ok
15:42:10 <rdieter_work> talking is good too, but bz is a good way to track it
15:45:02 * rdieter_work will close meeting in 2 minutes if there's nothing else
15:45:44 <apodtele> dual monitor settings lost on logout? Bug 699024?
15:45:59 <Kevin_Kofler> .bug 699024
15:46:01 <zodbot> Kevin_Kofler: Bug 699024 Krandrtray does not save position of second display - https://bugzilla.redhat.com/show_bug.cgi?id=699024
15:46:29 <apodtele> any core SIG member with dual monitor to reproduce?
15:49:01 <rdieter_work> not i
15:49:51 <jreznik_n900> no dual setup...
15:49:59 <rdieter_work> looks like the bug is less about setting not being saved, but rather those settings not being properly translated into the appropriate/correct xrandr calls
15:50:14 <rdieter_work> but the effect is the same
15:50:24 <apodtele> yes
15:53:32 <Kevin_Kofler> What's the NTH tracker again? F15-accepted?
15:53:50 <Kevin_Kofler> (IIRC they're using "accepted" even for stuff which is not accepted yet. ;-) )
15:54:01 <rdieter_work> I think only qa folks are supposed to set that, after it being nominated for blocker
15:54:20 <rdieter_work> but I could be wrong about that
15:54:47 <Kevin_Kofler> adamw: What's the correct procedure for nominating something as NTH?
15:55:06 <rdieter_work> wrt the dual monitor settings, we'll need someone with an intersection of having the hardware, and the ability/interest to look into fixing it.  seems we're currently stuck on the empty set
15:55:17 <adamw> Kevin_Kofler: yo
15:55:25 <adamw> Kevin_Kofler: mark it as blocking F15-accepted (for final NTH)
15:55:35 <Kevin_Kofler> OK.
15:55:42 <adamw> beta NTH is F15Beta-accepted , Alpha is F15Alpha-accepted , for F16 s/15/16/ , I guess you get the picture :)
15:56:00 <adamw> and yeah, the name is kinda silly, maybe we should just change it to NTH>
15:57:21 <rdieter_work> adamw: thanks
15:57:35 <rdieter_work> alrighty, we're about out of time, so I'll close up shop, thanks everyone!
15:57:37 <rdieter_work> #endmeeting