kde-sig
LOGS
15:03:50 <Kevin_Kofler> #startmeeting KDE SIG Meeting
15:03:50 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:03:57 <Kevin_Kofler> #meetingname kde-sig
15:03:57 <zodbot> The meeting name has been set to 'kde-sig'
15:04:06 <Kevin_Kofler> #topic Role call
15:04:20 * jgrulich is present
15:04:23 * nucleo here
15:04:26 <mbriza> hello
15:06:00 <Kevin_Kofler> than, rdieter, jreznik_: Ping?
15:09:15 <Kevin_Kofler> #chair jgrulich nucleo mbriza
15:09:15 <zodbot> Current chairs: Kevin_Kofler jgrulich mbriza nucleo
15:09:19 <kalev> oh hey, I have a discussion item, if the agenda isn't too full yet: BlueZ 5
15:09:33 <Kevin_Kofler> #info Kevin_Kofler, jgrulich, nucleo, mbriza present.
15:09:46 <Kevin_Kofler> kalev: We don't have any agenda that I know of.
15:09:50 <mbriza> i have yeat another topic - sddm instead of kdm feature
15:09:52 <mbriza> yet
15:10:19 <Kevin_Kofler> But the problem is, BlueDevil is jreznik_'s and he doesn't seem to be present.
15:10:31 <Kevin_Kofler> #topic Agenda
15:10:40 <Kevin_Kofler> So let's collect agenda topics:
15:10:49 <Kevin_Kofler> #info BlueZ 5 (kalev)
15:10:59 <Kevin_Kofler> #info SDDM instead of KDM (mbriza)
15:11:02 <mbriza> i can poke him gently if i'll see him around the office when going for coffee... brb
15:12:19 <nucleo> system LibRaw in libkdcraw
15:13:55 <Kevin_Kofler> #info system LibRaw in libkdcraw (nucleo)
15:16:32 <Kevin_Kofler> So, let's start, even if half of the SIG is AWOL again.
15:16:52 <mbriza> 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 <Kevin_Kofler> #topic SDDM instead of KDM
15:17:32 <Kevin_Kofler> Let's start with this one.
15:17:45 <Kevin_Kofler> mbriza: So, what are the plans, status etc. there?
15:18:34 <mbriza> status is: i've written a feature page, link incoming
15:18:39 <mbriza> preparing packages
15:18:39 <jgrulich> https://fedoraproject.org/wiki/SIGs/KDE/KDMtoLightDM
15:19:01 <mbriza> that, and https://fedoraproject.org/wiki/Changes/SDDMinsteadOfKDM
15:19:34 <mbriza> status of sddm is, upstream started being active again yesterday
15:20:10 <mbriza> 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 <mbriza> i'll of course withdraw the feature page if we as a sig decide not to go there
15:22:08 <than> mbriza: go ahead with sddm
15:22:12 <Kevin_Kofler> So I must say I don't think we want that for F20, sorry, for several reasons:
15:22:27 <Kevin_Kofler> * 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 <mbriza> it's not qt5-only
15:22:50 <Kevin_Kofler> * it's not feature-complete yet (e.g. you say it's missing XDMCP)
15:23:31 <Kevin_Kofler> * 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 <mbriza> that's true, yet if it's only xdmcp what bothers us, i'll finish the support
15:24:15 <Kevin_Kofler> I'll also personally miss the nice old Solar KDM theme, unless you do a QML version of Solar for SDDM. ;-)
15:24:16 <mbriza> kdm staying in kde-workspace isn't really a blocker for this, imho
15:24:45 <Kevin_Kofler> We could ship both, right.
15:24:51 <than> Kevin_Kofler: i don't see any problem to support sddm additionally
15:24:53 <mbriza> yeah, actually i was thinking about creating my own theme but with my graphical skills... ugh :)
15:24:55 <Kevin_Kofler> But then the question is which should be the default.
15:24:56 <than> we ship wboth
15:25:32 <than> in my opinion kdm shoud be the default
15:26:37 <than> we will switch sddm to default when  all missing  features implemented
15:27:25 <mbriza> 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 <than> mbriza: do you think we can get this feature done in f20?
15:28:54 <Kevin_Kofler> And in any case I think we'll want SDDM built against Qt 4 in F20, not Qt 5.
15:29:11 <mbriza> Kevin_Kofler: yeah, i agree
15:29:15 <Kevin_Kofler> (Your feature page emphasizes the Qt-5-ness a lot.)
15:29:27 <than> Kevin_Kofler: +1
15:30:15 <mbriza> 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 <mbriza> there are other features which are interesting to us, though
15:30:43 <mbriza> today a feature branch containing possibility to change keyboard layouts have been merged
15:31:00 <Kevin_Kofler> Ah, KDM horribly sucks at that.
15:31:31 <mbriza> yesterday, actually, nevermind
15:32:04 <Kevin_Kofler> 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 <Kevin_Kofler> 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 <mbriza> yes, that's absolutely reasonable... i'll change the feature page a bit to not over-emphasize the qt5 part
15:34:28 <than> we have kde feature page for f20 https://fedoraproject.org/wiki/Changes/KDE411
15:34:34 <Kevin_Kofler> 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 <than> please take a look at this
15:35:07 <Kevin_Kofler> than: Good, but the display manager switch should be separate.
15:35:29 <mbriza> 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 <than> Kevin_Kofler: yes, sddm will be separate
15:37:10 <Kevin_Kofler> than: So, the 4.11 feature page looks basically OK, but:
15:37:31 <Kevin_Kofler> 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 <than> Kevin_Kofler: feel free to correct it  ;-)
15:37:49 <Kevin_Kofler> (Somebody just did a s/Software Compilation/Plasma Workspace/, but that's not really OK.)
15:38:34 <Kevin_Kofler> 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 <Kevin_Kofler> 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 <rdieter> sorry I'm late... (reading backscroll)
15:40:31 <Kevin_Kofler> 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 <Kevin_Kofler> (I still think that's silly, but I think that's how upstream wants it worded.)
15:41:32 <Kevin_Kofler> 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 <than> yes, it's exactly what upstream writes in annoucement
15:42:44 <than> based on top of Qt 4.8.5 ?
15:43:31 <rdieter> imo, drop the extraneous mention of Qt at all
15:44:01 <Kevin_Kofler> I edited the summary: https://fedoraproject.org/wiki/Changes/KDE411#Summary
15:44:10 <Kevin_Kofler> rdieter: +1
15:44:16 <than> it's fine with me
15:44:52 <Kevin_Kofler> OK, "based on top of Qt 4.8" removed.
15:47:15 <Kevin_Kofler> Let's move on.
15:47:45 <Kevin_Kofler> #agreed "SDDM instead of KDM" feature will be submitted as a Change.
15:47:47 <Kevin_Kofler> #topic system LibRaw in libkdcraw
15:47:59 <nucleo> https://projects.kde.org/projects/kde/kdegraphics/libs/libkdcraw/repository/revisions/ee76a4eef0c601215c7c7c4440fd56b2b8740a63
15:48:00 <Kevin_Kofler> nucleo: That's yours.
15:48:37 <nucleo> this patch added posibility to build against system LibRaw, but only 0.15+ version required
15:48:47 <Kevin_Kofler> So I see you already applied this in Rawhide.
15:49:03 <nucleo> yes
15:49:39 <nucleo> but if LibRaw 0.15 not present libkdcraw fails to build with internal LibRaw
15:50:30 <Kevin_Kofler> The patch is such that it REQUIRES the external LibRaw.
15:50:38 <Kevin_Kofler> So it's expected that it will NOT fall back to a bundled one.
15:50:44 <nucleo> 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 <Kevin_Kofler> It's also not in current upstream master, only in an external-libraw branch.
15:51:01 <Kevin_Kofler> I suppose it will only enter master after 4.11 branches.
15:51:17 <Kevin_Kofler> Dependency changes are not allowed at this stage of the 4.11 release cycle.
15:51:36 <Kevin_Kofler> This will be only for 4.12.
15:51:47 <nucleo> then we can just not apply patch for < F20?
15:51:57 <Kevin_Kofler> Right.
15:52:30 <nucleo> ok, then there is other problem - internal LibRaw built with RawSpeed codec
15:52:30 <Kevin_Kofler> 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 <nucleo> but no RawSpeed in system LibRaw because it commented in its Makefile
15:53:10 <Kevin_Kofler> 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 <Kevin_Kofler> (and we'd be effectively downgrading it on, say, F18)
15:54:08 <nucleo> I don't know why libkdcraw requires LibRaw  0.15
15:54:51 <Kevin_Kofler> 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 <Kevin_Kofler> The system LibRaw is also not built against libjpeg, which means JPEG-compressed DNGs cannot be decoded.
15:55:39 <nucleo> so Rawhide is fine for using external LibRaw?
15:55:54 <Kevin_Kofler> I think one of us needs to sign up as a comaintainer of LibRaw and get the missing features in there.
15:56:09 <Kevin_Kofler> (and also possibly coordinating upgrades for releases if it will become necessary in the future)
15:56:18 <nucleo> at least it have libjpeg.so.62 deps http://koji.fedoraproject.org/koji/rpminfo?rpmID=4041419
15:56:30 <rdieter> nucleo: for now rawhide is ok
15:56:35 <Kevin_Kofler> For RawSpeed, I think a patch is needed, it's not supported out of the box by upstream LibRaw.
15:56:54 <rdieter> testing and use will show how well it works, we can back it out if there are unresolvable problems
15:57:01 <Kevin_Kofler> 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 <nucleo> http://kojipkgs.fedoraproject.org//packages/LibRaw/0.15.2/1.fc20/data/logs/i686/build.log
15:58:15 <nucleo> jpeg checked in ./configure
15:59:21 <nucleo> so libjpeg used somehow in LibRaw
15:59:28 <Kevin_Kofler> 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 <Kevin_Kofler> But it doesn't matter feature-wise.
16:00:14 <Kevin_Kofler> RawSpeed does, we need to discuss that with the LibRaw maintainer.
16:00:25 <Kevin_Kofler> Note that libkdcraw upstream also does NOT build RawSpeed by default.
16:00:31 <nucleo> ok, I will file bug
16:00:44 <Kevin_Kofler> It's documented as an optional experimental feature, which we are explicitly enabling.
16:00:53 <nucleo> yse
16:01:19 <nucleo> I mean yes :)
16:01:49 <Kevin_Kofler> #info libkdcraw now has support for an external LibRaw in a development branch, we are enabling this in Rawhide.
16:02:00 <Kevin_Kofler> #action nucleo to file a bug requesting RawSpeed to be enabled in the system LibRaw.
16:02:23 <Kevin_Kofler> #topic BlueZ 5
16:02:36 <Kevin_Kofler> Last topic, we're already over time…
16:02:42 <Kevin_Kofler> kalev: So what about that?
16:02:58 <kalev> hi all
16:03:10 <kalev> hadess is planning to update bluez 4 to bluez 5 in F20 and that needs a bit coordination
16:03:23 <kalev> bluez has two ways of using it: (1) through the libbluetooth shared library or (2) over DBus
16:03:35 <kalev> 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 <kalev> 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 <kalev> 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 <kalev> 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 <Kevin_Kofler> Ugh…
16:04:25 <kalev> bluez5 package review ticket: https://bugzilla.redhat.com/show_bug.cgi?id=974145
16:04:35 <rdieter> I kinda assume bluedevil uses the lib ABI (via libbluedevil), not that's mostly a guess
16:04:36 <kalev> 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 <Kevin_Kofler> That's horrible, you won't have working Bluetooth if you install both KDE and GNOME that way.
16:04:46 <kalev> yeah.
16:04:51 <Kevin_Kofler> I think it's all or nothing.
16:04:55 <kalev> there's a libbluedevil patch for bluez 5 support at https://git.reviewboard.kde.org/r/108912/
16:05:01 <Kevin_Kofler> Just like with NM, we also vetoed the idea of a Conflicts there.
16:05:23 <rdieter> Conflicting packages here is indeed bad, I'm surprised anyone is considering that option viable
16:05:36 <kalev> 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 <Kevin_Kofler> If there's already BlueDevil support for the new version, we should just upgrade it.
16:05:53 <kalev> (I'm personally not much of a fan for the conflicting packages here, for what it's worht)
16:06:05 <Kevin_Kofler> "Pushed to bluez5 branch of libbluedevil's repo" – so we'll just ship that.
16:06:07 <rdieter> looks like libbluedevil uses dbus
16:06:38 <rdieter> Kevin_Kofler: +1
16:06:43 <Kevin_Kofler> 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 <Kevin_Kofler> It just means not to merge master without thinking. ;-)
16:07:57 <kalev> cool :)
16:08:02 <Kevin_Kofler> (and to know when to stop pulling new upstream releases into f19)
16:09:49 <Kevin_Kofler> (Looks like 2.0 will be the BlueZ 5 version.)
16:09:58 <Kevin_Kofler> (but we can ship branch snapshots of course)
16:10:23 <Kevin_Kofler> #info BlueZ 5 will come in Rawhide for F20, BlueDevil has support for it in a branch.
16:10:29 <Kevin_Kofler> #topic Open discussion
16:10:33 <Kevin_Kofler> Anything else?
16:10:37 <nucleo> 4.10.5 update
16:10:45 <Kevin_Kofler> Oh right…
16:11:05 <Kevin_Kofler> What's the status of that? I think it's in testing pending the 2-week timeout or something.
16:11:20 <Kevin_Kofler> Let me check…
16:11:46 <Kevin_Kofler> Oh, actually it's not filed in Bodhi yet.
16:11:48 <Kevin_Kofler> Huh?
16:11:50 <Kevin_Kofler> Why?
16:12:11 <rdieter> 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 <Kevin_Kofler> than did the 4.10.5 imports, he's not here, so I can't ask him about the status.
16:13:01 <Kevin_Kofler> Oh, actually he is here now.
16:13:05 <Kevin_Kofler> than: Ping?
16:13:13 <Kevin_Kofler> (He wasn't here at the beginning of the meeting.)
16:14:06 <Kevin_Kofler> (Looks like he left again? He was there when we discussed the meeting pages.)
16:14:27 <Kevin_Kofler> #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 <Kevin_Kofler> #undo
16:14:30 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x125e5e10>
16:14:38 <Kevin_Kofler> #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 <kalev> 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 <Kevin_Kofler> kalev: I'll do that.
16:15:43 <kalev> cool, thanks
16:17:17 <Kevin_Kofler> nucleo: Looks like we won't know more about the 4.10.5 status today… :-(
16:17:29 <Kevin_Kofler> #endmeeting