14:02:29 <rdieter> #startmeeting kde-sig -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-03-23
14:02:30 <zodbot> Meeting started Tue Mar 23 14:02:29 2010 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:02:33 <rdieter> #meetingname kde-sig
14:02:34 <zodbot> The meeting name has been set to 'kde-sig'
14:02:51 <rdieter> #chair Kevin_Kofler than jreznik
14:02:52 <zodbot> Current chairs: Kevin_Kofler jreznik rdieter than
14:02:59 <rdieter> #topic roll call
14:03:03 <rdieter> who's present today?
14:03:13 <Kevin_Kofler> Present.
14:03:24 * jreznik is present
14:03:54 * than is present
14:05:04 <rdieter> #topic building Soprano with QT_NO_DEBUG_OUTPUT?
14:05:07 <rdieter> Kevin_Kofler: ?
14:05:37 <Kevin_Kofler> So I used Soprano in an application I wrote for the university.
14:05:48 <rdieter> cool
14:05:54 <Kevin_Kofler> And I found that it spews tons of debugging output, especially from the Virtuoso backend.
14:06:07 <Kevin_Kofler> It uses qDebug directly, with no sane way to disable this at runtime.
14:06:23 <Kevin_Kofler> The only thing which can be done to filter the output is to install a Qt message handler in the client program.
14:06:35 <Kevin_Kofler> Libraries spewing debug messages is very annoying.
14:06:51 <Kevin_Kofler> Especially when you want to use them in console (QtCore/kdecore) apps.
14:07:09 <Kevin_Kofler> (and a library needs to be fit for all uses)
14:07:12 <than> Kevin_Kofler: is there an debug option to disable it ?
14:07:28 <Kevin_Kofler> So I'm suggesting to build it with QT_NO_DEBUG_OUTPUT, which will disable the qDebug messages.
14:07:41 <rdieter> I suppose there isn't any way to toggle this at runtime?
14:07:43 <Kevin_Kofler> (It won't affect qWarning etc. if they're used.)
14:08:12 <than> rdieter: i don't think it will work at runtime
14:09:06 <than> Kevin_Kofler: it's fine to disable it F11/F12/F13 but not in rawhide
14:09:09 <rdieter> ok, I guess the long-term solution is to poke upstream to get this handled more sanely
14:09:16 <Kevin_Kofler> rdieter: +1
14:09:28 <Kevin_Kofler> Because it's just as annoying for users of other distros.
14:09:33 <rdieter> short-term, QT_NO_DEBUG_OUTPUT is an ok option to me
14:09:47 <ltinkl> well I don't think there's other way to disable the qDebug messages
14:10:02 <Kevin_Kofler> than: Have you seen the kind of output it produces?
14:10:08 <ltinkl> other than what rdieter and Kevin_Kofler suggested
14:10:08 <Kevin_Kofler> It spits out:
14:10:19 <Kevin_Kofler> 1. the messages Virtuoso prints at startup
14:10:41 <than> Kevin_Kofler: not yet
14:10:50 <Kevin_Kofler> 2. the SparQL queries for every single call of some functions, such as removeAllStatements
14:10:51 <rdieter> of course, doing this will limit our ability to debug soprano-related prolbems
14:12:08 <jreznik> it's really verbose
14:12:21 <than> i take a look at ~/.xsession-errors. there re a lot of debugs infos!
14:12:23 <Kevin_Kofler> Disabling this stuff at compile time might also end up speeding up Nepomuk significantly.
14:12:31 <rdieter> I think we're mostly in agreement here, any objections to the plan as proposed?
14:12:44 <ltinkl> +1 disable debug messages
14:13:00 <ltinkl> it really shouldn't be in any end.user packages
14:13:11 <jreznik> +1 (are we really going to debug something on this level? I don't think so)
14:13:18 <than> +1 exclude rawhide
14:13:38 <rdieter> #agreed short-term build soprano with QT_NO_DEBUG_OUTPUT (except rawhide), long-term poke upstream to address this better
14:13:41 <jreznik> than: +1
14:13:47 <ltinkl> (and don't forget that when syncing from rawhide back :)
14:14:10 <rdieter> Kevin_Kofler: you want to work on implementing it?
14:14:11 <Kevin_Kofler> I wonder if we should set QT_NO_DEBUG_OUTPUT in some global place even.
14:14:13 <jreznik> ltinkl: condifional
14:14:23 <ltinkl> jreznik: even better :)
14:14:38 <Kevin_Kofler> I'm not convinced not doing it in Rawhide makes sense.
14:14:49 <Kevin_Kofler> We're likely to forget about this when F14 branches.
14:14:58 <rdieter> Kevin_Kofler: you mean like, building all qt-related stuff with QT_NO_DEBUG_OUTPUT too? (or something else?)
14:15:09 <jreznik> another question is - who is going to use it in rawhide
14:15:24 <Kevin_Kofler> rdieter: Yes, that's what I was wondering. But it's probably too hardcode. :-)
14:15:24 <than> jreznik: it's good question :)
14:15:32 <Kevin_Kofler> *hardcore
14:15:55 <jreznik> than: so maybe we even don't need it for rawhide too
14:16:11 <rdieter> that's probably too extreme now, I think we'd best doing so on a case-by-case basis for now
14:16:13 <jreznik> and in case someone experiencing bad issues - we can do custom scratch build
14:16:39 <jreznik> rdieter: that's why we should prefer long term solution
14:16:46 <jreznik> and do only most verbose apps
14:16:51 <rdieter> indeed
14:18:04 <than> it's fine with me to disable it for rawhide too
14:18:58 <than> if someone wants to debug stuff, just scratch build in this case
14:19:09 <Kevin_Kofler> OK. I'll take care of it.
14:19:18 <Kevin_Kofler> So can we move on now? :-)
14:19:21 <rdieter> yep
14:19:31 <rdieter> #topic KOffice 2.2 Beta for F13?
14:20:01 <rdieter> Kevin_Kofler proposed this.  probably not a bad idea.  I'd like ot test it bit first.
14:20:05 <Kevin_Kofler> So there are several reasons why we'd like 2.2 over 2.1:
14:20:07 <rdieter> I'll get builds into kde-unstable repo asap
14:20:08 <Kevin_Kofler> * Kexi is back
14:20:35 <Kevin_Kofler> * import filters for M$ stuff are improved (the Office "Open" XML ones are even entirely new)
14:21:18 <rdieter> http://wiki.koffice.org/index.php?title=Schedules/KOffice/2.2/Release_Plan
14:21:19 <jreznik> they said OOXML is in initial state but good to have it than nothing
14:21:26 <Kevin_Kofler> * spell checking in KWord is back, too
14:21:35 <than> it's nice to see more features in 2.2,  but important thing is stability ;-)
14:22:15 <rdieter> F13 final freeze is Apr 24, fyi
14:22:43 <rdieter> so will get at least beta2, rc1 if we're lucky
14:22:47 <than> when will  f13 be released?
14:22:57 <rdieter> http://fedoraproject.org/wiki/Schedule
14:23:01 <jreznik> I don't believe in rc1
14:23:01 <Kevin_Kofler> IMHO we should definitely go for 2.2.
14:23:38 <ltinkl> I think so too
14:23:53 <jreznik> but I'm with Kevin - it would be definitely better than 2.1 - there are lot of missing features and it's not as stable as I'd like to see (and I'm not office user)
14:24:18 * than really prefers stable koffce
14:24:27 <jreznik> I'm still not sure it's in shippable state at all (even 2.2)
14:25:18 <jreznik> but let's try 2.2 from kde-unstable - we can decide next meeting
14:25:30 <jreznik> no one even have tried it yet
14:25:54 <rdieter> I've been using koffice-2.1.x periodically for awhile, it's been pretty good
14:26:14 <rdieter> I'll get some builds going then, and we can see.
14:26:37 <Kevin_Kofler> I guess we can go with jreznik's plan: build 2.2 for kde-unstable, test it there, report back, decide next week.
14:26:45 <rdieter> I'll try to come up with a basic test-plan too (some basic tasks, open/save a file or too, maybe print)
14:27:06 <rdieter> Kevin_Kofler: yeah, so far, it's only been built in rawhide
14:27:25 <Kevin_Kofler> PRINT? Who wants to do THAT? ^^ ;-)
14:27:25 <than> Kevin_Kofler: the Question is how many user will test it?
14:27:37 <jreznik> I have some document test suite from dtardon from last time...
14:27:50 <jreznik> than: we have to...
14:27:58 <jreznik> I like rdieter
14:28:01 <jreznik> 's plan
14:28:12 <than> it's bad if only some users test it
14:28:20 <Kevin_Kofler> Soliciting user feedback on the ML would not be a bad idea either.
14:28:26 <rdieter> ok, I'll try to splat out a test-plan after meeting, and only if these basic tests/criteria pass, then we can consider using it
14:28:46 <jreznik> than: but as I said - 2.1 is really featureless, not very stable (from my few tries), so maybe 2.2 (even beta) would be better
14:29:18 <jreznik> who want's "stable" office still use oo.org
14:29:49 <Kevin_Kofler> Indeed. (KOffice 1 is quite buggy as well.)
14:29:50 <jreznik> 2.x is more for fun now - but I like the way how it's done - I hope it's going to be better than oo.org soon!
14:30:00 <than> perhaps we need to vote again for koffce ;-)
14:30:01 <rdieter> I really doubt we'll have anyone clamoring for us to keep koffice1 around (like with amarok1 vs amarok2 )
14:30:05 <Kevin_Kofler> If you ever tried to do charts with KOffice 1's KSpread, you'll know what I mean!
14:30:24 <jreznik> no - koffice 1, not 2 are not for real work
14:30:44 <jreznik> it's sad, but it's truth
14:31:20 <rdieter> #agreed rdieter will do some test builds for kde-unstable, document a test plan, solicit feedback.  defer decision at least a week
14:31:49 <rdieter> #topic Open discussion
14:32:04 <jreznik> it was quick today :)
14:32:39 <Kevin_Kofler> We probably forgot something important. ;-(
14:32:45 <rdieter> I think based on our recent target audience discussions (and feedback), I'll try to come up with some sort of response to the boards' official request for feedback, http://lists.fedoraproject.org/pipermail/kde/2010-February/005889.html
14:32:53 <than> ltinkl: does the backported patch fix the krunner crash?
14:33:04 <ltinkl> than: umm, which one?
14:33:20 * than is looking
14:33:54 <than> it's the one you built in kdelibs
14:34:00 <ltinkl> than: the pixmap cache fix?
14:34:05 <than> yes
14:34:20 <ltinkl> ye i think it does, based on the feedback in the BZ
14:34:21 <Kevin_Kofler> The pixmap cache fix fixes all the SIGBUS crashes in various KDE apps.
14:34:31 <Kevin_Kofler> Maybe also some of the SIGSEGV or other crashes, I'm not sure.
14:34:47 <ltinkl> Kevin_Kofler: time to push this into stable?
14:34:57 <Kevin_Kofler> I already did. :-)
14:35:01 <jreznik> ;-)
14:35:03 <ltinkl> ok, all clear then :)
14:35:14 <than> ltinkl: clear :)
14:35:36 <Kevin_Kofler> It went stable today (well, during the night).
14:35:47 <rdieter> speaking of common bugs, what about the qt/PyQt4 hp one?  anyone with the necessary *-fu to debug that on our team?
14:36:02 <ltinkl> Kevin_Kofler gets the cream for closing a bug with zillion duplicates and about 300 votes :)
14:36:07 <rdieter> https://bugzilla.redhat.com/show_bug.cgi?id=543286
14:37:05 <Kevin_Kofler> Well, there's a patch which fixes at least one of the crashes, but to me it looks like just papering over the symptoms and there are still sometimes crashes elsewhere even if that's applied.
14:37:40 <Kevin_Kofler> Somehow the display ends up being NULL while Qt is still in use and it really doesn't like that.
14:38:04 <Kevin_Kofler> Sounds like an order of destruction issue.
14:38:08 <rdieter> https://bugzilla.redhat.com/attachment.cgi?id=385716  ?
14:39:04 <rdieter> https://bugzilla.redhat.com/show_bug.cgi?id=543286#c16 posted here
14:39:28 <rdieter> well, if we don't have mojo here, suggestions on what else to do about it?
14:39:30 <Kevin_Kofler> Yes, that's the patch. That said, I think I remember incorrectly, I don't see any claim of other crashes.
14:39:34 <Kevin_Kofler> So maybe we should just apply that.
14:39:42 <Kevin_Kofler> Checking for a non-NULL display before using it can't hurt.
14:40:15 <rdieter> ok, baring any other suggestions, I'll test with and without the patch (after meeting).
14:40:19 <Kevin_Kofler> It might also not really fix things either, but it surely can't be wrong.
14:40:22 <than> Kevin_Kofler: tim already tested it, the patch doesn't fix the problem
14:40:41 <Kevin_Kofler> Other crashes elsewhere?
14:40:49 <than> no the same crash
14:41:05 <Kevin_Kofler> Huh? Weird.
14:41:41 <than> i will try to debug the problem
14:41:43 <Kevin_Kofler> https://bugzilla.redhat.com/show_bug.cgi?id=543286#c18
14:41:52 <Kevin_Kofler> From the stacktrace it looks like it's dpy which is NULL, not display.
14:42:40 <rdieter> #action than will try to debug bug #543286
14:42:44 <Kevin_Kofler> Though, wait, that's the same variable.
14:42:59 <Kevin_Kofler> It's just called dpy in the XFreeColormap parameter list.
14:43:40 <rdieter> any other topics to discuss today?
14:44:15 <than> Kevin_Kofler:  it doesn't crash at the line 210 if (display && colormap)
14:44:29 <than> Kevin_Kofler:  somewhere else
14:46:14 <rdieter> alright, let's close... thanks everyone.
14:46:22 <rdieter> #endmeeting