14:03:21 <rdieter> #startmeeting KDE SIG Meeting -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-01-05
14:03:21 <zodbot> Meeting started Tue Jan  5 14:03:21 2010 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:21 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:03:31 <rdieter> #chair Kevin_Kofler ltinkl than jreznik
14:03:31 <zodbot> Current chairs: Kevin_Kofler jreznik ltinkl rdieter than
14:03:36 <rdieter> #topic Init
14:03:41 <Kevin_Kofler> #meetingname kde-sig
14:03:41 <zodbot> The meeting name has been set to 'kde-sig'
14:03:43 <rdieter> who's present today ?
14:03:47 <Kevin_Kofler> Present.
14:03:48 * ltinkl is present
14:03:50 * jreznik is here
14:03:57 * than is present
14:04:18 <rdieter> SMParrish sent his regards (dr appt)
14:06:02 <rdieter> #topic agenda items
14:07:30 <rdieter> just added a few items, kdm/plymouth, kde/f13 todos, anything else ?
14:08:51 <rdieter> well, let's get started then.
14:09:00 <rdieter> #topic KDE SC 4.3.5
14:09:06 <jreznik> maybe back to akonadi - instead fixing calendar, get rid of akonadi split
14:09:16 <rdieter> ok, I'll add that to agenda
14:09:46 <than> ltinkl: could you please take care of kde-4.3.5 update when it's available on ktown?
14:09:53 <ltinkl> definitely
14:10:02 <than> ltinkl: thanks
14:11:21 <rdieter> that was easy. :)
14:11:30 <ltinkl> :)
14:11:34 <rdieter> relatedly,
14:11:44 <ltinkl> 4.3.5 should be avi sometimes this week
14:12:00 <ltinkl> or at least tagged
14:12:06 <rdieter> #topic kdm/plymouth buglet , https://bugzilla.redhat.com/show_bug.cgi?id=551310
14:12:07 <buggbot> Bug 551310: high, low, ---, rstrode, ASSIGNED, update to kde-4.3.4 - X startup fails, xf86OpenConsole: VT_WAITACTIVE failed: Interrupted system call
14:12:46 <rdieter> any thoughts here?  the fix to not hardcode using vt1 exposed this fun one
14:13:28 <rdieter> plymouth -> X transtion borks if it involves a vt switch (ie, in the non-kms case)
14:14:07 <rdieter> sadly, no word or comment from the plymouth folks yet, I'll try pinging them again today
14:14:59 <jreznik> yep, help from plymouth guys would be nice
14:15:15 <Kevin_Kofler> I think we should just go back to hardcoding tty1 until that's fixed.
14:15:15 <rdieter> too bad we (apparently) don't have linus anymore, else he could help debug like when it happened similarly in the past with rhgb, https://bugzilla.redhat.com/show_bug.cgi?id=323501
14:15:16 <buggbot> Bug 323501: high, low, ---, ajax, CLOSED RAWHIDE, rhgb causes "xf86OpenConsole: VT_WAITACTIVE failed: Interrupted system call" on real X startup
14:15:46 <Kevin_Kofler> I think hardcoding tty1 is the lesser evil.
14:15:48 <jreznik> Kevin_Kofler: indeed
14:15:59 <rdieter> Kevin_Kofler: I'd prefer just advertising that loudly as a workaround
14:16:22 <rdieter> but i don't feel strongly
14:16:25 <jreznik> rdieter: it's not suitable for 'normal' users
14:16:55 <rdieter> secondly, I'd also before to hear from the plymouth/X maintainers, before doing anything rash
14:16:58 <jreznik> my colleague next to me is affected too :) and if you can't boot, you can't check google for workaround
14:17:03 <rdieter> s/before/prefer/
14:17:40 <rdieter> really sad we didn't find out about it in time, while it was in -testing
14:18:12 <rdieter> than, ltinkl: what do you guys think ?
14:18:35 <ltinkl> I don't have any trong opinion on this
14:18:38 <jreznik> rdieter: now with KMS/different drivers etc... there are so many combinations...
14:18:46 <jreznik> to test properly
14:19:22 <rdieter> the kms case is fine, in that case, there is no vt switch
14:19:35 <rdieter> it's non-kms folks hitting this bug
14:20:05 <rdieter> where kdm tries to switch to the first free vt => vt7
14:20:39 <than> we should add a workaround temporary before we know where the problem is
14:20:51 <jreznik> rdieter: ops, I thought it's with KMS... from description, and kvolny has KMS enabled too - it boots only while rhgb is removed
14:21:15 <than> it's bad when the user cannot login
14:21:20 <rdieter> the kdm patch is clear, when kms is used => no vt switch
14:21:42 <Kevin_Kofler> The bug is with KMS enabled!
14:21:47 <Kevin_Kofler> Or vga=…
14:21:57 <Kevin_Kofler> Anything which uses the graphical version of Plymouth.
14:22:01 <rdieter> Kevin_Kofler: I disagree 9at least it's unclear)
14:22:01 <jreznik> yes
14:22:20 <rdieter> it's folks hacking in a graphical plymouth without kms, from what I can gather
14:22:23 <Kevin_Kofler> There's no issue with the text Plymouth.
14:22:23 <jreznik> it's with KMS enabled - I saw it :-) or maybe there are more bugs...
14:22:47 <rdieter> with kms enabled, there isn't (or shouldn't be!) any vt switch
14:23:09 <jreznik> rdieter: so it's not connected to vt switch? or two different bugs?
14:23:21 <rdieter> ie, it's possible to use plymouth without kms (I think that's confusing the issue here... unless I'm just confusing myself)
14:23:31 <rdieter> it's all about the vt switch!
14:24:05 <jreznik> there should be no vt switch but it doesn't work...
14:24:07 <rdieter> thought the plymouth graphical vs text thing is wierd
14:24:30 <jreznik> without kms you have text plugin (or you have to set vga=....)
14:24:42 <rdieter> hint: when kms is used, kdmrc's ServerVTs= is ignored
14:24:57 <rdieter> yet, for all reporters so far, setting ServerVTs=1 "'fixes" it.
14:26:13 <Kevin_Kofler> That's the strange thing.
14:26:18 <Kevin_Kofler> Looks like your patch is not working.
14:26:48 <rdieter> works fine on my box (afaict)
14:26:52 <rdieter> also strange
14:27:12 * jreznik asks kvolny to try reboot with ServerVTs=1
14:27:12 <rdieter> (ie, I cannot reproduce the problem either, when forcing non-kms)
14:27:21 <rdieter> :(
14:27:29 <rdieter> so, long-story short, here's what I propose,
14:27:50 * halfline looks up
14:28:02 <rdieter> 1.  wait to hear from plymouth maintainers , 2. if 1 takes too long, revert to kdmrc ServerVTs=1 in the meantime
14:28:05 <rdieter> halfline: hiya
14:28:15 <halfline> hey
14:28:29 <Kevin_Kofler> Maybe the issue is with systems which never had GDM installed?
14:28:42 <Kevin_Kofler> /var/spool/gdm probably doesn't exist then.
14:28:50 <than> rdieter: it's a critical bug, we should do 2 (workaround)
14:29:03 <rdieter> Kevin_Kofler: ooh... that is indeed owned by gdm, rats
14:29:06 <Kevin_Kofler> I don't have a /var/spool/gdm at all on this machine.
14:29:18 <Kevin_Kofler> And so Plymouth doesn't create the file which triggers the magic behavior.
14:29:19 <than> before we can figure out where the problem is
14:29:24 <Kevin_Kofler> And so your patch doesn't work.
14:29:30 <Kevin_Kofler> than: I just figured it out. :-)
14:29:45 <Kevin_Kofler> See above.
14:30:08 <rdieter> halfline: ok, if /var/spool/gdm is missing, then I suppose /var/spool/gdm/force-display-on-active-vt won't get created by plymouth, eh?
14:30:14 <Kevin_Kofler> Right.
14:30:22 <Kevin_Kofler> KMS in use here, no /var/spool/gdm at all.
14:30:44 <rdieter> I have gdm installed (for testing), ah, why I can't reproduce.  duh (feel silly now)
14:31:35 <rdieter> halfline: what would you prefer, moving owner ship of /var/spool/gdm to plymouth somewhere, or teach plymouth to use another path (for kdm, others)?
14:32:03 <halfline> oh glad you guys figured it out
14:32:08 <halfline> so my concern is
14:32:16 <halfline> this /var/spool/gdm/ thing is a hack
14:32:21 <rdieter> well, that's one possible problem anyway, I still suspect there's > 1 here
14:32:23 <halfline> that will be going away in f13
14:32:33 <rdieter> halfline: right, we're discussing f11/f12 here
14:32:42 <halfline> so whatever we do, it just needs to be good enough for the mean time
14:32:46 <rdieter> we can deal with f13 changes when they land
14:32:53 <halfline> right
14:33:48 <rdieter> I'm still convinced in some cases (kms or not) that a vt1/plymouth (whatever) => vt7 switch bug is there somewhere, but if we can at least get the kms case right, that'll be something
14:33:59 <halfline> i don't really want to do big changes in f12 (and especially f11) so we should probably figure out the minimum change needed
14:34:06 <halfline> even if it isn't the most elegant
14:34:16 <rdieter> halfline: I think the /var/spool/gdm ownership fix is all that is required
14:34:30 <halfline> rdieter: sure, let's deal with each bug separately
14:34:30 <Kevin_Kofler> We can just have kdebase-workspace coown /var/spool/gdm.
14:34:31 <rdieter> OK, I know, I'll add that dir to kdm too
14:34:32 <Kevin_Kofler> Or rather, kdm.
14:34:39 <rdieter> Kevin_Kofler: right
14:34:44 <Kevin_Kofler> (which is a subpackage of kdebase-workspace)
14:34:48 <Kevin_Kofler> How will it work in F13?
14:34:55 <halfline> that seems like an ok solution
14:35:05 <rdieter> halfline: thx, we'll do that, and see how it goes
14:35:17 <halfline> in f13 plymouth stays running until after kdm starts the x server
14:35:30 <halfline> so you can just run plymouth --ping to check whether to do the transtion or not
14:35:52 <rdieter> cool
14:36:17 <rdieter> I'll do the kdm owning /var/spool/gdm thing , anything else here, or can we move on?
14:36:18 <halfline> Kevin_Kofler: i wrote a blog post about it over thanksgiving, let me find it
14:36:23 <Kevin_Kofler> That sounds more complicated than the lockfile. :-(
14:36:35 <Kevin_Kofler> But of course we can implement that in KDM too.
14:36:35 <halfline> Kevin_Kofler: http://blogs.gnome.org/halfline/2009/11/28/plymouth-%e2%9f%b6-x-transition/
14:36:50 <Kevin_Kofler> We'll just need to have conditional patches for it. :-/
14:36:58 <halfline> Kevin_Kofler: well we can talk about the details later i guess
14:37:18 <halfline> and make changes in the process if necessary
14:37:23 <rdieter> halfline: right, your blog is what gave me the clues to make kdm work. thanks!
14:37:46 <rdieter> (modulo my botching the /var/spool/gdm ownership)
14:38:21 <halfline> well glad you guys figured it out.  hopefully the other issue will fall away too, but if not, prod me again
14:38:46 <rdieter> kl
14:38:55 * halfline goes back to post-vacation catchup
14:39:06 <rdieter> #topic get rid of -akonadi pkg splits for KDE SC 4.4?
14:39:36 <rdieter> topic says it all, as akonadi is becoming pervasive in 4.4, we ought to re-evaluate the need/wisdom of all the -akonadi splits
14:40:45 <than> it seems it doesn't make sense to split it
14:42:20 <rdieter> we did it before to keep akonadi off the livecd, don't think that's even possible anymore really
14:42:34 <rdieter> any objections to scrapping the -akonadi splits then ?
14:43:33 <than> ok, we drop the -akonadi splits
14:43:42 <jreznik> question is how deep is akonadi integration in 4.4 but still get rid of split...
14:44:00 <than> move it back main package
14:44:03 <jreznik> for F13 and for F11/F12 I can fix at least calendar
14:44:04 <rdieter> any sucker... err... volunteer to undo the -akonadi packaging ?
14:44:16 <Kevin_Kofler> I also think the split doesn't make sense anymore.
14:44:25 <rdieter> will need to be careful with Obsoletes (and possibly some Provides).
14:44:30 <than> Kevin_Kofler: i agree
14:44:34 <Kevin_Kofler> In fact I was against it in the first place because I knew very well this was going to happen. ;-)
14:44:41 <jreznik> yep, obsoletes would be fun :)
14:45:08 <rdieter> well, I guess i can do it, I'm pretty familiar with it
14:45:12 <than> rdieter: i will take care of this
14:45:19 <rdieter> than: ok, thx
14:47:56 <rdieter> #topic http://fedoraproject.org/wiki/User:Rdieter/FUDCon_Toronto_KDE_F13_TODOs
14:48:25 <rdieter> some requirements for default apps, and misc todos for f13 that came from a brainstorm session @ fudcon
14:48:47 <rdieter> what I'd like to focus on are setting minimal requirements for some default apps
14:49:11 <rdieter> in particular, for nm, pk, bluetooth frontends
14:49:43 <rdieter> if for nothing else, when/if we get the inevitable questions about why/how we chose what apps here to use and include, we can point to that
14:50:02 <Kevin_Kofler> There aren't really any replacements for those apps.
14:50:12 <Kevin_Kofler> So I don't think "minimal requirements" makes sense.
14:50:17 <jreznik> Kevin_Kofler: Gnome one...
14:50:18 <rdieter> my other ulterior motive is to use this as justification to consider not using kpackagekit
14:50:20 <Kevin_Kofler> Target features for F13, sure.
14:50:23 <Kevin_Kofler> jreznik: No thanks!
14:50:38 <rdieter> Kevin_Kofler: frankly, we need something that works.  kpk doesn't
14:50:42 <Kevin_Kofler> We don't want to add more GTK+/GNOME stuff.
14:50:45 <Kevin_Kofler> KPK works well enough.
14:50:52 <rdieter> have you tried it lately?
14:50:57 <Kevin_Kofler> The main issue I've seen with it on F12 is a PK backend bug.
14:50:58 <rdieter> complete fail
14:51:03 <Kevin_Kofler> It also fails with gnome-pk.
14:51:10 <jreznik> Kevin_Kofler: if gnome application meets our requirements and KDE does not - than it's ok for me... sorry, I'n not S/M user :D
14:51:10 <Kevin_Kofler> And it's fixed in the current update.
14:51:32 <rdieter> I've been using gnome-pk for past couple of weeks.  wonderful to have an updater that actually works.
14:51:53 <Kevin_Kofler> gnome-pk is designed to run in GNOME, it even has an OnlyShowIn.
14:52:10 <rdieter> all i care about is having these essential front-ends that are reliable and have the functionality we need.
14:52:28 <rdieter> hence, come up with an objective list of requirements, and find the app that best meets those
14:52:42 <Kevin_Kofler> Using it in KDE in F9 (or whatever version that was) was a hack, required patching the .desktop file and meant we couldn't easily transition users to KPK once it worked.
14:52:50 <rdieter> in case of anything close, we can give a slight edge to any kde application of course
14:53:19 <Kevin_Kofler> I also think NM-gnome really shouldn't be considered an option anymore.
14:53:49 <Kevin_Kofler> It already sucked that we shipped 5 releases with KDE infected with this stuff which didn't even have a working keyring until today.
14:53:53 <rdieter> Kevin_Kofler: you're welcome to that opinion, I don't share it.  I want something that works.
14:53:55 <Kevin_Kofler> And these days, KNM just works.
14:54:07 <Kevin_Kofler> I don't see why we would continue not using it.
14:54:19 <rdieter> sure, knm is probably the way to go for us, has an active upstream, fixing stuff all the time.  we see progress there.
14:55:04 <rdieter> even basic stuff like instaling standalone/unsigned packages fails in kpk => reason why we need a list of objective criteria
14:55:34 <rdieter> heck, if kpk can be whipped into shape to meet our criteria, great.
14:55:47 <Kevin_Kofler> "search sucks" is probably a PK backend issue.
14:56:06 <Kevin_Kofler> Or does gnome-pk work better there?
14:56:12 <jreznik> rdieter: the must list sounds really great but it should be upstream list of the must...
14:56:13 <rdieter> yep
14:56:25 <Kevin_Kofler> The unsigned packages bug sucks a lot, this keeps being broken all the time.
14:56:33 <rdieter> jreznik: of course, once we have a firmer list of requirements, I'll definitely send them upstream
14:56:35 <Kevin_Kofler> Upstream surely knows about it by now.
14:56:46 <Kevin_Kofler> I have no idea why they can't manage to fix it.
14:56:56 <Kevin_Kofler> I think the current issue is not the same as the original one.
14:57:05 <Kevin_Kofler> But the effect is that it's still/again broken.
14:57:11 <jreznik> Kevin_Kofler: it need more force - we need this to ship it...
14:57:15 <rdieter> Kevin_Kofler: only one maintainer, and he's a bit busy these days...it seems.
14:58:23 <ltinkl> do what's the concensus, go with kpk or gnome-pk in F13?
14:58:24 <rdieter> anyway, it's also heresy, but that's why I also listed bluetooth on the wiki as well.
14:58:29 <ltinkl> s/do/so
14:58:39 <rdieter> kbluetooth is (still) sorely lacking
14:58:46 <Kevin_Kofler> For Bluetooth: gnome-bluetooth drags in a lot of GNOME stuff, so I think it's either kbluetooth or no BT support at all.
14:59:04 <Kevin_Kofler> There's no room for all the gnome-bluetooth deps on the live image.
14:59:10 <rdieter> ltinkl: I don''t want a consensus yet, let's focus on a list of requirements for our nm frontend... and we'll simply match up what works best to meet those
14:59:34 <ltinkl> rdieter: ok, sounds reasonable, besides we still have time for the decision
14:59:41 <rdieter> Kevin_Kofler: consider also kde-desktop comps group too
14:59:42 <Kevin_Kofler> IMHO, we should make all these F13Target bugs, but switching frontends is not an option.
14:59:59 <Kevin_Kofler> (for PK, but also for the others)
15:00:01 <rdieter> you'd rather blindly use a kde app that's broken ?
15:00:17 <Kevin_Kofler> We've been shipping KPK all this time.
15:00:23 <Kevin_Kofler> We don't want to go backwards.
15:00:41 <rdieter> I know, it's time to accept the fact that kpk... sucks.  no way around the truth
15:00:44 <Kevin_Kofler> Unsigned packages not working is not a new issue.
15:00:57 <Kevin_Kofler> The other stuff, I don't know.
15:01:12 <Kevin_Kofler> If multiple restart notifications are that big an issue, we can just #if 0 the restart notifications entirely.
15:01:15 <Kevin_Kofler> Who needs them anyway?
15:01:17 <jreznik> no bt is not an option in this cell phone age (but yes, that's problem to fit live image)
15:01:33 <Kevin_Kofler> jreznik: Then make kbluetooth work. ;-)
15:01:34 <ltinkl> let's see if they (kpk) can improve the stuff, we can vote about it later
15:01:44 <rdieter> restart notifcations are fixed (for me anyway), but heck, kpk hasn't been working for > month now, so I can't even try to test it
15:02:30 <ltinkl> rdieter: same here, I gave up :/
15:02:49 <ltinkl> most of the time kpk doesn't even pop up when there are updates
15:02:59 <rdieter> indeed! (and why I'm ranting)
15:03:01 <ltinkl> and those times it does, it usually fails to install the packages
15:03:23 <patrickian> hey,
15:03:29 <patrickian> which meeting is it now?
15:03:31 <adamw> patrickian: kde folks are still meeting
15:03:36 <adamw> patrickian: we'll wait for 'em to finish
15:03:44 <patrickian> adamw: thank you
15:03:46 <rdieter> anyway, we're out of time, I'll work to move that aforementioned wiki into the kde-sig namespace somewhere, and we can edit going forward
15:03:56 <rdieter> thanks everyone
15:03:59 <rdieter> #endmeeting