15:04:39 <rdieter> #startmeeting kde-sig -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2012-01-31
15:04:39 <zodbot> Meeting started Tue Jan 31 15:04:39 2012 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:04:39 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:04:43 <rdieter> #meetingname kde-sig
15:04:43 <zodbot> The meeting name has been set to 'kde-sig'
15:04:47 <rdieter> #topic roll call
15:04:53 <Kevin_Kofler> Present.
15:04:53 <rdieter> hi, who's present today?
15:04:58 <jreznik> rdieter was a half second faster :)
15:05:02 * jreznik is here
15:05:40 * rnovacek is here
15:05:53 <rdieter> #info rdieter Kevin_Kofler jreznik rnovacek present
15:06:00 <rdieter> #chair Kevin_Kofler jreznik rnovacek
15:06:00 <zodbot> Current chairs: Kevin_Kofler jreznik rdieter rnovacek
15:06:45 * ltinkl is here
15:06:56 <rdieter> than: ping
15:07:49 <rdieter> #info ltinkl here
15:07:50 <rdieter> #chair ltinkl
15:07:50 <zodbot> Current chairs: Kevin_Kofler jreznik ltinkl rdieter rnovacek
15:08:01 <rdieter> #topic agenda
15:08:31 <rdieter> ok, threw some quick topics together on the wiki so far: kde-4.8, live image, apidocs, gcc47
15:08:35 <rdieter> anything else for today?
15:09:10 * than is present
15:09:16 <rdieter> #chair than
15:09:16 <zodbot> Current chairs: Kevin_Kofler jreznik ltinkl rdieter rnovacek than
15:09:19 <rdieter> than: hi
15:09:27 <rdieter> #info than present
15:09:34 <than> rdieter: hi
15:10:15 <rdieter> ok, let's go with the agenda as-is then
15:10:24 <rdieter> #topic kde-4.8.0 status
15:10:59 <rdieter> should be all good to go 4.8.0-wise now in rawhide, jreznik wrestled kdesdk (antlr/java) into submission
15:11:19 <rdieter> our f16 kde48 repo is generally getting good feedback so far too
15:11:20 <jreznik> yep, it's built now
15:11:31 <jreznik> just trying the fixed antlr with kdesdk
15:12:14 <Kevin_Kofler> So, F16 updates-testing next? :-)
15:12:24 <ltinkl> yup, no problems at all so far
15:12:34 <jreznik> hint: next time, the epoch in java versions is the must :)
15:12:34 <jreznik> #info should be all good to go 4.8.0-wise now in rawhide, jreznik wrestled kdesdk (antlr/java)
15:12:37 <jreznik> #info f16 kde48 repo getting good feedback
15:12:42 <rdieter> Kevin_Kofler: we've still got several blockers, no?
15:13:08 <Kevin_Kofler> jreznik: For the kdesdk BR, we'll have to conditionalize the minimum version of Java per Fedora release.
15:13:19 <Kevin_Kofler> We can't require 1.7 on F16.
15:13:28 <rdieter> https://bugzilla.redhat.com/showdependencytree.cgi?id=765955&hide_resolved=1
15:13:31 <jreznik> Kevin_Kofler: I'm going to remove it
15:13:43 <Kevin_Kofler> rdieter: IMHO, those don't preclude pushing to testing, only to stable.
15:13:48 <rdieter> so, still have the powerdevil profile wierdness to re-test, and nepomuk config key migration
15:13:59 <jreznik> and let antlr bring the correct java (it's already built with 1.7, so it needs 1.7)
15:14:26 <rdieter> the ark thing... well that's more a nice-to-have, wouldn't argue to consider that a blocker really
15:14:26 <Kevin_Kofler> There's also the Ark+GwenViewPart image preview regression.
15:14:39 <Kevin_Kofler> Well, it's a regression…
15:15:55 <rdieter> so, I'm still of a mind to consider the 2 aforementioned issues blockers prior to even considering anything for f16.  And, i'd feel a little better simply waiting for 4.8.l as well.
15:16:41 <jreznik> anybody's going to work on the blockers?
15:16:53 <rdieter> i still get an occasional 'laptop won't sleep on lid close', though this may get attention and be fixed in 4.8.1
15:17:24 <ltinkl> rdieter: that works fine here, note there have been some kernel bugs regarding suspend/resume
15:17:29 <than> rdieter: i cannot reproduce this issue
15:17:47 <than> rdieter: it works fine on both laptop here
15:17:53 <rdieter> it only happens sometimes, and manually selecting kickoff->sleep works, it's just the lid close doesn't do it's thing
15:18:42 <rdieter> I'm not too worried about it, esp if others can't reproduce it then.
15:18:50 <than> rdieter: is it on f16 with latest kernel?
15:18:54 <rdieter> than: yes
15:19:13 <rdieter> the screen blanks, it just doesn't go to sleep, for whatever reason
15:20:00 <rdieter> anyway, anything else about 4.8 to mention?  move on?
15:20:31 <rdieter> well, hold, maybe to answer jreznik's query.  anyone want to work on the nepomuk config kconf script?
15:21:02 <rdieter> or, alternatively, we could choose to leave as-is, but i think i'd rather not
15:21:16 <jreznik> I'm sorry, I'm quite busy going to fosdem these days, ltinkl?
15:21:24 <rdieter> .bug 771053
15:21:26 <zodbot> rdieter: Bug 771053 new nepomuk config keys - https://bugzilla.redhat.com/show_bug.cgi?id=771053
15:21:48 <ltinkl> ugh, no idea about nepomuk
15:22:11 <ltinkl> I can have a look at the lid close bug, or the Ark/Gwenview regression
15:22:25 <rdieter> in short, 4.8 nepomuk uses 1 (or 2?) new kconfig keys for being enabled (or not)
15:22:29 <Kevin_Kofler> That kconf_update script should be straightforward, I can take care of it.
15:22:46 <rdieter> since it treats file indexing and mail indexing separately now
15:22:50 <jreznik> ok
15:22:57 <rdieter> (which is a 'good thing')
15:23:24 <jreznik> #action ltinkl to take a look on lid close bug and/or Ark/Gwenview regression
15:23:29 <Kevin_Kofler> Read the value of the old key, clone it into the 2 new keys, that's exactly what kconf_update is for.
15:23:31 <rdieter> ltinkl: don't worry about lid close, until I can get more useful debugging/data
15:23:37 <ltinkl> rdieter: ok
15:23:45 <jreznik> #action Kevin_Kofler to take a look on nepomuk config keys bug (#771053)
15:23:51 <ltinkl> rdieter: I'd start with the most recent kernel :)
15:24:04 <rdieter> ok, ltinkl, I may ping you a bit later :)
15:24:09 <ltinkl> sure
15:24:25 <rdieter> yay
15:24:31 <rdieter> ok, we can move on now.
15:24:53 <rdieter> #topic kde live image status
15:24:55 <rdieter> Kevin_Kofler:
15:24:57 <rdieter> ?
15:26:40 <Kevin_Kofler> So we should fit now, we were ~1 MiB oversized (exactly 704 MiB) yesterday, I dropped Krusader (should save ~4 MiB).
15:27:26 <nucleo> ConsoleKit error when logging in on livecd http://img692.imageshack.us/img692/1171/errorzg.png
15:27:32 <rdieter> action item for me is to update comps for all the pkg splits, and in doing so, could theoretically leave out a few pieces here and there to save a bit too.
15:27:37 <Kevin_Kofler> But I think we should look into some other way to save size.
15:27:48 <Kevin_Kofler> nucleo: We're discussing the size issues now.
15:28:09 <Kevin_Kofler> Yes, split comps is a good idea.
15:28:20 <rnovacek> is gnome-keyring on livecd?
15:28:22 <Kevin_Kofler> Can omit JuK (we have Amarok), at least.
15:28:31 <Kevin_Kofler> rnovacek: Yes, dragged in by more than one thing. :-(
15:28:32 <rdieter> rnovacek: probably
15:28:41 <rnovacek> if yes, we can save some deps by using ksecrets
15:28:50 <rdieter> #action rdieter to add kde split packaging to comps
15:28:54 <Kevin_Kofler> I guess having ksecrets Provides: gnome-keyring could help there.
15:29:15 <rdieter> .bug 785838
15:29:17 <zodbot> rdieter: Bug 785838 ksecrets/gnome-keyring tracking bug - https://bugzilla.redhat.com/show_bug.cgi?id=785838
15:29:49 <rdieter> speaking of which, ^^, created a tracker bug to help identify hard-deps on gnome-keyring
15:29:53 <Kevin_Kofler> Another thing I had been suggesting for a while is to split /usr/share/kde4/apps/k3b/{cdi,extras} from k3b-common to an optional subpackage.
15:30:17 <Kevin_Kofler> ~4 MiB of probably poorly-compressing stuff (extras is mpg, already compressed) hardly anybody uses.
15:30:31 <Kevin_Kofler> CD-I? Huh? And Video CDs of photos?
15:31:03 <Kevin_Kofler> (The Photo-(S)VCD stuff is even called "extras" by upstream.)
15:31:05 <rdieter> Kevin_Kofler: maybe...  if you have a chance, mind opening a bug suggesting that change in packaging?
15:32:18 <rdieter> and, in general, if anyone has concrete suggestions on space-saving measures on pkgs installed on live image, please do share.
15:32:59 <rdieter> nucleo: can you share now the ConsoleKit issue?
15:33:29 <jreznik> I'm + removing JuK (subpackaging, not shiping anymore ;-) and k3b-common
15:33:30 <rdieter> and theories on what's causing it, and ideally, how to fix it? :)
15:33:59 <rdieter> jreznik: true, shipping both juk and amarok makes no sense
15:34:11 <Kevin_Kofler> rdieter: Filing the K3b bug now.
15:34:40 <nucleo> there is error when last nightly livecd starts, don't know what wrong there http://img692.imageshack.us/img692/1171/errorzg.png
15:35:33 <rdieter> this may be related to systemd taking over all/some duties for session management?
15:35:43 <rdieter> (just guessing)
15:36:05 <rnovacek> ConsoleKit should have been autoactivated by DBus
15:36:40 <jreznik> rdieter: JuK is unusable (not talking about Amarok rather :)
15:36:59 <nucleo> only ConsoleKit-libs installed on livecd
15:37:03 <rdieter> if we've no better theories, I guess open a bug against ConsoleKit for tracking purposes
15:37:23 <rdieter> nucleo: oh, that may have something to do with it
15:37:41 <jreznik> #info the possibilities are - remove JuK, we have Amarok and split some k3b extras to k3b-common as optional subpackage
15:38:21 <rdieter> interestingly, f16 ConsoleKit doesn't get pulled it from -libs either
15:38:33 <rdieter> ConsoleKit is needed by (installed) polkit-0.102-3.fc16.x86_64
15:38:39 <rdieter> ConsoleKit >= 0.3.0-9 is needed by (installed) gdm-1:3.2.1.1-8.fc16.x86_64
15:38:45 <Kevin_Kofler> ConsoleKit used to get dragged in by default, they're deprecating it.
15:38:48 <rdieter> ConsoleKit = 0.4.5-1.fc15 is needed by (installed) ConsoleKit-x11-0.4.5-1.fc15.x86_64
15:38:55 <rdieter> and the latter by xorg-x11-xinit
15:39:31 <Kevin_Kofler> You need to ask the people behind the "remove ConsoleKit" process whether they think we can disable ConsoleKit support in KDM entirely, whether we should make it silently fail if ConsoleKit is not installed, or whether we should just Require ConsoleKit.
15:40:16 <rdieter> ok, sounds sane, who wants the job?
15:40:18 <Kevin_Kofler> https://fedoraproject.org/wiki/Features/ckremoval
15:40:49 * Kevin_Kofler filed https://bugzilla.redhat.com/show_bug.cgi?id=786150 for the K3b split.
15:42:13 <rdieter> I suppose long term we should also look into what it would take on the kde side to support that systemd-style sessions
15:42:44 <jreznik> rdieter: yep
15:42:52 <jreznik> let's try to catch lennart on devconf :)
15:43:05 <ltinkl> catch is not the right word
15:43:18 <jreznik> but as I read kde-core, there's no will from his side to support us, so it's upon us
15:43:30 <Kevin_Kofler> For the ckremoval, we also need to support yet another way to shutdown in kde-workspace, i.e. the equivalent to https://bugzilla.gnome.org/show_bug.cgi?id=666891
15:43:43 <Kevin_Kofler> Otherwise shutdown/restart will once again become unavailable for GDM users. :-(
15:44:52 <Kevin_Kofler> We shouldn't need added KDM support for the new session registration, they claim the PAM integration should be sufficient.
15:45:02 <rdieter> Kevin_Kofler: yay.
15:45:36 <jreznik> ah PAM, soon there will be SSSD, another work for us :)
15:45:53 <Kevin_Kofler> OTOH, GDM did get some changes: https://bugzilla.gnome.org/show_bug.cgi?id=655380
15:46:16 <Kevin_Kofler> So I'm not convinced that we really don't need to change anything. :-/
15:46:43 <ltinkl> systemd, SSSD, CKremoval... did I mention UDisks2 is being (silently) worked on?
15:47:05 <ltinkl> needless to say it's incompatible with the current udisks
15:47:23 <Kevin_Kofler> Overall this feels like F7 all over again to me (where ConsoleKit got introduced and I had to rush a KDM patch out when we were supposed to already be in deep freeze).
15:47:39 <Kevin_Kofler> ltinkl: Not so silently… gnome-disk-utility already uses it.
15:47:46 <ltinkl> hm
15:47:47 <rdieter> well, lets get on top of it, and poke fesco if it breaks the world
15:47:48 <Kevin_Kofler> So now we have 2 versions of udisks on the spin.
15:48:12 <Kevin_Kofler> That reminds me, should we drop gnome-disk-utility from the KDE spin? The Xfce and LXDE spins already blacklist it.
15:48:20 <Kevin_Kofler> Xfce puts gparted on instead, LXDE nothing.
15:48:20 <ltinkl> well at least they use a different DBUS name
15:48:29 <rdieter> Kevin_Kofler: +1
15:48:49 <Kevin_Kofler> We could replace it with kde-partitionmanager or just leave it off.
15:49:09 <ltinkl> Kevin_Kofler: I noticed a new version has juts been released
15:49:12 <jreznik> ltinkl: another work for you? have you started already? how much work is needed, Gnome is going to use it for F17, would be great to make it possible too
15:49:30 <Kevin_Kofler> kde-partitionmanager has a new Fedora maintainer, and upstream is alive enough to have fixed it for parted3.
15:49:48 <ltinkl> jreznik: I "started" by inspecting the XML iface docu and comparing that with udisks1
15:50:21 <jreznik> ltinkl: that's what we need now, do you know how difficult it will be?
15:50:52 <ltinkl> jreznik: moderate, it loosely follows the classes in Solid
15:51:10 <ltinkl> (with some features missing)
15:51:24 <jreznik> #info ltinkl "started" working on udisks2 by inspecting the XML iface docu and comparing that with udisks1
15:51:34 <Kevin_Kofler> Now design-wise gnome-disk-utility is really the better tool, I'm afraid. kde-partitionmanager runs the whole UI as root. :-/
15:51:44 <rdieter> .bug 786157
15:51:46 <zodbot> rdieter: Bug 786157 ConsoleKit support and/or systemd session support - https://bugzilla.redhat.com/show_bug.cgi?id=786157
15:51:48 <Kevin_Kofler> We need a KDE frontend for udisks2 in the long run.
15:52:06 <rdieter> ^^ tracking bug per our ck/systemd conversation
15:52:18 <jreznik> rdieter: thanks rdieter
15:52:30 <ltinkl> Kevin_Kofler: yup, I'm guessing it will be squeezed into the release schedule of F18 just after the feature freeze ;)
15:52:52 <Kevin_Kofler> ltinkl: I was really talking about a GUI frontend like gnome-disk-utility.
15:53:01 <Kevin_Kofler> But we need Solid support for udisks2 as well.
15:53:02 <ltinkl> oh yea
15:53:11 <Kevin_Kofler> (even more urgently)
15:53:13 <rdieter> ok, we're running short on time, can we move on?
15:53:21 <jreznik> yep, move on
15:53:29 <rdieter> #topic gcc47 status
15:53:39 <rdieter> anything to report on gcc47 ftbfs ?
15:54:02 <rdieter> I guess I do: koffice ftbfs, but calligra is ok, and it's release schedule looks like f17 is doable. so... :)
15:54:43 <rdieter> kdepim3 still ftbfs, Kevin_Kofler , would you rather kill it and make task-juggler not rely on it anymore?
15:55:10 <rdieter> perhaps depends on if anyone relies on host features or not
15:55:21 <rdieter> s/host/those/
15:57:26 <rdieter> that's all I have off the top of my head, last topic then... kdelibs-apidocs
15:57:30 <rdieter> #topic kdelibs-apidocs
15:57:56 <Kevin_Kofler> I'll have some more time now in February, I'm hoping to have a look at the *3 build failures.
15:58:20 <rdieter> just to report, still some discussion going on -legal list, though an overriding consensus there suggests we should consider simply not shipping -apidocs anymore (for various reasons).
15:58:38 <jreznik> what are the reasons?
15:58:43 <Kevin_Kofler> We need to speak up there.
15:58:59 <rdieter> licensing is still a little unclear, at least.
15:59:27 <rdieter> spot initially had some serious issues with it, but hasn't responded to Kevin_Kofler's followup yet
15:59:30 <Kevin_Kofler> spot claimed the LGPL doesn't work for docs, he hasn't yet replied to my mail pointing out that the LGPL→GPL conversion clause makes the "must be a software library" issue moot (or at least not a showstopper).
15:59:57 <Kevin_Kofler> The LGPL allows converting to the GPL (and ignoring the whole rest of the LGPL) and the GPL does not have such a clause.
16:00:24 <rdieter> and several respondents believe it not worth us shipping it at all, if it's easily available elsewhere (like api.kde.org)
16:00:55 <rdieter> (regardless of legalities and licensing)
16:01:44 <rdieter> http://lists.fedoraproject.org/pipermail/legal/2012-January/001793.html
16:01:48 <rdieter> ml thread ^^
16:02:03 <Kevin_Kofler> "Several"? I count only 2: Josh Boyer from rel-eng and spot himself.
16:02:17 <rdieter> a few more contacted me privately too
16:03:44 <rdieter> so, anyway, it's probably premature to make any decisions yet
16:03:57 <Kevin_Kofler> Right, defer to next week, we're already over time anyway…
16:04:11 <jreznik> ok
16:04:13 <rdieter> ok, thanks everyone, will close meeting here in a bit
16:04:56 <rdieter> #endmeeting