15:16:44 <rdieter> #startmeeting kde-sig -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2013-09-17
15:16:44 <zodbot> Meeting started Tue Sep 17 15:16:44 2013 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:16:44 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:16:51 <rdieter> #meetingname kde-sig
15:16:51 <zodbot> The meeting name has been set to 'kde-sig'
15:17:04 <rdieter> #topic roll call
15:17:14 <rdieter> hi, whos present today?
15:17:21 <Kevin_Kofler> Present.
15:17:25 <mbriza> present
15:17:25 <jgrulich> present
15:17:29 * oddshocks lurking
15:18:25 <rdieter> than_ : ping
15:19:04 <rdieter> #info Kevin_Kofler rdieter mbriza jgrulich oddshocks present
15:19:13 <rdieter> #chair Kevin_Kofler  mbriza jgrulich
15:19:13 <zodbot> Current chairs: Kevin_Kofler jgrulich mbriza rdieter
15:19:56 <rdieter> let's just run through the agenda per wiki (see /topic), and then see if we have time at end for anything else
15:20:00 <rdieter> #topic kde-4.11.1 status
15:20:32 <rdieter> let me echo what I sent to kde@fpo list...
15:20:35 <rdieter> As far as kde-4.11.1 goes, status is that it's been in kde-testing for awhile now, getting some good testing.  I just submitted it in several pieces to bodhi for f19/f20 yesterday.  It seems to be too big to submit as a single piece to bodhi anymore.
15:20:50 <rdieter> several things I wanted to work on :
15:20:52 <rdieter> * enable automatic passwordless-kwallet (for f20+ at least)
15:20:54 <rdieter> * backport https://git.reviewboard.kde.org/r/109609/
15:21:02 <than_> present
15:21:09 <rdieter> #info than_ present
15:21:11 <rdieter> #chair than
15:21:11 <zodbot> Current chairs: Kevin_Kofler jgrulich mbriza rdieter than
15:21:12 <rdieter> #chair than
15:21:12 <zodbot> Current chairs: Kevin_Kofler jgrulich mbriza rdieter than
15:21:47 <rdieter> that's all I have wrt 4.11.1, any other comments/concerns?
15:22:16 <Kevin_Kofler> F18 builds?
15:23:11 <rdieter> I suppose I could do unofficial f18 builds, unless you're suggesting more than that?
15:23:44 <rdieter> was meaning to do el6 ones sooner or later, could just as well do f18 at the same time
15:24:05 <Kevin_Kofler> I'm always the one who suggests doing official updates for Fn-1, but I guess I've just opened a big can of worms…
15:25:26 <than> rdieter:  you mean 4.11 for el6 ?
15:26:23 <Kevin_Kofler> Yes, in kde-redhat, where he has 4.10 already built.
15:26:45 <rdieter> than: yes
15:26:46 <than> great !
15:26:54 <Kevin_Kofler> It's not eligible for EPEL because it replaces the stock RHEL KDE.
15:27:14 <than> i know
15:29:13 <rdieter> anything else?  (otherwise I'll move on to f20 features/changes items... sddm, plasma-nm)
15:31:02 <Kevin_Kofler> If you do unofficial builds of 4.11 for F18 soon, I can probably test them.
15:31:19 <rdieter> #topic sddm - https://fedoraproject.org/wiki/Changes/SDDMinsteadOfKDM
15:31:20 <rdieter> ok
15:31:24 <Kevin_Kofler> I'd really like to test the kdepim performance improvements, I hope I won't be disappointed!
15:31:50 <rdieter> mbriza: mind giving a brief update/status-report
15:32:03 <rdieter> wrt sddm progress
15:32:31 <mbriza> so, briefly, there's still some mess regarding pam, resulting in me basically rewriting the whole authenticator class
15:33:22 <Kevin_Kofler> Are we sure the PAM issues are even SDDM's fault?
15:33:33 <mbriza> not really but other DMs work better
15:33:37 <Kevin_Kofler> There seems to be some PAM/systemd breakage lurking in F20+.
15:33:49 <mbriza> at least on my machine
15:34:22 <rdieter> Kevin_Kofler: could be
15:35:36 <mbriza> but yeah, having an online session after logging out is definitely wrong
15:35:36 <rdieter> pam_systemd does most of the work for session regristration, no?
15:36:10 <mbriza> well, the current problem is you can't log in again after logging out, i'm not sure if this is directly related to pam_systemd or any other pam module
15:36:16 * rdieter forgets, spoiled by it "just working" for so long
15:36:22 <mbriza> mainly because when you restart sddm, it works fine again (for one log in)
15:36:51 <rdieter> .bug 1005233
15:36:52 <mbriza> so i think there's some state information lingering in sddm, causing it to fail once tried again
15:36:54 <zodbot> rdieter: Bug 1005233 lightdm greeter does not allow existing users to choose a different DE when they logout or "switch users" - https://bugzilla.redhat.com/show_bug.cgi?id=1005233
15:37:06 <rdieter> fyi ^^ I think this may be a symptom of the same or similar problem
15:37:16 <mbriza> thanks, i will take a look at it
15:37:45 <rdieter> planning on reassigning that to systemd , and proposing it a blocker
15:38:11 <mbriza> ah, yeah, i already saw that, this is definitely wrong
15:38:41 <rdieter> mbriza: the problem you describe on not being able to login again... does that happen on f19 too, or just f20+ ?
15:39:06 <mbriza> well, currently it doesn't happen anywhere because it's "fixed" by calling pam_end() twice on the same handle
15:39:19 <rdieter> heh, ok
15:39:23 <mbriza> which is wrong of course
15:39:33 <rdieter> pam_end_harder
15:39:35 <mbriza> and afaik it causes automatic relogging for autologin
15:40:15 <rdieter> may be a pam problem then, eh?
15:40:25 <mbriza> i doubt that
15:40:54 <mbriza> other DMs just work with the same flow of pam calls as we have
15:41:16 <rdieter> per the bug I referenced, all DMs fail the same way for me.
15:41:21 <mbriza> currently i'm experimenting in ending the session after the X process has exited, the session process has exited and such... still no success though
15:42:12 <mbriza> hmmm, unfortunately i don't have my f20 machine here right now, it'd be worth trying again to be sure
15:42:18 <rdieter> only significant pam difference f19 vs f20, is bug 969174
15:42:20 <rdieter> .bug 969174
15:42:24 <zodbot> rdieter: Bug 969174 pam_sepermit is causing xguest to ask for password on screenlock. - https://bugzilla.redhat.com/show_bug.cgi?id=969174
15:42:59 <rdieter> anyway, didn't mean to sidetrack things here...
15:43:03 <rdieter> anything else wrt sddm ?
15:43:17 <rdieter> in particular, anything you need help with or testing particular features?
15:43:56 <mbriza> theme - have a draft, nobody has still seen the source but it looks kinda like this http://ma.rtinbriza.cz/s/esdedeem.png and i have no idea how to finish it and who to discuss it with
15:44:20 <mbriza> in particular, i'd love if somebody tested itv with some directory service
15:45:18 <mbriza> if you have any setup somewhere, otherwise i'll just ping the freeipa guys in rh
15:46:13 <rdieter> mbriza: we use active directory @ work, so I could test that
15:46:34 <rdieter> but that's all generally handled via pam, so I wouldn't expect any problems
15:47:06 * rdieter likes the basic theming, good start.
15:47:40 <Kevin_Kofler> Yeah, it's an OK design.
15:47:55 <rdieter> #info mbriza working on improving pam, has a draft non-userlist theme
15:48:27 <Kevin_Kofler> Are you going to also maintain a version with the userlist or only that one?
15:48:54 <mbriza> so far i'd just stick to this one
15:49:03 <rdieter> sddm has other themes that support userlist, I dont think we need to provide another one
15:49:39 <rdieter> ok, moving on?
15:50:47 <rdieter> #topic plasma-nm - https://fedoraproject.org/wiki/Changes/Plasma-nm
15:51:11 <rdieter> jgrulich: your baby, can you give a brief update on plasma-nm status?
15:51:53 <jgrulich> well, on F19 it works okay, but it seems we have some problems on F20, but don't know whether the problem is NetworkManager
15:53:30 <rdieter> <nod> let's make sure to file bugs to track these items
15:53:54 <rdieter> (if not already, of course)
15:54:30 <jgrulich> the only existing problem now is that you can't see IPv4 address in connection details
15:57:00 <rdieter> in particular, can't see ipv4 addr for wired connections (I can see wireless ipv4 addr ok)
15:57:32 <jgrulich> rdieter: hmm, that's weird
15:57:47 * Kevin_Kofler cannot find jriddell's script to migrate to plasma-nm.
15:57:57 <Kevin_Kofler> It's not in the Kubuntu package.
15:58:17 <jgrulich> because there is no difference between getting IPv4 addr from wired and wireless connections
15:58:38 * rdieter double checks
15:59:18 <rdieter> confirmed, it shows fine for wiki
15:59:52 <jgrulich> that's another thing, Aaron Seigo and Sebastian Kugler want for us to rename plasma-nm to have the same name like the old one for better upgrade experience
16:00:45 <jgrulich> so when we rename it, we won't need any migrate script
16:01:10 <Kevin_Kofler> I think that makes sense.
16:01:25 <rdieter> hrm... that means when/if renaming happens, we can no longer deploy it to < f20, unless you mean to migrate them too eventually?
16:01:28 <Kevin_Kofler> The name is also hardcoded in the initialization code in kde-workspace if I'm not mistaken.
16:01:55 <Kevin_Kofler> So you also avoid having to install an init script for new users if you use the well-known name.
16:02:42 <jgrulich> rdieter: we can have both, the one under kde-plasma-nm and the old one as it is now, we would only rename the plugin name
16:03:35 <rdieter> jgrulich: but wouldn't they conflict then?
16:04:01 <jgrulich> rdieter: yes, that would be the only change in packaging
16:04:46 <rdieter> icky
16:05:21 <Kevin_Kofler> Conflicts: is evil…
16:05:21 <rdieter> I suppose we could patch for < f20 to not conflict, if we *really* wanted to
16:06:16 <Kevin_Kofler> Yeah, I think it also makes sense to keep the name we already ship in F19-.
16:06:42 <Kevin_Kofler> But then of course we'd probably want a migration script to switch back to the old name on upgrades to F20.
16:07:18 <Kevin_Kofler> (In fact IMHO we need that script anyway because we already shipped the new (soon to be old) name.)
16:07:24 <jgrulich> I don't think it's possible to just simply change the plugin name by some patch due to translations
16:07:40 <Kevin_Kofler> There's no way around a migration script.
16:08:57 <rdieter> I could live with updating only for f20+ when/if it is renamed
16:10:01 <rdieter> it's only a tech-preview for < f20 anyway, we could do unofficial builds of there's demand for it
16:10:27 <rdieter> anything else? nm-related?  I guess we're running short on time
16:11:01 <rdieter> fyi, hero haraldh whipped up a systemd build to test, may help fix some/all of our issues, http://koji.fedoraproject.org/koji/buildinfo?buildID=465157
16:14:50 <rdieter> #topic KDE test day
16:15:02 <rdieter> last item on agenda was this, who added it?
16:15:06 <jgrulich> me
16:15:13 <rdieter> I guess its about picking a test day?
16:15:27 <jgrulich> just a reminder that we should organize some KDE test day
16:16:16 <rdieter> last few releases we've had test days, and have got a lot of good feedback, polish, bugs from them
16:16:39 <jgrulich> and it will be useful for plasma-nm
16:16:54 <rdieter> anyone interested in leading test day organization?
16:17:14 <jgrulich> I can help
16:17:24 <jgrulich> but the question is, when?
16:17:27 <Kevin_Kofler> Sadly, more than Test Days, we need Fix Days. ;-)
16:18:24 <Kevin_Kofler> Finding people to FIND bugs is the easy part, the hard part is finding people to actually FIX them. :-(
16:18:29 <rdieter> https://fedoraproject.org/wiki/QA/Fedora_20_test_days
16:18:38 <rdieter> Kevin_Kofler: every day is a fix day.
16:18:41 <rdieter> ha ha
16:18:51 <Kevin_Kofler> :-)
16:18:58 <jgrulich> for plasma-nm it's obvious who will fix them :)
16:19:39 <rdieter> imo, lets take the test day topic onlist, ask for feedback about dates, and go from there?
16:19:52 <Kevin_Kofler> +1
16:20:08 <jgrulich> ok
16:21:11 <rdieter> I think its a given that we want a test day
16:21:27 <rdieter> its just a matter of documenting test cases, and stuff we want tested... and picking a date
16:22:32 <rdieter> and only picking the date we can wait for (not too long though), the others do asap
16:24:58 <rdieter> lets wrap up, went way longer than intended. :)
16:25:02 <rdieter> thanks everybody
16:25:04 <rdieter> #endmeeting