15:02:57 <rdieter_work> #startmeeting kde-sig -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2011-03-22
15:02:57 <zodbot> Meeting started Tue Mar 22 15:02:57 2011 UTC.  The chair is rdieter_work. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:57 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:03:01 <rdieter_work> #meetingname kde-sig
15:03:01 <zodbot> The meeting name has been set to 'kde-sig'
15:03:06 <rdieter_work> #topic roll call
15:03:16 <rdieter_work> hi! who's present today?
15:03:19 * rnovacek is here
15:03:23 * thomasj o/
15:03:57 <Kevin_Kofler> Present.
15:04:21 * jreznik is here
15:04:41 * than is here
15:05:30 * ltinkl is here
15:05:34 <rdieter_work> #info rdieter_work rnovacek thomasj  Kevin jreznik than ltinkl present
15:05:44 <rdieter_work> #chair rnovacek thomasj  Kevin jreznik than ltinkl present
15:05:44 <zodbot> Current chairs: Kevin jreznik ltinkl present rdieter_work rnovacek than thomasj
15:05:58 <rdieter_work> #topic polkit-desktop-policy
15:06:08 <rdieter_work> polkit-desktop-policy: add org.kde.kcontrol.kcmclock.save? Drag this in? (GNOME drags it in through gnome-session.)
15:06:12 <Kevin_Kofler> So I put this one up.
15:06:18 <rdieter_work> Kevin_Kofler: go ahead
15:06:23 <Kevin_Kofler> I noticed GNOME has been dragging in that polkit-desktop-policy package for a while.
15:06:52 <Kevin_Kofler> And for F15, instead of using groups that can only be configured in GNOME, this uses the standard *nix wheel group, and Anaconda allows you to add your user to wheel.
15:07:00 <Kevin_Kofler> So I think we should support this too.
15:07:11 <Kevin_Kofler> I guess kde-settings should grow a Requires on polkit-desktop-policy.
15:07:23 <rdieter_work> I followed the -devel discussion a bit, and I think this makes sense
15:07:37 <jreznik> yeah
15:07:38 <Kevin_Kofler> And we should fix the package to also list org.kde.kcontrol.kcmclock.save as allowed for wheel, the equivalent GNOME policy is already listed.
15:08:46 <rdieter_work> that's a modification to polkit-desktop-policy ?
15:10:08 <rdieter_work> yeah, looks like it.  makes sense.
15:10:19 <jreznik> I'm +1 for both
15:10:31 <Kevin_Kofler> There are 2 modifications, one to the package (should be obvious), and one to drag the package in for KDE.
15:10:41 <Kevin_Kofler> Where should we do the latter? kde-settings?
15:10:46 <rnovacek> yeah 2x(+1)
15:10:47 <rdieter_work> kde-settings
15:10:51 <Kevin_Kofler> kde-settings will also pull it in as a dep of KDE apps…
15:11:03 <Kevin_Kofler> So it's a bit suboptimal.
15:11:07 <than> kde-settings is the place
15:11:08 <rdieter_work> or... hmm... kdebase-workspace is an option too
15:11:15 <Kevin_Kofler> But logically, kde-settings is really the best place.
15:11:19 <rdieter_work> ok, how about this.
15:11:39 <rdieter_work> kde-settings already has a -kdm subpkg, maybe do a -workspace subpkg for... workspace-specific deps too
15:11:52 <rnovacek> polkit-desktop-policy is really tiny without any deps
15:12:17 <Kevin_Kofler> I propose just adding the dep to kde-settings for F15 given that it's tiny and look at a split post-F15.
15:12:19 <rdieter_work> there's a couple of other workspace-related deps we've had to add to kdebase-workspace instead of kde-settings because of that
15:12:33 <Kevin_Kofler> *looking
15:12:51 <rdieter_work> like plasma theme, wallpapers...
15:13:53 <rdieter_work> another option is to just add it to kde-desktop in comps, it's not really a *hard* dep after all.
15:13:56 <jreznik> I agree with Kevin_Kofler - for F15, easiest way, than for F16 do it properly
15:14:12 <rdieter_work> but given the options so far, I'd opt for kde-settings somehow (preferably a subpkg), imo
15:15:25 <rdieter_work> what's the objection to kde-settings-workspace?  (needless complication? or other?)
15:16:18 <Kevin_Kofler> That it's a F16 change.
15:16:50 <Kevin_Kofler> I think it's too big a change for F15.
15:17:21 * rdieter_work shocked to Kevin_Kofler sounding conservative'ishy
15:17:29 <jreznik> lol
15:17:39 <thomasj> heh
15:17:40 <rdieter_work> ok, fair enough, kde-settings it is, I can do that part
15:17:57 <rdieter_work> Kevin_Kofler: you mind doing the poking to get polkit-desktop-policy modified?
15:18:00 <Kevin_Kofler> In particular, if we move deps to kde-settings-workspace and apps turn out requiring those deps after all, we break things.
15:18:25 <rdieter_work> Kevin_Kofler: sure, any deps moved would have to be considered carefully
15:18:28 <Kevin_Kofler> rdieter_work: I think I can just do the change… The list of things allowed by the policy is in the specfile, and they list the GTK+ clock applet.
15:18:37 <Kevin_Kofler> The GNOME clock applet.
15:18:41 <rdieter_work> ok
15:18:43 <jreznik> #info rdieter to add polkit-desktop-policy to kde-settings for F15, and prepare kde-settings-workspace for F16
15:18:44 <Kevin_Kofler> So adding the KDE one shouldn't be controversial.
15:18:54 <Kevin_Kofler> The policy already allows wheel users to set the time.
15:19:46 <rdieter_work> another related piece to this... the "admin" checkbox also adds selected users to the "wheel" group, which is preconfigured for sudo access.
15:20:20 <rdieter_work> we could configure 'kdesu' in 'sudo' mode...
15:20:59 <rdieter_work> ie, kdesu would only require the users' password, instead of root's (ie, to follow sudo behavior)
15:21:19 <Kevin_Kofler> The problem is, this breaks for users with no sudo configured.
15:21:42 <Kevin_Kofler> We'd really need kdesu to use sudo for users in the wheel group and su otherwise, but I don't think this is supported.
15:21:44 <rdieter_work> hmm... good point, our default config would only work for users marked as 'admins"
15:21:47 * thomasj shudders.. sudo behavior..
15:22:11 <Kevin_Kofler> Alternatively, we'd need to lobby to get sudo configured to allow any user to sudo using the root password.
15:22:12 <fenrus02> thomasj, it's not worse than other distro defaults, or osx.
15:22:18 <rdieter_work> with my sysadmin hat on, I'd welcome the the sudo behavior, imo.
15:22:23 <Kevin_Kofler> This is possible (there's a targetpw option or something), openSUSE does it.
15:22:24 <thomasj> fenrus02, that's the problem :)
15:22:44 <fenrus02> thomasj, 'su -c' is insufficient.  it cannot grok selinux at all.  sudo can.
15:22:50 <Kevin_Kofler> I think it's quite silly to have sudo not set up to allow this when you can just use su if you have the root password anyway.
15:23:13 <thomasj> fenrus02, doesn't change anything for me. I don't like sudo.
15:23:21 <rdieter_work> ok, I'll take up the sudo issue, and consider Kevin_Kofler's concern a quasi-blocker to implementing this for kdesu
15:23:21 <fenrus02> thomasj, fair enough
15:23:33 <thomasj> fenrus02, come on, you know that ;)
15:23:50 <fenrus02> thomasj, i'm just around to point out facts, not convert the unwilling ;)
15:23:57 <thomasj> haha
15:24:25 <rdieter_work> anything else?  (I'll move on in ~60 seconds if not)
15:25:01 <fenrus02> with the same SA hat on, i would prefer that the su / sudo access be granted via group membership.  no good can come of $newuser being able to run su/sudo directly without the SA's explicit permission.
15:25:31 <fenrus02> this would mean restricting su access via pam to wheel group as well.  makes it nice and consistent that way.
15:25:53 * rdieter_work likes SA hat's
15:26:10 <Kevin_Kofler> fenrus02: su allows anybody to use it if they have the root password.
15:26:13 <Kevin_Kofler> It's just how this is designed.
15:26:26 <Kevin_Kofler> So I don't see why we don't set sudo up to do the same.
15:26:43 <Kevin_Kofler> Of course sudo with their own password should not be allowed for non-wheel users, duh.
15:26:52 <fenrus02> Kevin_Kofler, add "auth            required        pam_wheel.so use_uid" to your pam file.  it is already there, uncomment it.
15:27:46 <Kevin_Kofler> fenrus02: wheel now means you can sudo with your own password, use PolicyKit elevation with your own password and do a few things like setting the clock with no password at all.
15:27:58 <Kevin_Kofler> So be very very careful with handing out wheel membership in F15+.
15:28:07 <rdieter_work> indeed
15:28:07 <fenrus02> Kevin_Kofler, yes.  what i am suggesting is to make 'su' also use wheel, makes it very consistent that way.
15:28:43 <rdieter_work> oh, neat, su can also be made passwordless?  pam_wheel.so trust ?
15:28:47 <Kevin_Kofler> And what I'm proposing is to allow sudo with the root password (not your own) for non-wheel members, making it consistent with su, and also making things work for setups without wheel.
15:28:50 <rdieter_work> wua ha ha
15:28:58 * thomasj chuckles
15:29:08 <fenrus02> rdieter_work, sicko :)
15:29:30 <rdieter_work> ok, I think we can all agree consistency is good, mm kay? :)
15:29:46 <Kevin_Kofler> If you're the admin, you don't want to have to log the user out to install a package for him/her, do you?
15:29:54 <rdieter_work> I'll try to raise these points on -devel list, feel free to join the conversation
15:29:57 <Kevin_Kofler> So you need to be able to su from within any user's account.
15:30:04 <Kevin_Kofler> But of course you don't want to make them admins (wheel).
15:30:19 <rdieter_work> #topic f14/kde46 status update
15:30:51 <rdieter_work> just a quick update, first batch of f14/kde46 was pushed yesterday, and already found something missing, newer kde-i18n/kdegames3 builds
15:31:02 <rdieter_work> I added those about a hour ago.
15:31:19 <rdieter_work> and updated, https://fedoraproject.org/wiki/SIGs/KDE/KDE46_for_Fedora_14 accordingly
15:31:25 <Kevin_Kofler> Oh yeah, the Klickety conflict, fun…
15:32:30 <Kevin_Kofler> Looking at blockers for going stable, there's still https://bugzilla.redhat.com/show_bug.cgi?id=684419 which we need to address somehow.
15:32:36 <Kevin_Kofler> That's the "pykdeuic4 is broken" bug.
15:32:50 <rdieter_work> than: were you going to look into that one?
15:32:55 <Kevin_Kofler> Somehow it isn't prepared for the PyQt4 version claimed to be a requirement. :-(
15:33:05 * rdieter_work thought so, but might be remembering wrong
15:34:05 * Kevin_Kofler doesn't remember anybody signing up for looking into that.
15:34:29 <than> rdieter_work: i didn't say that
15:34:55 <rdieter_work> ok.  blame bad memory
15:35:43 <rdieter_work> I can try sometime this week, but no promises
15:36:07 <Kevin_Kofler> We need at least https://projects.kde.org/projects/kde/kdebindings/pykde4/repository/revisions/3d84be0316c62136aa02f6a0a5482652d9582242 , but it's not sufficient.
15:36:25 <Kevin_Kofler> Maybe we need these:
15:36:27 <Kevin_Kofler> https://projects.kde.org/projects/kde/kdebindings/pykde4/repository/revisions/9665109594d01a4b62f158e43dca5ca86bf1d169
15:36:33 <Kevin_Kofler> https://projects.kde.org/projects/kde/kdebindings/pykde4/repository/revisions/326b8698c6b62fc7906ea5df62ca5e9262629908
15:36:55 <Kevin_Kofler> And maybe we need fixes which are not done anywhere upstream yet.
15:37:22 <rdieter_work> Kevin_Kofler: if you can post those in the bug, I'll try 'em out and see if I can reproduce the problem anymore or not
15:40:46 <rdieter_work> that looks like our only current blocker, cool, https://bugzilla.redhat.com/showdependencytree.cgi?id=657002&hide_resolved=1
15:41:27 <rdieter_work> the true test is when this goes stable though.  cross your fingers
15:41:32 <Kevin_Kofler> We've been so conservative, waiting for ages until we even pushed this to testing…
15:42:11 <rdieter_work> true, we could nudge things along a little, move all this from kde-testing -> kde (stable) feature repo
15:42:41 <Kevin_Kofler> I think we shouldn't put this in kde-stable now.
15:43:06 <Kevin_Kofler> We should get the blocker resolved (and any new ones that pop up) and then get the update out to official updates, it's already in official updates-testing after all.
15:43:52 <rdieter_work> sure, I was just considering this as one way to find " any new ones that pop up" faster
15:44:23 <Kevin_Kofler> I don't think kde-stable has significantly more users than kde-testing, to be honest.
15:44:26 <rdieter_work> but point taken about the remaining blocker
15:44:35 <rdieter_work> Kevin_Kofler: probably true
15:45:09 <Kevin_Kofler> kde-stable has been mostly unused ever since the Core-Extras Merge, people would only know about kde-redhat if they were looking for kde-testing or kde-unstable.
15:45:11 <rdieter_work> Kevin_Kofler: If so, there shouldn't be much harm to doing it either. :)
15:45:45 <rdieter_work> kde(stable) is just a crutch for last-minute testing while stuff is queue'd for stable in bodhi
15:45:56 <rdieter_work> historically
15:46:23 <rdieter_work> anyway, let's move on...
15:46:27 <rdieter_work> #topic open discussion
15:46:35 <Kevin_Kofler> Well, it used to be the place where people could get the current KDE in ancient RHL days where it wasn't pushed as updates.
15:46:44 <rdieter_work> that's it for the agenda, anything else to discuss in the last 10-15 minutes?
15:47:21 <Kevin_Kofler> So "[Bug 689070] Firstboot doesn't use gtk-oxygen theme after kde spin install" should be fixed now: http://git.fedorahosted.org/git/?p=spin-kickstarts.git;a=commitdiff;h=9a222daf121e1265a859850e2b064b61a929ca44
15:47:42 <Kevin_Kofler> I hope this works and Anaconda doesn't rm -rf /root somehow on liveinst, otherwise we'll need a plan B.
15:48:12 <rdieter_work> it's quite a hack, but I can't think of any better alternative
15:48:18 <Kevin_Kofler> (plan B which would probably be to stuff the creation of the file into rc.local or something)
15:49:23 <Kevin_Kofler> Speaking of liveinst, does liveinst show up properly in the desktop folder view?
15:49:37 <Kevin_Kofler> Because I don't see anywhere where that would be set up…
15:50:09 <Kevin_Kofler> (I noticed this because I saw the diffs removing setting up a desktop icon from the GNOME spin because they don't have a desktop anymore.)
15:50:10 <rdieter_work> Kevin_Kofler: I believe so
15:50:47 <rdieter_work> Kevin_Kofler: look for this comment: # show liveinst.desktop on desktop and in menu
15:51:00 <Kevin_Kofler> That just touches the NoDisplay.
15:51:13 <Kevin_Kofler> It doesn't put the file into ~/Desktop.
15:51:38 <Kevin_Kofler> I guess that if this works, it's getting symlinked from somewhere, but I don't know from where.
15:51:59 <Kevin_Kofler> I don't see the ln -s anywhere in the kickstarts.
15:52:21 <rdieter_work> I'll have to test it again
15:53:13 <Kevin_Kofler> It may be hardcoded somewhere.
15:53:28 <Kevin_Kofler> (but if so, we shouldn't rely on it, with GNOME no longer needing/using it)
15:53:30 <rdieter_work> oh awesome, I just updated my f15 box, and it grabbed new wallpaper, and it refreshed itself before my eyes
15:54:00 <jreznik> :)
15:54:02 <rdieter_work> Kevin_Kofler: agreed
15:54:09 <than> rdieter_work: yes, it' nice :)
15:54:27 <jreznik> actually it's possible to hace "desktop" again in gnome - gsettings magic :)
15:56:49 * rdieter_work will end meeting ni 60 seconds, if there's nothing else...
15:57:21 * rdieter_work is booting f15-alpha-kde-x86_64 to test
15:57:48 <rdieter_work> should snag a fresh snapshot too
15:58:46 <rdieter_work> thanks everyone!
15:58:49 <rdieter_work> #endmeeting