15:03:50 #startmeeting KDE SIG Meeting 15:03:50 Meeting started Tue Jul 9 15:03:50 2013 UTC. The chair is Kevin_Kofler. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:03:50 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:03:57 #meetingname kde-sig 15:03:57 The meeting name has been set to 'kde-sig' 15:04:06 #topic Role call 15:04:20 * jgrulich is present 15:04:23 * nucleo here 15:04:26 hello 15:06:00 than, rdieter, jreznik_: Ping? 15:09:15 #chair jgrulich nucleo mbriza 15:09:15 Current chairs: Kevin_Kofler jgrulich mbriza nucleo 15:09:19 oh hey, I have a discussion item, if the agenda isn't too full yet: BlueZ 5 15:09:33 #info Kevin_Kofler, jgrulich, nucleo, mbriza present. 15:09:46 kalev: We don't have any agenda that I know of. 15:09:50 i have yeat another topic - sddm instead of kdm feature 15:09:52 yet 15:10:19 But the problem is, BlueDevil is jreznik_'s and he doesn't seem to be present. 15:10:31 #topic Agenda 15:10:40 So let's collect agenda topics: 15:10:49 #info BlueZ 5 (kalev) 15:10:59 #info SDDM instead of KDM (mbriza) 15:11:02 i can poke him gently if i'll see him around the office when going for coffee... brb 15:12:19 system LibRaw in libkdcraw 15:13:55 #info system LibRaw in libkdcraw (nucleo) 15:16:32 So, let's start, even if half of the SIG is AWOL again. 15:16:52 yeah, so he was on the phone and ran away when saw me entering the kitchen so we'll see if he'll come on his own :) 15:17:04 * Kevin_Kofler is starting to get fed up of showing up for meetings every week when everyone else doesn't. 15:17:26 #topic SDDM instead of KDM 15:17:32 Let's start with this one. 15:17:45 mbriza: So, what are the plans, status etc. there? 15:18:34 status is: i've written a feature page, link incoming 15:18:39 preparing packages 15:18:39 https://fedoraproject.org/wiki/SIGs/KDE/KDMtoLightDM 15:19:01 that, and https://fedoraproject.org/wiki/Changes/SDDMinsteadOfKDM 15:19:34 status of sddm is, upstream started being active again yesterday 15:20:10 some features are still missing, for example xdmcp, however, it gives us opportunity in other ways, for example i saw somebody started writing a wayland backend 15:21:06 i'll of course withdraw the feature page if we as a sig decide not to go there 15:22:08 mbriza: go ahead with sddm 15:22:12 So I must say I don't think we want that for F20, sorry, for several reasons: 15:22:27 * it's Qt 5. As things are now, it'd be the ONLY thing on the KDE spin that's Qt 5! 15:22:39 it's not qt5-only 15:22:50 * it's not feature-complete yet (e.g. you say it's missing XDMCP) 15:23:31 * KDM is still there in kde-workspace 4.x, and given their permanent feature-freeze, will probably stay as long as 4.x exists 15:23:35 that's true, yet if it's only xdmcp what bothers us, i'll finish the support 15:24:15 I'll also personally miss the nice old Solar KDM theme, unless you do a QML version of Solar for SDDM. ;-) 15:24:16 kdm staying in kde-workspace isn't really a blocker for this, imho 15:24:45 We could ship both, right. 15:24:51 Kevin_Kofler: i don't see any problem to support sddm additionally 15:24:53 yeah, actually i was thinking about creating my own theme but with my graphical skills... ugh :) 15:24:55 But then the question is which should be the default. 15:24:56 we ship wboth 15:25:32 in my opinion kdm shoud be the default 15:26:37 we will switch sddm to default when all missing features implemented 15:27:25 there aren't many missing features in sddm, afaik, i'd say... there's xdmcp which doesn't even have a working client part now as far as i know 15:27:59 mbriza: do you think we can get this feature done in f20? 15:28:54 And in any case I think we'll want SDDM built against Qt 4 in F20, not Qt 5. 15:29:11 Kevin_Kofler: yeah, i agree 15:29:15 (Your feature page emphasizes the Qt-5-ness a lot.) 15:29:27 Kevin_Kofler: +1 15:30:15 than: i have started implementing xdmcp server on my own, actually, but i'm missing something there (possibly in xauth) and can't connect to the running display 15:30:29 there are other features which are interesting to us, though 15:30:43 today a feature branch containing possibility to change keyboard layouts have been merged 15:31:00 Ah, KDM horribly sucks at that. 15:31:31 yesterday, actually, nevermind 15:32:04 So I think I'm willing to give this a try (i.e. +1 to submitting the feature) under the conditions that 1. you build SDDM against Qt 4 in F20 and 2. you don't remove or Obsolete KDM. 15:32:44 We'll see how well it works out and we can always switch the default back if it doesn't work well. 15:33:35 yes, that's absolutely reasonable... i'll change the feature page a bit to not over-emphasize the qt5 part 15:34:28 we have kde feature page for f20 https://fedoraproject.org/wiki/Changes/KDE411 15:34:34 I see the increasing problems with fixing KDM, I just hope SDDM won't have too many issues that are hard to fix (missing features you weren't aware of, bugs that are showstoppers for some users etc.). 15:34:58 please take a look at this 15:35:07 than: Good, but the display manager switch should be separate. 15:35:29 well, to me, adding features and fixing bugs in sddm is a lot more feasible than doing the same in kdm, so i'm pushing this so hard mainly because of that 15:36:49 Kevin_Kofler: yes, sddm will be separate 15:37:10 than: So, the 4.11 feature page looks basically OK, but: 15:37:31 The Summary sounds like the KDE Applications and the KDE Platform are part of the KDE Plasma Workspace, which doesn't really sound right. 15:37:34 Kevin_Kofler: feel free to correct it ;-) 15:37:49 (Somebody just did a s/Software Compilation/Plasma Workspace/, but that's not really OK.) 15:38:34 than: Well, I'd correct it to just KDE 4.11 or KDE Software Compilation 4.11, so if you want a marketing-correct wording, find someone who likes the latest upstream marketing speech. ;-) 15:39:26 The problem is that upstream doesn't want any term used for the complete release, they themselves use silly wording such as "KDE releases June updates". 15:40:26 sorry I'm late... (reading backscroll) 15:40:31 What about: "Rebase to version 4.11 of: the KDE Plasma Workspaces including Plasma Desktop and Netbook workspaces, the KDE Applications and the KDE Platform."? 15:40:50 (I still think that's silly, but I think that's how upstream wants it worded.) 15:41:32 The second thing I think doesn't make much sense is "based on top of Qt 4.8", we've been shipping 4.8 for a while. 15:42:16 yes, it's exactly what upstream writes in annoucement 15:42:44 based on top of Qt 4.8.5 ? 15:43:31 imo, drop the extraneous mention of Qt at all 15:44:01 I edited the summary: https://fedoraproject.org/wiki/Changes/KDE411#Summary 15:44:10 rdieter: +1 15:44:16 it's fine with me 15:44:52 OK, "based on top of Qt 4.8" removed. 15:47:15 Let's move on. 15:47:45 #agreed "SDDM instead of KDM" feature will be submitted as a Change. 15:47:47 #topic system LibRaw in libkdcraw 15:47:59 https://projects.kde.org/projects/kde/kdegraphics/libs/libkdcraw/repository/revisions/ee76a4eef0c601215c7c7c4440fd56b2b8740a63 15:48:00 nucleo: That's yours. 15:48:37 this patch added posibility to build against system LibRaw, but only 0.15+ version required 15:48:47 So I see you already applied this in Rawhide. 15:49:03 yes 15:49:39 but if LibRaw 0.15 not present libkdcraw fails to build with internal LibRaw 15:50:30 The patch is such that it REQUIRES the external LibRaw. 15:50:38 So it's expected that it will NOT fall back to a bundled one. 15:50:44 0.15 now only in Rawhidem so if this patch will be in libkdcraw 4.11 we will need to do something for building it for < F20 15:50:48 It's also not in current upstream master, only in an external-libraw branch. 15:51:01 I suppose it will only enter master after 4.11 branches. 15:51:17 Dependency changes are not allowed at this stage of the 4.11 release cycle. 15:51:36 This will be only for 4.12. 15:51:47 then we can just not apply patch for < F20? 15:51:57 Right. 15:52:30 ok, then there is other problem - internal LibRaw built with RawSpeed codec 15:52:30 What we could also do is try to hack things so they build against the old system LibRaw, or try to get the system LibRaw updated. 15:52:58 but no RawSpeed in system LibRaw because it commented in its Makefile 15:53:10 But I'd rather just wait for 4.12 with the move to an external LibRaw because old LibRaw = fewer supported hardware etc. 15:53:29 (and we'd be effectively downgrading it on, say, F18) 15:54:08 I don't know why libkdcraw requires LibRaw 0.15 15:54:51 I don't know either, I'd have to look into it and I'd rather not do it, to be honest. 15:54:55 * rdieter agrees with Kevin_Kofler 15:55:39 The system LibRaw is also not built against libjpeg, which means JPEG-compressed DNGs cannot be decoded. 15:55:39 so Rawhide is fine for using external LibRaw? 15:55:54 I think one of us needs to sign up as a comaintainer of LibRaw and get the missing features in there. 15:56:09 (and also possibly coordinating upgrades for releases if it will become necessary in the future) 15:56:18 at least it have libjpeg.so.62 deps http://koji.fedoraproject.org/koji/rpminfo?rpmID=4041419 15:56:30 nucleo: for now rawhide is ok 15:56:35 For RawSpeed, I think a patch is needed, it's not supported out of the box by upstream LibRaw. 15:56:54 testing and use will show how well it works, we can back it out if there are unresolvable problems 15:57:01 nucleo: Oh, I guess it's dragged in by jasper-devel and/or lcms-devel, but there should be an explicit BR. 15:57:45 http://kojipkgs.fedoraproject.org//packages/LibRaw/0.15.2/1.fc20/data/logs/i686/build.log 15:58:15 jpeg checked in ./configure 15:59:21 so libjpeg used somehow in LibRaw 15:59:28 Yes, as I said, it's dragged in by the other BRs (I think I remember now that jasper-devel drags it in), but it's poor form not to explicitly BR it. 15:59:42 But it doesn't matter feature-wise. 16:00:14 RawSpeed does, we need to discuss that with the LibRaw maintainer. 16:00:25 Note that libkdcraw upstream also does NOT build RawSpeed by default. 16:00:31 ok, I will file bug 16:00:44 It's documented as an optional experimental feature, which we are explicitly enabling. 16:00:53 yse 16:01:19 I mean yes :) 16:01:49 #info libkdcraw now has support for an external LibRaw in a development branch, we are enabling this in Rawhide. 16:02:00 #action nucleo to file a bug requesting RawSpeed to be enabled in the system LibRaw. 16:02:23 #topic BlueZ 5 16:02:36 Last topic, we're already over time… 16:02:42 kalev: So what about that? 16:02:58 hi all 16:03:10 hadess is planning to update bluez 4 to bluez 5 in F20 and that needs a bit coordination 16:03:23 bluez has two ways of using it: (1) through the libbluetooth shared library or (2) over DBus 16:03:35 the new bluez 5 update doesn't change the libbluetooth shared library's ABI, but the DBus API is redone and requires changes in apps that use it 16:03:50 unfortunately, the way it's done is so that bluez 4 and bluez 5 aren't parallel installable, so we'd need a flag day to switch over the core packages 16:04:06 hadess's current plan is to have two separate packages, bluez and bluez5, to make it possible for some spins to ship with v4 (KDE) and others with v5 (GNOME) 16:04:20 this is somewhat unorthodox because the v4 and v5 packages wouldn't be parallel installable, but would conflict (and bluez5 would obsolete bluez) 16:04:24 Ugh… 16:04:25 bluez5 package review ticket: https://bugzilla.redhat.com/show_bug.cgi?id=974145 16:04:35 I kinda assume bluedevil uses the lib ABI (via libbluedevil), not that's mostly a guess 16:04:36 might be nicer to be able to update the existing bluez package to version 5 instead of going through the conflicts-obsoletes route, but it's hard to switch the whole distro over at the same time 16:04:38 That's horrible, you won't have working Bluetooth if you install both KDE and GNOME that way. 16:04:46 yeah. 16:04:51 I think it's all or nothing. 16:04:55 there's a libbluedevil patch for bluez 5 support at https://git.reviewboard.kde.org/r/108912/ 16:05:01 Just like with NM, we also vetoed the idea of a Conflicts there. 16:05:23 Conflicting packages here is indeed bad, I'm surprised anyone is considering that option viable 16:05:36 if it's possible to switch over both KDE and GNOME at the same time, then it might be feasible to not do the conflicting packages 16:05:39 If there's already BlueDevil support for the new version, we should just upgrade it. 16:05:53 (I'm personally not much of a fan for the conflicting packages here, for what it's worht) 16:06:05 "Pushed to bluez5 branch of libbluedevil's repo" – so we'll just ship that. 16:06:07 looks like libbluedevil uses dbus 16:06:38 Kevin_Kofler: +1 16:06:43 All we need to take care of is to ship the right version of BlueDevil for the right version of Fedora, but we've already done that with e.g. NM. 16:07:47 It just means not to merge master without thinking. ;-) 16:07:57 cool :) 16:08:02 (and to know when to stop pulling new upstream releases into f19) 16:09:49 (Looks like 2.0 will be the BlueZ 5 version.) 16:09:58 (but we can ship branch snapshots of course) 16:10:23 #info BlueZ 5 will come in Rawhide for F20, BlueDevil has support for it in a branch. 16:10:29 #topic Open discussion 16:10:33 Anything else? 16:10:37 4.10.5 update 16:10:45 Oh right… 16:11:05 What's the status of that? I think it's in testing pending the 2-week timeout or something. 16:11:20 Let me check… 16:11:46 Oh, actually it's not filed in Bodhi yet. 16:11:48 Huh? 16:11:50 Why? 16:12:11 just fyi mostly for posterity and meeting log, kde-redhat primary mirror had been offline jul 3, but I finally got the disk replaced and restored yesterday, jul 8 16:12:47 than did the 4.10.5 imports, he's not here, so I can't ask him about the status. 16:13:01 Oh, actually he is here now. 16:13:05 than: Ping? 16:13:13 (He wasn't here at the beginning of the meeting.) 16:14:06 (Looks like he left again? He was there when we discussed the meeting pages.) 16:14:27 #info kde-redhat primary mirror had been offline jul 3, but I finally got the disk replaced and restored yesterday, jul 8 16:14:30 #undo 16:14:30 Removing item from minutes: 16:14:38 #info kde-redhat primary mirror had been offline jul 3, but rdieter finally got the disk replaced and restored yesterday, jul 8 16:15:00 * Kevin_Kofler wanted to edit that and hit Return accidentally. ;-) 16:15:11 one more thing about bluez: would be nice if someone could comment on the bluez5 review ticket and say that there's no need for Conflicts just for KDE's sake (if the libbluedevil patch / git branch looks feasible to ship in F20, of course) 16:15:34 kalev: I'll do that. 16:15:43 cool, thanks 16:17:17 nucleo: Looks like we won't know more about the 4.10.5 status today… :-( 16:17:29 #endmeeting