15:03:55 <rdieter> #startmeeting kde-sig -- http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2011-09-06
15:03:55 <zodbot> Meeting started Tue Sep  6 15:03:55 2011 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:55 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:04:01 <rdieter> #meetingname kde-sig
15:04:01 <zodbot> The meeting name has been set to 'kde-sig'
15:04:09 <rdieter> #topic roll call
15:04:14 <rdieter> hola, who's present today?
15:04:25 * rnovacek is present
15:04:28 * nucleo present
15:04:43 * jreznik is here
15:05:08 <rdieter> than said he'd be a little late
15:05:19 <Kevin_Kofler> Present.
15:05:57 <rdieter> #chair rnovacek  nucleo  jreznik than Kevin_Kofler
15:05:57 <zodbot> Current chairs: Kevin_Kofler jreznik nucleo rdieter rnovacek than
15:06:06 <rdieter> #info rdieter rnovacek  nucleo  jreznik Kevin_Kofler  present
15:06:31 <rdieter> #info than will be a little late
15:06:39 <rdieter> #topic agenda
15:06:58 <rdieter> since we're lame and don't have any wiki or agenda for awhile... :)
15:07:08 <rnovacek> 4.7.1 status?
15:07:36 <rdieter> than sent some good ideas:  kde-4.7.1, qt-4.7.4, kdeedu split packaging reviews
15:08:04 <rdieter> anything else for today
15:08:06 <rdieter> ?
15:08:15 <rdieter> #info ltinkl present too
15:08:17 <nucleo> .bug 731269
15:08:19 <zodbot> nucleo: Bug 731269 Warning about nepomuk not running pops up on boot of F16 Alpha RC5 KDE live - https://bugzilla.redhat.com/show_bug.cgi?id=731269
15:08:30 <Kevin_Kofler> https://svn.reviewboard.kde.org/r/6794/
15:08:57 <nucleo> disable Nepomuk and patch warnings to not appear?
15:08:59 <rdieter> Kevin_Kofler: woo!
15:09:26 <rdieter> ok, all good, let's get started
15:09:34 <Kevin_Kofler> FYI, I want to make a version (which will actually be much smaller) supporting both the new Phonon method and the old xine-lib one.
15:09:39 <Kevin_Kofler> For use in F14 and F15 updates.
15:09:48 <Kevin_Kofler> That way we won't break the feature for phonon-xine users.
15:09:59 <Kevin_Kofler> From F16 on, phonon-xine is dead and gone.
15:10:05 <rdieter> #topic kde-4.7.1
15:10:07 <jreznik> Kevin_Kofler: nice!
15:10:37 <rdieter> than reported "mostly are already comitted in git, the rest should be done today or by tomorrow."
15:10:37 <Kevin_Kofler> I shall add that the patch needs testing, right now I haven't even verified that it compiles. ;-)
15:11:15 <Kevin_Kofler> That's great, 4.7.1 FTW. :-)
15:12:10 <Kevin_Kofler> Something in me wants to restart the "push to F15?" debate at every 4.7.x release (so now would be the next time), but then again it's probably a waste of everyone's time. ;-)
15:12:53 <Kevin_Kofler> I suppose it will end up in the kde47 repo though, right rdieter?
15:13:12 <jreznik> btw, I've been to release team meeting @ BDS
15:13:25 <jreznik> the new plan is to have less minor updates
15:13:42 <jreznik> and 4.x.1 coming really soon after 4.x.0
15:14:05 <rdieter> afk
15:14:15 <Kevin_Kofler> WTF?! Why?!
15:14:28 <Kevin_Kofler> One update per month was fine!
15:14:45 <jreznik> Kevin_Kofler: advise from gnome guy...
15:14:59 <Kevin_Kofler> Are other distros asking for that, or are distro needs being entirely ignored now?
15:15:17 <rnovacek> less minor updates means more work w/ backporting patches
15:15:24 <jreznik> Kevin_Kofler: no one from distros was agains, I came late for discussion
15:15:28 <Kevin_Kofler> (I'd guess the latter, seeing how kdelibs 4.8 was canceled only because they thought that 3 branches were "not nice". Very stupid.)
15:15:32 <ltinkl> indeed, the 1 month minor update frequency was fine
15:16:03 <jreznik> it makes sense to have the first update soon after release - to fix the top bugs
15:16:11 <Kevin_Kofler> They only care about the convenience of the core group of developers, any other contributors, distributors and users are getting ignored entirely in their scheduling. :-(
15:16:49 <Kevin_Kofler> jreznik: It makes no sense whatsoever. It's no use doing another release right after the .0 release, without the time to actually FIX things.
15:16:52 <rdieter> back sorry.  Kevin_Kofler, I'm definitely in favor of integrating your dragon patch asap
15:17:26 <Kevin_Kofler> Most regressions aren't even FOUND until ~2 weeks after the .0 release.
15:17:30 <jreznik> Kevin_Kofler: of course - with fixes - the most important and annoying ones - but then I'm for the old schedule
15:17:37 <rdieter> wrt upstream release schedules, I'm not aware of anything changing short-term, but we can discuss it more later, if you want, but let's try to finish our existing agenda first please.
15:17:54 <jreznik> rdieter: ok, sorry (just I wanted to say it :)
15:17:58 <Kevin_Kofler> (Even less so now that we don't push the stuff as stable updates. When we did, the issues were found when we pushed the stuff to stable, at least.)
15:18:35 <rdieter> move on?  anything else 4.7.1-wise?
15:18:56 <jreznik> just if than needs a hand to help, I can do it
15:19:30 <rdieter> oh, to be clear, once 4.7.1 is all built and happy for rawhide, I can start working on f15/kde47 repo builds
15:19:39 <jreznik> rdieter: thanks
15:19:45 <rdieter> #topic qt-4.7.4
15:20:22 <rdieter> qt-4.7.4 was released this past week, it's imported/built for f14/f15.
15:20:30 <rdieter> I was about to throw it into kde-testing repo
15:20:39 <jreznik> I expect no problems, correct?
15:20:53 <rdieter> *should* be safe, yeah
15:21:08 <rdieter> it's release notes mention qtquick-1.1 update though
15:21:10 <Kevin_Kofler> Yes, it's a bugfix release, it should be pushed to F14/F15 official updates ASAP.
15:21:20 <Kevin_Kofler> Who actually uses Qt Quick? ;-)
15:22:02 <jreznik> Kevin_Kofler: /me :)
15:22:04 <Kevin_Kofler> Qt rules for point releases are quite strict, it should definitely be appropriate as a bugfix update.
15:22:05 * rdieter agrees
15:22:12 <jreznik> +1
15:22:21 <rdieter> who wants the task the submit the update?
15:22:23 <jreznik> in Fedora, nobody uses Qt Quick right now, so
15:23:10 * rdieter won't have much time today unfortunately
15:23:16 <jreznik> I can do it
15:23:35 <rdieter> #action jreznik to submit qt-4.7.4 updates
15:23:37 <rdieter> thanks
15:24:07 <jreznik> should recheck our bugs against 4.7.4 changelog
15:24:30 <rdieter> #topic kdeedu package split reviews, https://bugzilla.redhat.com/showdependencytree.cgi?id=656997&hide_resolved=1
15:25:14 <rdieter> mostly an fyi thing, I worked last week on split kdeedu packaging, they're all in pkg review queue awaiting love.
15:25:33 <jreznik> wow, so many reviews... I can make some love with it this week I guess
15:25:34 <rdieter> (and for testing purposes, these split builds are all in kde47 repo already)
15:25:43 <rdieter> jreznik: :)
15:26:11 <rnovacek> I'll take few review this week too
15:26:30 <rdieter> ideally, they'd get reviewed/imported prior to 4.7.1, but we'll make do if not
15:27:00 <jreznik> note: kdeutils respined (about right now)
15:27:17 <rdieter> fwiw, there's the telepathy-kde stack awaiting review too, but that's less-pressing, just a nice-to-have thing
15:28:27 <jreznik> rdieter: btw, thanks for telepathy-qt4, I forgot completely... another piece for makneto in fedora
15:28:49 <rdieter> speaking of which, I'll be leaving on a trip and will be away fedora-wise for ~1 week starting tomorrow morning, so if anyone in kde-sig would be willing to take ownership of the pkg submissions for review purposes, that would be a-ok with me.
15:29:13 <rdieter> we'll likely all be comaintaining most/all of that stuff in the end anyway...
15:30:41 <jreznik> rdieter: ok
15:30:47 <rdieter> #topic open discussion
15:30:50 <jreznik> enjoy your trip
15:31:28 <rdieter> #undo
15:31:28 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x1613d18c>
15:31:39 <rdieter> #topic https://bugzilla.redhat.com/show_bug.cgi?id=731269 "nepomuk startup warnings"
15:31:50 <nucleo> There are problems with performanse on F16 LiveCD after enabling Nepomuk because of high CPU usage by virtuoso-t (26%) and nepomukservices (49%) just after LiveCD start. So manybe it is makes sense to disable Nepomuk (as it was before) and patch warnings to not appear?
15:32:28 <rdieter> I'm not entirely satisfied with the current live setup here.  init'ing the nepomuk db kills performance. ;(
15:32:58 <rdieter> and, I've long-hated those largely-useless nepomuk warnings anyway...
15:33:17 <nucleo> Other applications (not from kdepim) that uses Nepomuk works without such warnings if Nepomuk disabled.
15:33:36 <jreznik> surpress warnings on live, make nepomuk by default after installation?
15:34:09 <Kevin_Kofler> That'd be the same as F15 except for suppressing the warning, which we didn't have to do in F15 because Akonadi wasn't started up on Plasma startup.
15:34:19 <nucleo> warnings unnecessary in general
15:34:41 <rdieter> suppressing warnings would require patching, and we could implement it in a way that's only for the live image sure.
15:34:48 <Kevin_Kofler> Well, upstream Akonadi thinks the warning is important, they wouldn't show it otherwise.
15:35:22 <rdieter> something possibly upstreamable would be some sort of "don't show this warning again" option, which we'd enable on live of course.
15:35:26 <rnovacek> But it shows warning event when akonadi is not used
15:35:55 <rdieter> cause re-showing it over and over again, is so cool. (not)
15:35:58 <jreznik> rdieter: that would work for me, still not ok on live
15:36:24 <jreznik> rdieter: and on slow machines several nepomuk warnings in one time looks like slow motion movie
15:36:51 <Kevin_Kofler> jreznik: We'd init the config on the live CD to make it think "Don't show this warning again" has already been checked.
15:36:54 <rdieter> yup :(  I've already read several online reviews of f16/kde about how "slow" it is.  this is probably a major culprit
15:38:02 <rdieter> anyway, so to spell it out, my proposal is:  1.  disable nepomuk on live image (ie, back the way it was)  2. implement patch to disable akonadi/nepomuk warnings at runtime
15:38:41 <rnovacek> rdieter: +1
15:39:35 <Kevin_Kofler> Well, Akonadi will not be fully functional with that setup.
15:39:54 <Kevin_Kofler> And I wonder whether disabling Nepomuk will be sufficient to get back to F15's performance.
15:39:56 <rdieter> anyone wanting to do akonadi + searching on a live image is in a world of pain anyway.
15:40:02 <Kevin_Kofler> F15 also didn't start up Akonadi by default.
15:40:25 <Kevin_Kofler> Now it's getting autostarted in F16, which is why we had the "no Nepomuk" warning in the first place.
15:40:55 <rdieter> you'd see the error on f15 too, if you ran any app that poked address books (like konversation)
15:41:41 <Kevin_Kofler> I'm casting a 0 vote, I don't really care about what solution we pick as long as our users aren't spammed with a warning about our default configuration when they start the live image.
15:41:46 <jreznik> the thing is we probably don't need akonadi for live neither - as the live is more installation source than anything to be used everyday...
15:42:05 <Kevin_Kofler> rdieter: Right. The difference is that now Plasma autostarts Akonadi.
15:42:17 <Kevin_Kofler> And so I wonder how much of the performance problem is Nepomuk and how much is Akonadi.
15:42:40 <rdieter> akonadi itself should be a lot less now, using sqlite vs using mysql prior
15:42:46 <jreznik> Akonadi is problem when you have a lot of data there (eg. my imap folder)
15:42:58 <Kevin_Kofler> jreznik: The thing is, I have no idea how to prevent Akonadi startup.
15:43:07 <Kevin_Kofler> rdieter: Ugh, well, FWIW, I think that's also a very bad default.
15:43:12 <Kevin_Kofler> Upstream is defaulting to MySQL for a reason.
15:43:31 <nucleo> I thought akonadi started in F15 even when Nepomuk disabled
15:43:46 <nucleo> just after KDE start
15:43:51 <Kevin_Kofler> nucleo: Akonadi was started on demand by kdepim apps only.
15:43:56 <Kevin_Kofler> It wasn't started on Plasma startup.
15:44:07 <than> without akonadi and nepomuk kde works very smooth on slow old laptop
15:44:28 <than> imo both should be diable on live cd
15:44:45 <rnovacek> why it's started by plasma now?
15:45:01 <nucleo> Kevin_Kofler: for me akonadi started just after startup even if I not run kdepim apps
15:45:09 <rnovacek> start when required is much better
15:45:26 <rdieter> afk again (sorry)
15:45:27 <nucleo> I never saw see message "Starting akonadi" in F15
15:46:14 <than> rnovacek: or start when the user enable it
15:46:23 <jreznik> nucleo: there's no "starting akonadi" message anymore
15:46:31 <rnovacek> than: at least that
15:46:32 <jreznik> (at least I haven't seen it for ages)
15:47:00 <Kevin_Kofler> nucleo: On the live image, it didn't start up on Plasma startup.
15:47:01 <rnovacek> I really don't know why somethink start by default when a lot of people don't even use it
15:47:09 <Kevin_Kofler> Maybe this got changed in a post-release update.
15:47:11 <ltinkl> there's an "addressbook" and nepomuk krunner
15:47:15 <ltinkl> for alt+f2
15:47:29 <ltinkl> the latter seems to be enabled by default
15:47:30 <Kevin_Kofler> I know for sure that this "Nepomuk not running" warning from Akonadi didn't show up in F15 KDE Live.
15:48:31 <Kevin_Kofler> rnovacek: Because some people use it and the stuff they use doesn't work if the services aren't running.
15:48:49 <rnovacek> Kevin_Kofler: but when I disabled nepomuk on my laptop (f15) it shows the warning
15:49:25 <Kevin_Kofler> I think Plasma now starts Akonadi because the clock plasmoid looks up the Akonadi calendar for current tasks to display in its popup.
15:49:29 <Kevin_Kofler> That's a nice new feature.
15:49:37 <Kevin_Kofler> But it requires Akonadi on system startup.
15:49:44 <rnovacek> Kevin_Kofler: then the services should start when required, or at least it can be disabled
15:49:53 <Kevin_Kofler> (I guess that feature is new in 4.7.)
15:50:13 <Kevin_Kofler> Akonadi can already start on demand.
15:50:20 <rnovacek> Kevin_Kofler: yes, calendar intergration is nice
15:50:25 <Kevin_Kofler> The problem is that the demand is triggered by something as simple as the clock plasmoid.
15:50:35 <Kevin_Kofler> So there's effectively always demand.
15:50:43 <Kevin_Kofler> Which is why Akonadi always starts now.
15:51:23 <nucleo> No warning about not running Nepomuk on F15 LiveCD but akonadi started just after started KDE.
15:51:29 <Kevin_Kofler> Nepomuk is another story, but even if it did start on demand (which it doesn't), it would probably be triggered by Akonadi on system startup too.
15:52:41 <nucleo> there are akonadi* processes
15:52:49 <rnovacek> so getting rid of that warning seems like ideal solution
15:53:22 <Kevin_Kofler> Huh? Maybe F15's Akonadi had the warning silenced somehow?
15:53:41 <nucleo> warnings only with kdepim2
15:54:06 <Kevin_Kofler> Oh, I see, it's some Akonadi plugin from kdepim-runtime which has the warning.
15:54:15 <rnovacek> or it can check if user disabled nepomuk manually (like liveCD) and don't show warning in that case
15:54:20 <Kevin_Kofler> It got silenced in 4.4 after users complained.
15:54:34 <Kevin_Kofler> But it's back in 4.6/4.7.
15:55:21 <rdieter> Kevin_Kofler: lame. :(
15:55:56 <Kevin_Kofler> Still, it surprises me that Akonadi was already running on system startup in F15, I thought it was on demand.
15:56:03 <Kevin_Kofler> I guess they changed that in preparation for kdepim 4.6.
15:56:20 <Kevin_Kofler> Or maybe it's already triggered by Plasma (clock plasmoid?) in kdebase-workspace 4.6.
15:56:52 <rdieter> wrt akonadi using sqlite vs mysql... as a reminder, on my TODO list is to work on making switching default backend easier at runtime (which is virtually impossible now, only done via buildtime switch)
15:57:53 <rdieter> having that would help... cause we then could default to mysql backend, and switch to sqlite as needed (ie, like on live image, nfs setups, etc...)
15:59:26 <rdieter> anyway, we're running short on time... any other actionable proposals besides what I made then?
16:00:10 <jreznik> rdieter: I like your proposals
16:00:20 <rnovacek> me too
16:01:10 <rdieter> ok, while we're at it, anyone able/willing to work on part 2, the patch to optionally silence the aknoadi/nepomuk warnings?
16:01:33 * rdieter won't be able to start looking at it for another week or 2...
16:01:39 <rnovacek> I can try tomorrow
16:02:05 <rdieter> rnovacek: thanks!
16:02:16 <rdieter> well, we're really out of time now.  thanks everyone.
16:02:18 <rdieter> #endmeeting