14:02:33 <jreznik> #startmeeting kde-sig -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-05-11
14:02:33 <zodbot> Meeting started Tue May 11 14:02:33 2010 UTC.  The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:33 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:02:45 <jreznik> #meetingname kde-sig
14:02:45 <zodbot> The meeting name has been set to 'kde-sig'
14:03:09 <jreznik> #chair Kevin_Kofler than ltinkl rdieter SMParrish
14:03:09 <zodbot> Current chairs: Kevin_Kofler SMParrish jreznik ltinkl rdieter than
14:03:22 <jreznik> #topic roll call
14:03:36 <jreznik> who's present today?
14:03:45 * SMParrish here
14:04:03 * thomasj_ here
14:04:04 <Kevin_Kofler> Present.
14:04:14 * than is present
14:04:53 * ltinkl is present
14:05:11 <jreznik> #info jreznik than SMParrish thomasj_ Kevin_Kofler ltinkl present
14:05:34 <jreznik> #topic agenda
14:05:51 <jreznik> anything more to be added to agenda?
14:06:02 <jreznik> install dirs for apidocs?
14:06:23 <thomasj_> good idea
14:07:20 <Kevin_Kofler> +1
14:07:34 <jreznik> why we have "List of critical KDE packages for new update policy" again?
14:07:47 <jreznik> I think I can remove it as we agreed last week
14:07:55 <Kevin_Kofler> +1, remove, we already decided this.
14:08:25 <SMParrish> I thought we agreed as well so it should not be on this weeks agenda
14:08:47 <jreznik> ok, anything else? so we can start?
14:09:25 <jreznik> I'll start with 4.4.3 update status, will be quick
14:09:36 <jreznik> #topic 4.4.3 update status
14:09:58 <Kevin_Kofler> So than is taking care of kde-l10n, then ltinkl will prepare Bodhi updates.
14:10:10 <ltinkl> Kevin_Kofler: I am taking care of that
14:10:17 <Kevin_Kofler> Anything else?
14:11:14 <jreznik> #action than to respin and build kde-l10n
14:11:29 <jreznik> #action ltinkl to prepare Bodhi update
14:11:40 <than> jreznik: lukas is taking of kde-l10n
14:12:19 <jreznik> #action ltinkl to respin and build kde-l10n and to prepare Bodhi update
14:12:20 <ltinkl> kde-l10n are already being built as we speak, FYI
14:12:21 <jreznik> than: ok
14:12:37 <jreznik> I think it's all for this topic
14:12:49 <Kevin_Kofler> than, ltinkl: As long as you guys agree on who does what, it's fine with me. :-)
14:13:12 <than> Kevin_Kofler: we will take care of it ;-)
14:13:24 <Kevin_Kofler> Move on please.
14:13:37 <jreznik> just it has to be done :D
14:13:53 <jreznik> #topic Duplicate menu entries
14:14:04 <jreznik> #link https://bugzilla.redhat.com/show_bug.cgi?id=591089
14:14:24 <Kevin_Kofler> #link https://bugzilla.redhat.com/show_bug.cgi?id=591093
14:14:34 <Kevin_Kofler> #link https://bugzilla.redhat.com/show_bug.cgi?id=591097
14:14:56 <Kevin_Kofler> So there are 4 questions:
14:14:57 <Kevin_Kofler> Do we consider these bugs?
14:15:00 <Kevin_Kofler> Or do we want to follow upstream and keep the dupes where upstream has them?
14:15:04 <Kevin_Kofler> If we consider them bugs, do we want to fix these in updates? Or only in new releases?
14:15:19 <Kevin_Kofler> Do we want these to be blockers for F14? The GNOME folks consider these release blockers.
14:15:26 <jreznik> the question is - why upstream ships dupes? do they know? is that an intention to ship it?
14:15:43 <than> in my opinion it's a bug
14:15:48 <than> and should be fixed
14:15:53 <SMParrish> IMO they are more annoyances than bugs, certainly not blockers.
14:15:57 <Kevin_Kofler> That's a good question. For Okular, Sho_ has asked upstream, but I think he hasn't replied yet.
14:16:04 <Kevin_Kofler> (Sho_ just asked a few minutes ago.)
14:16:54 <nucleo> and skanlite appears twice
14:17:35 <Kevin_Kofler> I propose we should point these out to the respective upstreams, but if upstream says they want it that way, we should keep it.
14:17:38 <jreznik> SMParrish: +1, not a blocker
14:17:52 <Kevin_Kofler> Though it looks a bit strange.
14:17:53 <jreznik> Kevin_Kofler: yes, +1, preferred way
14:17:59 <Kevin_Kofler> But a release blocker? WTF?
14:17:59 <SMParrish> Kevin_Kofler: I agree +1
14:18:36 <ltinkl> SMParrish: what was the bug nr. again?
14:18:46 <than> it's not  blocker bug
14:18:54 <Kevin_Kofler> 591089, 591093, 591097
14:19:03 <Kevin_Kofler> And these are only the ones on the live image.
14:19:07 <ltinkl> menu items appearing twice might be a result from a not completely updated sycoca
14:19:11 <Kevin_Kofler> E.g. Skanlite has no such bug filed AFAIK.
14:19:21 <Kevin_Kofler> ltinkl: No.
14:19:27 <jreznik> ltinkl: it's on live cd
14:19:29 <Kevin_Kofler> Those come from multiple categories in the .desktop files.
14:19:30 <thomasj_> Another question might be, why do the GNOME guys handle it as release blocker. I guess there's a reason.
14:19:40 <ltinkl> Kevin_Kofler: ah k
14:19:53 <jreznik> thomasj_: you try to find reasons in gnome? :D
14:19:58 <ltinkl> xD
14:20:01 <thomasj_> Not really ;)
14:20:18 <thomasj_> Though, would be interesting why
14:20:19 <Kevin_Kofler> I guess they think it looks unpolished.
14:20:20 <ltinkl> I don't find it that illogical to have some apps on 2 categories tbh
14:20:55 <thomasj_> +1
14:21:18 <jreznik> for some apps there can be some logic to be listed in more cats...
14:21:27 <ltinkl> indeed
14:21:46 <ltinkl> and the menu spec explicitely allows that
14:22:34 <Kevin_Kofler> So I think we have agreement for my proposal (report upstream, follow upstream's decision, don't treat it as a release blocker in any case)?
14:22:47 <rdieter> Kevin_Kofler: yes
14:22:53 <jreznik> Kevin_Kofler: +1
14:23:13 <ltinkl> Kevin_Kofler: +1
14:23:30 <jreznik> than, SMParrish: ^^?
14:23:37 <SMParrish> +1
14:23:46 <than> it's fine with me
14:23:51 <jreznik> ok, five votes
14:24:15 <Kevin_Kofler> +1 from myself obviously.
14:24:22 <jreznik> #agreed on Kevin Kofler's proposal - report upstream, follow upstream's decision, don't treat it as a release blocker
14:24:47 <jreznik> Kevin_Kofler: ;-) sorry I didn't count you in :D
14:25:13 <jreznik> anything else to the topic? or we can move on?
14:25:18 <Kevin_Kofler> Next: apidocs?
14:25:23 <jreznik> #topic Default install paths for apidocs
14:26:16 <jreznik> the question is where should we install apidocs by default?
14:26:23 <jreznik> currently it's a mess
14:26:38 <jreznik> needed for example for Grantlee #link https://bugzilla.redhat.com/show_bug.cgi?id=583058
14:26:51 <Kevin_Kofler> So I think the #1 requirement is that the directory should not be version-specific (i.e. Soprano needs fixing).
14:27:05 <jreznik> indeed
14:27:07 <Kevin_Kofler> Because it's a PITA to have to update links, and it also breaks the browser history.
14:27:26 <ltinkl> not entirely persuaded about this, think qt3 vs. qt4 apidocs
14:27:29 <ltinkl> different stuff
14:27:30 <jreznik> only in case it's a new version and we support old one of course
14:27:31 <Kevin_Kofler> I think I'm the one at fault for the Soprano mess, I'll take the blame and I'm OK with fixing it.
14:27:47 <Kevin_Kofler> ltinkl: By "version-specific", I mean that we don't want qt-4.6.2-apidocs.
14:27:50 <jreznik> #action Kevin_Kofler to fix Soprano "mess"
14:27:53 <Kevin_Kofler> But qt4-apidocs, sure.
14:27:55 <ltinkl> Kevin_Kofler: ok
14:27:56 <Kevin_Kofler> :-)
14:28:27 <jreznik> all: ok with not to be version specific?
14:28:36 <Kevin_Kofler> jreznik: But before I can fix it, I need to know what to fix it to. :-)
14:28:39 * ltinkl nods
14:28:41 <thomasj_> +1 ok with it
14:28:58 <jreznik> Kevin_Kofler: of course - that's why I'm asking now :D
14:29:16 <jreznik> than, SMParrish, rdieter: ?
14:30:10 <SMParrish> +1 from me
14:30:15 <than> +1
14:30:19 <rdieter> I agree with fixing these to be in common/expected locations
14:30:21 <rdieter> +1
14:30:33 <Kevin_Kofler> Not version-specific just tells me what not to do, I still need to know what to do. :-)
14:30:38 <jreznik> the question now is version specific
14:30:46 <jreznik> Kevin_Kofler: step by step
14:31:07 <jreznik> #agreed apidocs not to be installed to version specific directories
14:31:16 <rdieter> similarly, I was just pinged in #kde-devel if we could fix this mild docbook insanity:  /usr/share/sgml/docbook/xml-dtd-4.2-1.0-50.fc13/catalog.xml
14:31:23 <jreznik> now the question is - where's the correct location for unversioned staff?
14:31:37 <rdieter> seems most other distros have this in a common/expected location too
14:32:05 <than> rdieter: it does make sense here
14:34:20 <jreznik> and what the common/expected location should be?
14:34:50 <rdieter> jreznik: I'd suggest simply, /usr/share/doc/<pkgname>/ , or alternatively, /usr/share/doc/HTML/en/<pkgname>
14:35:36 <Kevin_Kofler> rdieter: What about stuff which has both end user help and apidocs?
14:35:47 <jreznik> -apidocs suffix?
14:36:16 <rdieter> jreznik: +1 <pkgname>-apidocs make sense, I can't think of anything better. :)
14:36:47 <rdieter> assuming if keeping them both in the same location has a risk of conflicts
14:37:25 <Kevin_Kofler> So currently we have:
14:37:27 <Kevin_Kofler> /usr/share/doc/HTML/en/kdelibs4-apidocs
14:37:30 <Kevin_Kofler> /usr/share/doc/HTML/en/kdepimlibs-apidocs
14:37:37 <Kevin_Kofler> /usr/share/doc/soprano-apidocs-2.4.1/html
14:38:03 <Kevin_Kofler> We obviously want to drop the -2.4.1 from Soprano.
14:38:19 <Kevin_Kofler> But that still doesn't leave us with something consistent.
14:38:43 <jreznik> on the other hand - it's easier to find it in doc/app-apidocs/html
14:38:54 <Kevin_Kofler> Also to be discussed: at least kdelibs allows building apidocs in QCH (Qt Assistant since Qt 4.4) format, do we want to provide those? Or just HTML?
14:39:07 <Kevin_Kofler> At the moment we're building only the plain HTML.
14:39:14 <jreznik> Qt assistant is nice think
14:39:30 <Kevin_Kofler> If we build the QCH, we'll need a place for that too.
14:39:36 <jreznik> if we can support it - would be great... but first let's answer the location problem
14:40:08 <thomasj_> Maybe /usr/share/docs/apidocs/<app>
14:40:26 <rdieter> %qt4_docdir points to /usr/share/docs/qt4
14:40:35 <Kevin_Kofler> Who would own /usr/share/docs/apidocs?
14:40:49 <thomasj_> kdelibs?
14:40:52 <rdieter> kde-filesystem
14:40:55 <thomasj_> better
14:41:16 <jreznik> but it again hides it under one more directory
14:41:32 <Kevin_Kofler> We also need to make sure that kdevelop supports whatever location we choose, or patch it if it doesn't.
14:41:32 <jreznik> I'm usually looking at doc/ first
14:41:53 <Kevin_Kofler> BTW, it might also not support our current location, have we even tested that?
14:42:12 <rdieter> this is all for kdevelop support?  how about we look at it and it's code first, to see what it does now
14:42:30 <thomasj_> Currently for grantlee
14:42:33 <rdieter> it may be worth simply adapting to what it expects, if it makes sense
14:42:34 <jreznik> not only for support but for some consistency
14:42:44 <jreznik> rdieter: it makes sense
14:43:06 <jreznik> anyone experienced in kdevelop and docs to look on it?
14:43:11 <rdieter> I meant ... if kdevelop's expectation wrt doc location makes sense
14:43:27 <rdieter> but yeah
14:43:59 <rdieter> I'm not experienced using it by any means, but I can probabably figure it out, if no one else steps up to do it
14:44:47 <Kevin_Kofler> Looking at KDevelop definitely makes sense.
14:45:23 <jreznik> ok, so let's postpone it to next meeting... thomasj_ is it ok for you to wait with grantlee?
14:47:18 <jreznik> #agreed on adapting to KDevelop needs
14:47:40 <jreznik> #action to check KDevelop locations for apidocs
14:48:01 <thomasj_> jreznik, sure, no problem
14:48:39 <jreznik> thomasj_: of course you can apply my patch, it should be easy to fix it later to correct location
14:49:04 <thomasj_> jreznik, i will add it anyways, but wait until it's decided with the next build.
14:49:12 <jreznik> #action check location status next week
14:49:21 <jreznik> thomasj_: great, thanks
14:49:40 <jreznik> anything else?
14:50:17 <jreznik> #action thomasj_ to apply apidocs patch to Grantlee, wait with the next build
14:50:48 <jreznik> moving on
14:50:55 <jreznik> #topic open discussion
14:51:34 <Kevin_Kofler> FYI, I'm trying to get a koffice-kivio package from KOffice 1.x to build and install in parallel with KOffice 2 for F13+.
14:51:47 <Kevin_Kofler> I've started work, it's not trivial, but I think I have a plan how to make it work.
14:51:55 <Kevin_Kofler> It may be taking me a couple days though.
14:52:01 <jreznik> ok, great
14:52:46 <jreznik> #info Kevin_Kofler trying to build and install in parallel koffice-kivio from KOffice 1.x with KOffice 2 for F13+
14:53:50 <Kevin_Kofler> Hopefully we'll have a KOffice 2 Kivio for F14, there's a GSoC project for it.
14:53:57 <Kevin_Kofler> I hope it won't end up delayed forever like Quanta.
14:54:19 <Kevin_Kofler> Quanta is now also a GSoC project, so it might finally get done.
14:54:24 <thomasj_> Reminds me to ask the koffice guys about dictionary integration
14:56:19 <jreznik> are we done today?
14:56:31 <Kevin_Kofler> I think we are.
14:56:37 <Kevin_Kofler> We're also almost out of time. :-)
14:56:39 <jreznik> thanks guys
14:56:48 <jreznik> #endmeeting