15:10:47 #startmeeting KDE SIG Meeting 15:10:47 Meeting started Tue Jul 15 15:10:47 2014 UTC. The chair is Kevin_Kofler. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:10:47 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:10:50 I know. I'm waiting for rdieter or Kevin_Kofler to start the meeting - I'm not even "officially" part of the WG yet 15:10:57 #meetingname kde-sig 15:10:57 The meeting name has been set to 'kde-sig' 15:11:03 #topic Roll call 15:11:08 * Kevin_Kofler is present, who else? 15:11:09 * jreznik is around 15:11:20 * jgrulich is present 15:11:26 * danofsatx-work is accounted for 15:11:29 here 15:11:30 * pino|work mooes 15:11:36 present 15:11:44 here 15:12:41 dvratil, mbriza: ping? 15:12:46 hi 15:12:48 hi 15:13:06 hi 15:14:18 #chair jreznik jgrulich danofsatx-work rdieter pino|work than smooge dvratil ltinkl tosky 15:14:18 Current chairs: Kevin_Kofler danofsatx-work dvratil jgrulich jreznik ltinkl pino|work rdieter smooge than tosky 15:15:05 #info Kevin_Kofler, jreznik, jgrulich, danofsatx-work, rdieter, pino|work, than, smooge, dvratil, ltinkl, tosky present. 15:15:36 (Hmmm, where did jgrulich go?) 15:15:49 I think his desktop crashed :D 15:15:58 Plasma 5? :-) 15:16:02 * dvratil peeks over jgrulich's shoulder 15:16:08 yep, Plasma 5:) 15:16:15 That explains it. ^^ 15:16:18 #topic Agenda 15:16:19 yep, I'm trying to make it work :) 15:16:39 KF5 packages update 15:16:43 Plasma 5 in Fedora 15:17:15 kde-4.13.x (and f20) status 15:17:17 * pino|work passes jgrulich a hammer 15:17:53 well, it seems to work, I'm even getting notifications from konversation 15:18:17 i'm here 15:18:22 ye, works fine, lots of stuff missing tho compared to KDE 4 15:18:24 hi 15:19:08 GStreamer 1.x 15:19:24 Anyway, I'd suggest starting with the most pressing matter… 15:19:29 #topic kde-4.13.x (and f20) status 15:20:28 rdieter: Your turn! 15:21:31 kde-4.13.3 builds underway, rawhide done, f21/f20 going right now 15:21:52 one kde-4.13/f20 blocker remains, pkg review 15:22:10 .bug 1097384 15:22:13 rdieter: Bug 1097384 Review Request: baloo-kcmadv - Baloo Desktop Search Advanced configuration module - https://bugzilla.redhat.com/1097384 15:22:35 looks like ltinkl has been busy lately :) 15:23:21 that's all I have 15:24:06 ltinkl: Are you going to finish the review or should somebody else do it? 15:28:09 fwiw, I think the review is pretty much done minus the final approval 15:29:13 #info kde-4.13.3 builds underway, rawhide done, f21/f20 going right now 15:29:30 #action ltinkl needs to complete the baloo-kcmadv review. 15:29:54 #topic KF5 packages update 15:30:04 dvratil: Your turn. 15:30:25 so, we already have all kf5 packages in Fedora (since last Monday actually, but I wasn't here for last meeting to brag about it) 15:30:45 currently F21 has 4.100.0, and I'm running a massive chain-build for rawhide to update to 5.0.0 15:30:58 rdieter, any udpates on the custom target for F21? 15:31:29 the Copr repository has been updated to 5.0.0 too, so Frameworks are available for Fedora 20 too 15:32:19 * ltinkl looking at the baloo kcmadv review 15:32:29 #info We have all KF5 packages in Fedora now, currently 4.100.0, being updated to 5.0.0. 15:32:31 dvratil: no word from releng yet, but... f21 is still self-populating like rawhide, so its not *needed* yet either 15:32:38 #info The Copr repository has been updated to 5.0.0 too, so Frameworks are available for Fedora 20 too. 15:32:38 sorry ye, been very busy lately, moving the whole family, new house in wrecks :) 15:32:48 rdieter, ah, awesome. In that case I'm going to run the chain-build for f21 too 15:33:15 it's insanely slow because of the waitrepo tasks :( 15:33:25 It's insanely slow because of ARM. 15:33:33 no, the build are actually quite fast 15:33:39 frameworks are rather small 15:33:46 Everything has to wait for that lame ARM crap to complete the builds. 15:34:05 In any case, thanks dvratil for your work on this stuff! 15:34:49 np, finally I'm doing something useful :P 15:34:52 I did a lot of that work for KDE 4 back in the day, I know how much work it is to get everything going, and there were much fewer packages to care about back then. 15:35:24 * dvratil is going to get all the awesome Koji and Copr badges :P 15:35:39 :-) 15:35:41 it also has to wait for lame x86_32. someday there will only be MIPS64 15:36:21 * jgrulich still has more badges than dvratil 15:36:22 Are the MIPS machines really faster in practice? 15:36:35 jgrulich, that's gonna change soon ;-) 15:36:41 anyway, that's probably all for the KF5 update 15:37:27 For what it's worth, IMHO there should be exactly one primary architecture: the one that's fastest to build. It might even be something we don't ship at all, as long as it builds fast so that chain-builds get done quickly. 15:37:36 Then everything we actually ship would be built as secondary architectures. 15:37:45 We'd get stuff done much faster then. 15:38:02 then you'd have s390x as primary architecture, and x86_64 as secondary 15:38:11 is it really what you want? 15:38:12 (So if MIPS64 really is that fast, I wouldn't see a problem with building that as primary.) 15:38:25 pino|work: s390x isn't actually that great in practice. 15:38:36 you've never tried one, ok 15:38:46 why don't we just cross-compile the packages? 15:39:19 Big can of worms there… 15:39:59 A lot of build systems (and build system setups, e.g. CMakeLists.txt files) either don't support cross-compiling at all or have bugs with it. 15:40:14 RPM also doesn't support it without gross hacks. 15:40:34 meh 15:40:54 But I think we need to get back to the topic of the meeting, my apologies for having started this discussion that's pointless here. 15:41:18 #topic Plasma 5 in Fedora 15:41:24 dvratil: That's again you. 15:41:25 :-) 15:41:25 so Plasma 5 is out 15:41:28 yippie! 15:41:38 \o/ 15:41:40 \o/ 15:41:54 I have most of the stuf already packaged in Copr, but it will need some love (I packaged it about 2 moths ago) 15:42:13 I assume we want Plasma 5 available in Fedora 21, even though not as primary desktop 15:42:41 (that's actually a question) 15:43:11 if possible 15:43:12 optional with a big "hic sunt leones" sign there, why not? 15:43:22 definitely not as a default for F21, we should re-evaluate that for F22/Plasma Product 15:43:31 optional, sure 15:43:33 I think it will need to go in a separate repo if we want to make it easy to install. 15:43:34 but how? with Conflicts? 15:43:42 Unless you want to hack things to install in parallel (ewww…). 15:43:45 that's my second question :-) 15:43:46 or playground repo 15:43:48 ye that's the problem, a lot of stuff will conflict 15:43:58 Conflicts really suck, having packages that just upgrade the old ones is much cleaner. 15:44:08 runtime bits, translations, icons, etc. 15:44:16 That was also one of the reasons why we went with 4.0 as default/only KDE in F9. 15:44:19 do we wantto ship in Copr (officially supported one), ship in a prefix (/opt/plasma5?), or via confclits with KDE 4? 15:44:46 Of these, I'd say Copr is the least evil. 15:45:02 I'd like to point out, that even in Copr, we still need to handle the conflicts 15:45:18 so there's not really that big difference between Copr and "via conflicts" options 15:45:23 We handle them as Obsoletes, not Conflicts. 15:45:45 dvratil: is the only difference that copr provide a different repository then? 15:45:48 Something we can't do in the primary repo unless we're ready to desupport KDE 4 (i.e. the F9 solution). 15:45:52 tosky, yes 15:46:24 so the Copr repo would be an upgrade of KDE 4, instead of alternative to KDE 4 15:46:33 For what it's worth, I'd have voted for shipping Plasma 5.0 the way we shipped 4.0 in F9, i.e. throw out all the parts of Plasma 4 that have Plasma 5 replacements, keep only the libraries and the stuff that's not ported yet (currently, basically all the applications). 15:46:52 dvratil: so basically the same as having in main, just that they are "less official" if in copr? 15:46:53 But that train has already left, I guess. 15:47:18 So failing that, doing the same in a Copr repo is the best solution IMHO. That means "so the Copr repo would be an upgrade of KDE 4, instead of alternative to KDE 4" as you say. 15:48:02 tosky: The main point of having them in Copr is that they can REPLACE (Obsolete, or just upgrade through same Name and higher EVR) the KDE 4 packages instead of Conflicting. 15:48:38 I think that's more user-friendly. 15:48:44 on the other hand we should try to make sure that in F22 users can simply switch from the Copr repo to main repo 15:48:51 I'm a bit confused now, isn't it the same (replace etc) if they were in the proper repository? 15:48:55 (Just enable the repo and run "yum update".) 15:48:56 s/proper/principal/ 15:49:00 ah 15:49:01 I see 15:49:02 ok 15:49:23 If they're in the proper repo and they're set up with Obsoletes or with same-Name-higher-EVR, people can't install Plasma 4 at all anymore. 15:49:24 tosky: if they were in the main repo, Obsoletes would upgrade everyone whether they wanted it or not 15:49:25 if they are in the same repository you have to explicitely install some specific packages 15:49:27 That'd be the F9 solution. 15:49:52 I thought in the same repository with different names, but right, no sense 15:49:54 The one I would have chosen to begin with, but now it's too late for that kind of major change in F21. 15:49:57 ok, copr 15:50:08 on the other hand we should try to make sure that in F22 users can simply switch from the Copr repo to main repo 15:50:31 That's also easier if we don't try to make them live in the same repo with Conflicts, but just move users to the new names that will also be used in F22. 15:50:32 no idea is F22 is going to be again after 6 months from F21? 15:50:55 which brings out another question: naming! 15:51:08 plasma5-appname? 15:51:09 or just appname 15:51:17 like, for instance, "systemsettings", or "kmenuedit" 15:51:23 The plan with F22 was originally that, but now some WGs want their own (usually longer) schedule and it's all becoming a big mess. 15:51:47 anyway, too early for F22 15:51:50 The Workstation WG is already implicitly assuming that there'll be separate schedules, their documents talk about the "Fedora WS 22 schedule". 15:52:12 That mess will surely not make our lives easier. :-( 15:52:32 we haven't talked about f22 schedules. there's nothing implicit 15:52:34 that wording just means its always right, whether schedules diverge or not 15:52:35 dvratil: if it's a separate repository, the applications can have the same name (as they replace the old ones in fact) 15:53:03 separate repo probably is better for testing upgrade path(s) too 15:53:14 as Kevin_Kofler said - the names should be same as what we want to push to F22 eventually to make the upgrade path simpler 15:53:22 (even if it may mean more work :-/) 15:54:34 I think the Conflicts needed to put the stuff into the main repo would be more work. 15:54:35 what about plasma-desktop, plasma-workspace or plasma-nm? do we use just plasma5-desktop/workspace/nm? 15:54:46 or plasma5-plasma-desktop/workspace/nm 15:54:49 Everything would have to be conditionalized to Conflict on F21 and Obsolete on F22+. 15:55:09 Easier to just Obsolete everywhere. 15:55:24 Kevin_Kofler, +1 (because I like easier stuff :P) 15:55:28 jgrulich, maybe we could drop the "5" (?) 15:55:41 IMHO, everything that's not parallel-installable doesn't need namespacing. 15:55:56 core gnome packages have gnome- prefix, core KDE packages have kde- prefix, makes sense IMO for core Plasma 5 packages to have some prefix too? 15:56:12 Core GNOME packages do not have a gnome- prefix. 15:56:17 I would drop it 15:56:26 Except for gnome-shell (where "shell" would be a bit crappy a name ^^). 15:56:37 Or gnome-terminal or so. 15:56:44 dnf search gnome- gives a rather long list 15:56:49 nautilus is not gnome-nautilus. :-) 15:56:53 I *do* see the current scheme of kde-plasma-... being a little redundant, would be ok with resetting to just plasma-... 15:57:31 where convenient, of course 15:57:36 +1 to plasma- 15:57:55 Of course only for stuff which is really Plasma stuff. 15:57:59 sure 15:58:03 and the whole group @plasma-shell? :) 15:58:10 @plasma-desktop ? 15:58:11 Apps should just use the upstream name as is, like kmenuedit. 15:58:22 ok 15:58:27 +1 for @plasma-desktop 15:58:41 I don't see a reason to have application-for-plasma-5-using-kf5-kmenuedit or something silly like that. ;-) 15:58:45 Kevin_Kofler: ye but how do you differentiate between kmenuedit for KDE 4 and the one for Plasma 5? 15:58:51 ltinkl: We don't. 15:58:55 ltinkl: only ship one 15:58:58 Same name, higher EVR, direct upgrade. 15:58:59 thy both ship the same binary 15:59:05 ltinkl, kmenuedit is part of kdeworkspace 15:59:11 ltinkl, hence the Obsoletes kde-workspace 15:59:12 right 15:59:18 Just don't lose the Epoch where we have one. 15:59:25 * ltinkl chose a bad example prolly 15:59:28 (Also for Obsoletes, the Epoch needs to be specified!) 15:59:39 learned that the hard way... 16:01:33 ok, so that's decided. Plasma 5 will be in Copr for now, plasma- prefix where appropriate, Obsoletes KDE4 packages 16:01:51 if you want permissions for the Copr, I created http://copr.fedoraproject.org/coprs/dvratil/plasma-5/ 16:02:07 #agreed Plasma 5 packages for F21 will be provided as a Copr that "upgrades" the Plasma 4 ones shipped with F21. 16:02:48 #agreed A plasma- prefix will be used where appropriate, no versioned prefixes are needed outside of the parallel-installable KF5. 16:02:57 #link http://copr.fedoraproject.org/coprs/dvratil/plasma-5/ 16:03:05 #topic GStreamer 1.x 16:03:30 So, everything should be ready upstream now for GStreamer 1.x, some stuff (like QtGStreamer) even did releases for it. 16:03:47 I haven't had the time to look into importing it this weekend though. 16:03:49 We agreed with Rohan that we will do phonon-gstreamer-1.0 release in Randa next month 16:04:15 cool, and now that f21 branched, definitely ok for rawhide whenever, and can merge back to f21 once it's all ready 16:04:45 I'd like to import the snapshots/releases/patches into Rawhide and, once everything's built, F21, ASAP. 16:04:52 dvratil: permissions for copr to commit to, or to read from? 16:04:58 Kevin_Kofler: +1 16:05:25 danofsatx-work, to start builds there (that's all you can do in Copr anyway :D) 16:05:32 k 16:05:52 * danofsatx-work isn't fully versed in the packaging stuff yet 16:07:08 #action Kevin_Kofler will import the snapshots/releases/patches into Rawhide and, once everything's built, F21, ASAP. 16:07:17 #topic Open discussion 16:07:29 We're basically already out of time… 16:07:36 ltinkl: One thing though. 16:08:15 The LibreOffice maintainers have complained recently that they're unhappy with the maintenance (or lack thereof) of libreoffice-kde from us, and threatened to drop it. 16:08:54 They said that you were supposed to take care of it and that you (according to them) aren't really. 16:09:48 How do we deal with this? Should more of us KDE people try to look at LibreOffice KDE issues? 16:10:12 ls .. 16:10:18 oops...wrong window 16:11:17 More communication with upstream (especially the folks working on KDE integration) would also be helpful, we shouldn't have learned about the required Qt patches only from user complaints about the LibreOffice integration regression (where upstream decided to detect unpatched Qt and fire up the default LibreOffice dialog instead). 16:15:07 well that's what also happened in debian 16:15:44 It'd be a pity to lose LibreOffice KDE integration. 16:15:50 an user filed a bug for LO-kde that it was not using kde dialogs, and the LO debian maintainer (which is also upstream) researched and came up with the needed patched 16:15:52 *patches 16:15:59 Anything else? 16:16:09 We're already 15 minutes over time. 16:16:49 * dvratil runs home before it stars raining here 16:17:13 rain? that'd sure be nice. my grass is crunchy. 16:17:28 We already have time to talk about the weather? That can mean only 1 thing… 16:17:30 #endmeeting