15:04:40 #startmeeting kde-sig 15:04:40 Meeting started Tue Apr 15 15:04:40 2014 UTC. The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:04:40 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:04:45 #meetingname kde-sig 15:04:45 The meeting name has been set to 'kde-sig' 15:04:49 #topic roll call 15:04:53 ok, lets try this again 15:04:54 :) 15:04:55 hi again 15:04:58 Present. 15:04:59 hi 15:05:44 * rdieter waves at all the strangers he totally did not see just a minute ago in some other channel resembling this one 15:06:07 (dripping with sarcasm) 15:06:19 #info rdieter jgrulich Kevin_Kofler dvratil present 15:06:23 * pino|work turns rdieter upside down 15:06:24 #chair jgrulich Kevin_Kofler dvratil 15:06:24 Current chairs: Kevin_Kofler dvratil jgrulich rdieter 15:06:28 me 15:06:36 #info pino|work present 15:06:38 hre 15:06:42 here* 15:06:54 #info tosky present 15:07:01 #chair pino|work tosky 15:07:01 Current chairs: Kevin_Kofler dvratil jgrulich pino|work rdieter tosky 15:07:27 good enough for me, let's discuss agenda 15:07:29 #topic agenda 15:07:31 hi 15:07:38 #info mbriza present 15:07:41 #chair mbriza 15:07:41 Current chairs: Kevin_Kofler dvratil jgrulich mbriza pino|work rdieter tosky 15:07:48 what to discuss today? 15:08:01 KF5 reviews 15:08:11 * rdieter can do kde-4.13.0 status update 15:08:40 * jreznik is around, hope in a right channel :) 15:08:57 jreznik: Yes. :-) 15:10:05 ok, let's get started... 15:10:11 #topic kf5 reviews 15:10:19 dvratil: the floor is yours 15:10:28 so, I started submitting our KF5 packages for review 15:10:38 .bug 1086148 15:10:42 dvratil: Bug 1086148 KDE Frameworks 5 - https://bugzilla.redhat.com/1086148 15:10:55 all reviews block the "Feature" bug 15:11:01 so if you are bored, feel free to pick one 15:11:14 yay, will do. 15:11:20 I submitted the base packages and kf5-attica as a first framework, based on review of that framework I'll adjust all others 15:11:26 I'll take a look tomorrow :) 15:11:31 one question: 15:11:53 currently we have kf5-filesystem, which owns some of the paths, but also installs macro.kf5 for rpmbuild 15:12:20 kde-filesystem also worked that way. 15:12:31 given that we will need to adjust some env variables via /etc/profile.d, does it make sense to create kf5-settings, or can it go to kf5-filesystem, too? 15:12:59 I guess having the RPM macros separate would be cleaner, but for the few bytes they take… 15:13:22 dvratil: wrong link → http://dvratil.fedorapeople.org/kf5/review/dbusmenu-qt5.spec 15:13:31 dvratil: or you forgot to upload it 15:13:37 jgrulich, ok, will fix after the mtg 15:14:01 right now kf5-filesystem is in BR of all frameworks 15:14:16 so kf5-filesystem would have to be moved to Requires 15:14:41 dvratil: good question. I'd say if I had to do it all over again, I'd say producing both -settings -filesystem from the same base pkg makes sense 15:15:35 otoh, doing it separate isnt *wrong* either. whichever approach is most convenient I guess 15:15:40 hmm, that's a clever idea :-) 15:16:38 present 15:16:45 thanks rdieter :) 15:16:49 #info than present 15:16:51 #chair than 15:16:51 Current chairs: Kevin_Kofler dvratil jgrulich mbriza pino|work rdieter than tosky 15:17:11 except for that, that's all from me...add yourself to CC of the "Feature" bug, so that you get notifications about new reviews 15:17:22 For complete cleanliness, there should be kf5-filesystem with only the paths and kf5-rpmmacros. 15:17:23 if you want to get the notifications of course :-) 15:17:33 And the packages would BR kf5-rpmmacros and Require kf5-filesystem. 15:17:45 and kf5-settings 15:18:08 dvratil: For the reviews, please also put them on the kde-reviews tracker, I'm mass-changing the existing ones for that. 15:18:10 * rdieter doesn't see the need for a separate -rpmmacros, but meh (bikeshed) 15:18:22 Kevin_Kofler, ok, thanks 15:18:39 rdieter: Conceptually, -rpmmacros is a build-time dep, -filesystem a runtime one. 15:18:46 Spacewise, it's negligible of course. 15:19:15 I prefer to introduce subpkgs because it solves some need or problem. I don't see either in this case 15:19:27 dvratil: could you please add us when submitting SCM request? so we don't have to add yourself to all of KF5 packages later? 15:19:39 jgrulich, ok, I'll try not to forget that 15:20:50 does it make sense to have the basepkg (kf5) Require kf5-filesystem and kf5-settings, so that all frameworks can have just Requires: kf5 ? 15:20:56 then kf5-rpmmacros in BR 15:21:36 dvratil: +1, worksforme 15:22:01 ok, thanks for your input, I'll update the stuff accordingly after the mtg 15:22:32 dvratil: actually... I'd prefer only packages that *really* need -settings depend on it 15:22:50 (if possible) 15:22:55 that should be possible 15:23:11 for example, in kde4, only kdelibs Requires: kde-settings 15:23:23 not sure if that is analogous to kf5 15:23:32 hmm 15:23:41 I think the -settings only involves setting QML2_IMPORT_PATH 15:24:00 In KDE 4, everything requires kdelibs, so basically everything requires kde-settings. ;-) 15:24:03 so it should be required only by frameworks that install any QML stuff 15:24:15 dvratil: We'll definitely have more settings at some point. 15:24:19 Something like the KDE 4 kde-settings. 15:24:21 (so far). ok, consider me retracting my minor objection 15:24:36 I don't see any harm in it 15:24:41 Given how KF5 uses different settings directories, we need a separate one, or to add the stuff to kde-settings. 15:25:03 (I liked how KDE 4 shared the settings with KDE 3, IMHO it's a mistake from upstream to change that now.) 15:25:10 I'm trying to follow the KDE4 style, so that /usr/share/kf5, /usr/include/kf5/ .... 15:25:18 (just be mindful of the potential of adding needless extraneous deps all over) 15:25:19 so yes, maybe XDG_DATA_DIRS might need adjusting too 15:25:45 dvratil: It's not just a matter of environment variables, but also of defaults. 15:25:53 The upstream defaults are not always what we want. 15:26:03 Look at our kde-settings package to see what we override for KDE 4. 15:26:06 (and 3) 15:26:18 that mostly apps settings 15:26:36 that would be kde5-settings :-) 15:27:15 dvratil: namespaced directories for libraries/frameworks? 15:27:25 but that's a not-that-distant-but-still-pretty-far-away future 15:27:31 tosky, as in...? 15:27:49 /usr/lib64/$FRAMEWORK/libKF5$FRAMEWORK.so ? 15:27:51 dvratil: /usr/share/kf5, namespaced 15:27:55 oh 15:28:04 yes, that follows the KDE4 concept 15:28:13 everything KDE is in /usr/share/kde4 15:28:23 KDE5 will be in /usr/share/kde5 15:28:27 uhm 15:28:31 tosky: Prevents conflicts with KDE 4 and ancient KDE 3 stuff. 15:28:36 so it makes sense (IMO) to have FW in /usr/share/kf5 15:28:41 dvratil: /usr/share/kde4 was used only because it conflicted with kde3 stuff. 15:28:47 Kevin_Kofler: packagers from other distributions worked to prevent this 15:29:00 that's not the case with KF5, so should we drop the prefix for KF5? 15:29:12 dvratil: do you think /usr/share/kf5 or /usr/share/kde5 is needed to avoid conflicts still? 15:29:30 there are no conflicts with KDE4 as far as I know 15:29:36 We have kdelibs3 stuff in /usr/share (e.g. /usr/share/apps). 15:29:40 rdieter: I think that for *libraries* (kf5), conflicts are bugs 15:29:45 , only use prefix if it's necessary (or if you think it useful thinking forward to the future) 15:29:46 KDE 4 is in /usr/share/kde4/apps. 15:29:57 hmm, wait a sec 15:29:59 applications are different 15:30:01 One source of conflicts is KatePart syntax highlighting files. 15:30:11 IIRC one of the reasons we did /usr/share/kde4/apps to begin with. 15:30:13 That's a library. 15:30:26 there might be some confusion in /usr/libexec 15:30:30 I don't think it's a good idea to use non-namespaced installdirs. 15:30:30 I recall something in kde3/kde4 libkhtml conflicting too 15:30:40 libexecdir also definitely needs to be namespaced. 15:30:47 kf5-kinit install /usr/libexec/start_kdeinit, while kdelibs installs /usr/libexec/kde4/start_kdeinit 15:30:58 (there might be others, this is one I remember from top of my head) 15:31:10 And if other distros checked coinstallation with KDE 4 in /usr/share/apps, that doesn't help us because our /usr/share/apps is KDE 3, not 4. 15:31:20 Please keep the namespacing. 15:31:26 Kevin_Kofler: maybe we can fix it in kf5 15:31:31 or we can just blow KDE3 away :P 15:31:33 And the libexecdir stuff should go to /usr/libexec/kf5, not /usr/libexec. 15:31:35 dvratil: -1 15:32:08 well, if we keep namespacing somewhere, we can as well keep it everywhere... 15:32:11 so...keep namespacing or remove it? 15:32:22 keep +1 15:32:29 (and make it complete, i.e. also for libexecdir) 15:32:30 remove 15:32:31 namespacing would be the safest course (conflict-wise) 15:32:38 In some places like includedir, it's definitely needed! 15:32:41 remove for libraries, I mean 15:32:45 Kevin_Kofler, it's not 15:32:51 but it can also introduce other problems 15:33:10 dvratil: Why not? 15:33:21 I thought it shouldn't be a problem for libraries, they should be co-installable with kdelibs4 15:33:33 Kevin_Kofler, because the include folders are called /usr/include/$FrameWork 15:33:47 so they don't clash with kde4 or kde3 15:34:00 jgrulich: /usr/lib/lib*.so* should not conflict, I'm not proposing to namespace that. 15:34:29 I think we have a semi-consensus, to namespace only stuff where it makes good sense. 15:34:40 But /usr/include, /usr/libexec and the same places under /usr/share that were namespaced in KDE 4 should stay namespaced. 15:34:41 not sure what that includes exactly yet 15:35:10 I don't agree with that (namespaced things in /usr/share if there is no conflict) 15:35:19 /usr/include uses kf5 namespace 15:35:26 so lets start with easy stuff, is there anything that we know for sure conflicts without namespace? 15:36:08 nothing AFAIK 15:36:12 Unlike namespacing /usr/lib (a bad idea because it requires messing with linker paths, the kdelibs 3&4 coexistence hack is ugly and should not be needed for KF5), namespacing the other stuff shouldn't hurt anything. 15:36:15 (thanks to KDE4 being namespaced) 15:36:42 dvratil: oh? yay 15:37:00 then I'd be tempted to say lets try no namespacing, and see how it goes 15:37:17 there are *potential* conflicts, but all are solved thanks to KDE4 being namespaced (like the libexec thing with kf5-kinit) 15:37:28 only kactivities is conflicting as I remember, there was conflict in solid, but this is already solved in upstream 15:37:34 dvratil: Have you checked with kdelibs3 and kdebase3 though? 15:37:37 Those are NOT namespaced. 15:38:03 Again, all new stuff should be namespaced. 15:38:10 again, I don't agree 15:38:17 time to drop kde3, really 15:38:21 -1 15:38:27 There are still unported apps. 15:38:34 sorry afk ~5 min 15:38:35 checking kdebase3: 15:38:45 which means nobody worked on them for years 15:38:48 no conflict in /usr/bin (all frameworks that install execs have 5 suffix) 15:38:55 which means they are effectively dead 15:39:00 no conflict in /usr/lib (kde3 namespace) 15:39:02 I de-facto maintain kde*3, I can take primary maintainership if than wants me to, and I'm not going to give it up. 15:39:17 dvratil: So far, that was expected. 15:39:24 The problem is the /usr/share/apps stuff. 15:39:30 I have to check on /usr/share 15:39:30 being stubborn won't turn a dead body into a living dancer 15:39:51 Also putting stuff directly into /usr/include is ugly and not necessary. 15:39:54 as I said, apps are different, I was talking (for now) for kf5 (libraries), so no apps/ 15:40:16 so, I asked maintainers of the other distro doing the no-conflict work 15:40:29 directly in /usr/share, but /usr/include/KF5 15:40:29 Using a subdirectory in /usr/include for large frameworks is a standard practice, and KF5 is really a framework of frameworks. :-) 15:40:37 following upstream 15:41:19 tosky: KatePart no longer installs to apps/? 15:41:27 There's also services/… 15:41:43 Both those were under /usr/share/kde4/ for KDE 4, and IMHO should stay namespaced. 15:41:58 services are installed to /usr/share/kde5/, at least what I tried with plasma-framework 15:42:10 And that makes sense. 15:42:13 jgrulich, because I told it to do so 15:42:23 apps/ should also be namespaced. 15:42:31 dvratil: I compiled it myself 15:42:34 dvratil: shouldn't it be kf5 instead of kde5? 15:42:48 tosky, that was a hack for kde5-workspace to find it's stuff :-) 15:42:56 * tosky facepalms 15:42:57 I agree kf5 would make more sense 15:43:16 And includedir too, IMHO. There's already enough of a mess under /usr/include/. 15:44:10 includedir is namespaces by upstream by default, so I agree there 15:44:14 *namespaced 15:45:04 include dir is namespaced upstream too 15:45:32 I guess it's easier to check by installing with upstream default on a VM 15:45:36 That leaves /usr/libexec and /usr/share/{apps,services} and I really don't see a good reason to not namespace them like in KDE 4. 15:45:57 I don't think any framework installs into apps 15:46:03 i.e. /usr/libexec/kf5 and /usr/share/kf5/{apps,services} 15:46:06 because they are libraries, so they have nothing to do in apps 15:46:21 If apps is not relevant, then the discussion is moot for apps. 15:48:21 and there seems to be no conflict with kdebase3 or kdelibs3 in /usr/share 15:49:12 each framework has it's own namespace (so /usr/share/kconfigwidgets, /usr/share/knewstuff, etc.) 15:50:07 Ouch, directly under /usr/share, not even the /usr/share/apps that was at least SOME namespacing by default… 15:50:11 * Kevin_Kofler sees the conflicts come when there will be a KF6! 15:50:20 well, they are libraries 15:50:25 Some stuff might even conflict with non-KDE apps. 15:50:49 other K-applications? 15:50:51 nah 15:50:57 K-directories, I mean 15:51:10 no, because KDE4 application are namespaced and KDE5 will most probably be namespaced too 15:51:54 dvratil: you mean kf5-based apps? 15:52:02 yes, KDE5 is shorter 15:52:15 kf5apps :) 15:52:24 ok, ok 15:52:51 so... 15:53:01 looking at it, we want namespacing in /usr/include and /usr/libexec 15:53:22 that we agree on 15:54:21 about /usr/share, I don't know....there is no conflict in /usr/share, but on the other hand we are namespacing all stuff in include and libexec, why not namespace share too? 15:54:45 "closer to upstream" is my point 15:55:33 I understand it...but then if plasma-framework will insist on using /usr/share/kde5, it all gets messed up 15:55:57 I should probably send a mail about that upstream 15:56:01 exactly 15:56:07 this should be solved there too 15:56:32 if it is a framework, it should (upstream) follow the same rule for the other libraries 15:56:39 yes 15:56:43 if not, it's not a framework -> app, other rules 15:56:54 plasma-framework is tricky 15:56:56 it has both 15:57:28 eh, it does not work this way for frameworks 15:57:33 anyway, this is an upstream discussion 15:57:36 /usr/bin/dpitest 15:57:37 /usr/bin/plasma-shell 15:57:39 /usr/bin/plasmapkg2 15:57:39 and the time is almost over 15:57:57 so quick vote: /usr/share/kf5 or /usr/share ? 15:58:04 dvratil: please cc kde-frameworks-list, not only plasma-devel or whatever list 15:58:09 technically both is possible 15:58:21 +1 /usr/share (follow upstream as it is possible) 15:58:28 +1 /usr/share 15:58:36 I'll send mail directly to kf-list (there are more reasonable people than on plasma-devel) :D 15:58:58 dvratil: also solid has /usr/bin/solidhardware5 15:59:11 that's slightly different IMO 15:59:21 * Kevin_Kofler thinks /usr/share/kf5 is more future-safe… 16:02:49 Our hour is up… 16:03:46 ok, so summary: split kf5-filesystem to kf5-filesystem, kf5-rpmmacros and add kf5-settings 16:03:53 and install Frameworks to /usr/include/KF5, /usr/libexec/kf5, /usr/share 16:04:14 +contact upstream about the Plasma framework 16:07:58 dvratil: I guess you need to add an #action 16:08:06 dvratil: so that it's logged by the bot 16:08:17 #action contact upstream about Plasma framework installing to /usr/share/kde5 16:08:36 dvratil: and #info for the rest :) 16:08:52 #info we will split kf5-filesystem to kf5-filesystem and kf5-rpmmacros and add kf5-settings 16:08:59 dvratil: and #endmeeting if Kevin_Kofler is out, we are out of time 16:09:14 #info we will install into /usr/include/KF5, /usr/libexec/kf5 and /usr/share 16:09:15 I'm here, rdieter was supposed to lead the meeting today though… 16:09:44 and that's all from me. I did not expect to take full hour with my KF5 update, sorry :-) 16:09:53 #topic 4.13.0 status update 16:09:58 rdieter: Anything from you on that? 16:09:59 oh, right, sorry 16:11:06 Whatever, let's skip that and close the meeting now, time's up… 16:11:08 #undo 16:11:08 Removing item from minutes: 16:11:13 #endmeeting