15:05:57 <Kevin_Kofler> #startmeeting KDE SIG Meeting 15:05:57 <zodbot> Meeting started Tue Aug 19 15:05:57 2014 UTC. The chair is Kevin_Kofler. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:05:57 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:06:01 <Kevin_Kofler> #meetingname kde-sig 15:06:01 <zodbot> The meeting name has been set to 'kde-sig' 15:06:05 <Kevin_Kofler> #topic Roll call 15:06:09 * Kevin_Kofler is present, who else? 15:06:34 <Kevin_Kofler> [17:05] * danofsatx is here for KDE, wherever it is.... 15:06:35 <Kevin_Kofler> [17:05] <tosky> here 15:06:36 <dvratil> heya 15:07:03 <than> present 15:07:05 <pino|work> me 15:09:02 <Kevin_Kofler> rdieter: Ping? 15:10:52 <rdieter> here 15:11:45 <Kevin_Kofler> #chair danofsatx tosky dvratil than pino|work rdieter 15:11:45 <zodbot> Current chairs: Kevin_Kofler danofsatx dvratil pino|work rdieter than tosky 15:12:05 <Kevin_Kofler> #info danofsatx, tosky, Kevin_Kofler, dvratil, than, pino|work, rdieter present. 15:12:08 <Kevin_Kofler> #topic Agenda 15:12:22 <Kevin_Kofler> So, what's up this week? 15:12:29 <dvratil> I can do KF5/Plasma update 15:15:40 * rdieter can't think of anything, or recent bugs worth special attention 15:15:48 <Kevin_Kofler> #topic KF5/Plasma5 update 15:15:54 <Kevin_Kofler> Let's start with this then. 15:16:08 <dvratil> all Fedora repos and Copr are now KF5 5.1.0 15:16:22 <dvratil> and Plasma 5 copr is Plasma 5.0.1 - so completely up to date with upstream \o/ 15:16:22 <Kevin_Kofler> Great. 15:16:57 <dvratil> I did some adjustments to KDE 4 baloo package, so the coinstallability/upgrade path should now be much better 15:17:02 <Kevin_Kofler> Do we have all the Frameworks packaged now? 15:17:07 <dvratil> all stable ones, yes 15:17:34 <danofsatx> back 15:17:39 <Kevin_Kofler> So can we have a kf5-devel metapackage that drags in everything now? (And a qt5-devel one also.) 15:18:08 <Kevin_Kofler> It'd really make us packagers' life easier to be able to just BR kf5-devel, especially when porting old specfiles from kdelibs4-devel. 15:18:27 <dvratil> I'm for having kf5-devel for users, but I'm strictly against using kf5-devel in spec files 15:19:07 <dvratil> builds take ages already, and installing 60+ devel packages with all their -devel dependencies won't help 15:19:15 <dvratil> not metioning that it goes completely against the very idea of Frameworks 15:19:54 <Kevin_Kofler> The thing is that I don't agree with "the very idea of Frameworks" to begin with. :-) 15:20:07 <Kevin_Kofler> So I want a way to hide it from us packagers. 15:20:59 <Kevin_Kofler> People who really want to pick their cherries one by one from the huge box can still do it. 15:21:04 * rdieter agrees with dvratil 15:21:07 <Kevin_Kofler> It'd just not force everyone to do that. 15:21:28 <pino|work> hasn't this been discussed before? 15:21:38 <Kevin_Kofler> pino|work: It didn't come to a conclusion, it was deferred. 15:21:51 <dvratil> Kevin_Kofler, there's even a script (I can find it somewhere) that simply extracts all dependencies from CMake and writes them to a specfile -> use that 15:22:11 <rdieter> dvratil: oh, details? 15:22:13 <Kevin_Kofler> dvratil and rdieter are free to change kf5-devel to individual packages in the stuff they comaintain. 15:22:34 <Kevin_Kofler> But new packagers shouldn't be forced to use it. 15:22:37 <pino|work> Kevin_Kofler: that would make a mess in maintaineance 15:22:54 <Kevin_Kofler> Especially the template specfile we have for beginners could REALLY use a kf5-devel. 15:23:04 <Kevin_Kofler> Right now it has kdelibs4-devel. 15:23:10 <rdieter> I'm ok with dvratil's suggestion to make life easier for users, whether that be metapackages or comps group (would prefer the latter honestly), but fedora packaging should not rely on it 15:23:14 <dvratil> rdieter, apol has written some script that simply extracts dependencies by matching FindPackage( ...) in all CMakeLists.txt - I think it's somewhere on kde git, but I can ask him to send it to me 15:23:18 <dvratil> or to share it 15:23:26 <Kevin_Kofler> Requiring people to figure out the exact list of KF5 deps is one more step separating them from a working package. 15:23:33 <Kevin_Kofler> Our barrier to entry is already too high. 15:23:52 <Kevin_Kofler> https://fedoraproject.org/wiki/File:SIGs_KDE_KDE4FAQ_kde4_foo.spec 15:23:58 <dvratil> Kevin_Kofler, our barrier to entry is high for bazillion of different reasons, having few more BRs is not one of them 15:24:01 <Kevin_Kofler> I've more or less taken up maintainership of that one. 15:24:15 <rdieter> Kevin_Kofler: we can have such a package, and feel free to use it during initial packaging steps, but it needs to be clarified before/during review to use minimal BuildRequires 15:24:18 <Kevin_Kofler> And I want to do a KF5 one that doesn't require changing for every single package. 15:25:16 <rdieter> I don't see it as much of a burden, changes will have to be made anyway when transitioning from kde4 => kf5 15:25:16 <Kevin_Kofler> rdieter: It's kinda like @buildsys-build, not every package out there uses C++, yet g++ is still always dragged in automatically. 15:25:32 <Kevin_Kofler> It's just not practical to BR every single package each time. 15:25:46 <rdieter> how many kf5 frameworks are there? 15:25:55 <Kevin_Kofler> It's similar for our stuff (and I'd use a comps group, but RPM doesn't allow to BR a comps group, @buildsys-build is very special there). 15:26:04 <Kevin_Kofler> rdieter: Too many. :-) 15:26:08 <dvratil> ~60, about 10 unstable (no release yet) and ~30 once everything is done 15:26:09 <rdieter> do we have any plasma5 examples that use a large number of them yet? 15:26:25 <dvratil> probably plasma-workspace 15:26:27 * dvratil checks 15:26:44 <dvratil> https://github.com/FedoraKDE/fedora-kde-frameworks/blob/master/spec/plasma-5/plasma-workspace/plasma-workspace.spec 15:27:09 <rdieter> ok, if a significant number of kf5 consumers will need ~20+ BuildRequires, then I'd be more sympathetic to Kevin_Kofler's cause here 15:27:46 <Kevin_Kofler> Ewww… 15:27:48 <rdieter> so this one has 18-20, depending on how you count 15:28:03 <Kevin_Kofler> (The X11 ones are also horrible, that one could also really use a metapackage, but that's not upon us unfortunately. :-( ) 15:28:09 <rdieter> this is also an example of one that will use a *lot*, most others won't use this many 15:28:15 <tosky> rdieter: if you depend on one Tier3 framework, shouldn't that bring in its dependencies automatically? 15:28:18 <Kevin_Kofler> (At least most of OUR stuff is not going to depend (directly) on X libraries these days.) 15:28:27 <rdieter> tosky: yes 15:28:37 <dvratil> I'd like to point out though that plasma-workspace is huge - most applications will require less 15:28:47 <Kevin_Kofler> tosky: Ewww… Relying on that is a horrible idea. 15:28:50 <Kevin_Kofler> Dependencies can change. 15:28:58 <tosky> Kevin_Kofler: not for kio or kparts 15:29:27 <Kevin_Kofler> And also, the Framework being built against some other Framework doesn't necessarily imply that the -devel package has a Requires on it. 15:29:37 <dvratil> I made sure it has :) 15:29:39 <Kevin_Kofler> It can also be linked "privately". 15:29:40 <rdieter> Kevin_Kofler: relying on a metapackage means we lose out on some things... 15:29:49 <dvratil> it can be also extracted from cmake 15:29:51 <Kevin_Kofler> dvratil: Then that's wrong. 15:30:00 <rdieter> Say, we would want to rebuild all packages that build depends on kf5-foo-devel 15:30:03 <Kevin_Kofler> -devel Requires should only be there if it's part of the link interface. 15:30:15 <Kevin_Kofler> If it's linked with target_link_libraries(PRIVATE …), then no. 15:30:27 <dvratil> only PUBLIC stuff is required 15:30:35 <rdieter> Kevin_Kofler: <nod>, that's what I assumed tosky was talking about 15:30:36 <Kevin_Kofler> That makes sense then. 15:30:39 <dvratil> PRIVATE of course not - there's no need for that, that is only run-time dependency solved by yum 15:31:16 <Kevin_Kofler> Is PUBLIC really (ab)used that much? Link-interface-level dependencies suck! 15:31:17 <rdieter> are there any kf5-related comps groups yet? 15:31:19 * rdieter looks 15:31:43 <dvratil> Kevin_Kofler, it's not just about that, but it's also about referencing other frameworks from public headers 15:32:00 <rdieter> ok, I see kf5-software-development already 15:32:08 <danofsatx> for the record, y'all are way over my head right now.... 15:32:11 <Kevin_Kofler> <rdieter> Say, we would want to rebuild all packages that build depends on kf5-foo-devel 15:32:21 <Kevin_Kofler> Then you query the runtime dependencies to see what actually ends up linking to it. 15:32:38 <rdieter> of course, comps groups cannot be used as dependencies either 15:32:41 <Kevin_Kofler> There will be no runtime deps on stuff that's BRed and not used. 15:32:54 <Kevin_Kofler> Right, that's why I want a metapackage. 15:33:01 <rdieter> Kevin_Kofler: that doesn't track static libs or header-only stuff, but point taken 15:33:34 <Kevin_Kofler> Static libs? Does KDE ship those now?! 15:33:47 <tosky> ehm, one 15:33:50 <dvratil> :-) 15:34:12 <tosky> used only in one place, and I didn't do it 15:34:14 <rdieter> I think Kevin_Kofler is the sole supporter of a metapackage so far? anyone else? If that is so, we may as well move on 15:34:37 <pino|work> he is, and he was also last time this metapackage was discussed 15:34:46 <rdieter> we have a comps group already for development purposes 15:35:12 <rdieter> just make sure it is current and accurate for all kf5 packages, and we should be good 15:35:26 <Kevin_Kofler> I see 27 Qt 5 and KF5 BRs in plasma-workspace. 15:35:42 <rdieter> I skipped Qt5, only included real kf5-*-devel pkgs in my count 15:35:48 <Kevin_Kofler> Those could be replaced by 1 or 2 metapackage BRs (kf5-devel, and maybe qt5-devel, but I guess kf5-devel would drag that in). 15:36:03 <Kevin_Kofler> So we would save up to 26 lines of BRs. 15:36:33 <pino|work> yeah, because you add/remove them at each release... 15:36:36 <Kevin_Kofler> (I'm assuming that kf5-devel would also drag in phonon-qt5-devel, extra-cmake-modules, and the qt5-devel metapackage that I also want.) 15:36:46 <dvratil> *-devel 15:37:13 <rdieter> dvratil: if rpm only supported globs in BuildRequires :) 15:37:34 <Kevin_Kofler> We could even throw the X and Wayland libs into the metapackage too. 15:37:54 <pino|work> why should be X and wayland pulled together? 15:38:10 <Kevin_Kofler> Because we'll be building against both for the foreseeable future. 15:38:20 <pino|work> just in plasma, not elsewhere 15:38:38 <Kevin_Kofler> But I think most stuff outside of the workspace does not need either of those directly. 15:38:44 <Kevin_Kofler> That's what we have an abstraction for. 15:38:50 <Kevin_Kofler> So I wouldn't put those into the metapackage. 15:38:58 <Kevin_Kofler> Only the KF5 and Qt 5 stuff. 15:39:31 <Kevin_Kofler> dvratil: By the way, does BuildRequires: qimageblitz-devel make sense in your specfile? 15:39:44 <Kevin_Kofler> At least the qimageblitz I built is Qt-4-only. 15:39:48 <dvratil> probably not, the deps are copy-paste from kde-workspace 15:39:58 <tosky> qimageblitz can be compiled for Qt5 too 15:40:09 <dvratil> but yeah, we have qimageblitz-qt5 I think 15:40:24 <Kevin_Kofler> Should be fixed in the spec then. 15:40:26 <tosky> I discovered by accident in my devel kdesrc-build-based build 15:40:29 <dvratil> we don't have yet 15:41:03 <Kevin_Kofler> dbusmenu-qt5-devel and qimageblitz(-qt5)-devel are stuff that's currently listed in the generic deps but that would also be candidates for inclusion in kf5-devel. 15:41:20 <Kevin_Kofler> That would mean 28 lines of BRs saved in plasma-workspace alone. :-) 15:41:52 <pino|work> for a minority of users? 15:42:19 <Kevin_Kofler> pino|work: The actual USERS won't notice the difference. 15:42:23 <dvratil> I'd say: I create the -devel subpackage for users and will stick with using exact deps in spec files...you guys do whatever you want 15:42:30 <Kevin_Kofler> (The RUNTIME deps aren't going to be different either way.) 15:42:46 <pino|work> "users" in this case implies "packagers" 15:42:59 <rdieter> users/packagers can always, yum install @kf5-software-development 15:43:06 <dvratil> pino|work, users == developers who want to use develop against KF5 15:43:14 <Kevin_Kofler> For the packagers, nobody forces them to use the metapackage. 15:43:28 <Kevin_Kofler> But I also don't want to force people to NOT use it. 15:43:45 <pino|work> which, as i said above, would create a mess 15:43:54 <rdieter> let's move on... 15:43:57 <pino|work> either all the fedora packaging uses it, or it doesn't 15:44:06 <Kevin_Kofler> In fact, I'm actually interested in using it myself. 15:44:07 <rdieter> we're going in circles 15:44:15 <Kevin_Kofler> pino|work: What mess? 15:44:23 <pino|work> incoherency? 15:44:30 * danofsatx has lost interest 15:44:44 <rdieter> danofsatx: you're not the only one 15:44:44 <Kevin_Kofler> It's a matter of convenience vs. exactness, we have that with other things too. 15:45:43 <rdieter> Kevin_Kofler: can I suggest you bring up the topic on kde@lists.fpo ? if there's a swelling of support, then we can reconsider 15:45:54 <Kevin_Kofler> E.g., you can BR texlive-extras (or what it was called exactly) or you can BR the individual stuff that you actually need. 15:46:13 <rdieter> or devel list even 15:46:31 <Kevin_Kofler> OK, I'll move to the MLs. 15:46:46 <rdieter> thanks 15:48:45 <Kevin_Kofler> So, move on? 15:49:27 <rdieter> yes, please. 15:49:41 <rdieter> I forget if we had other agenda topics or not 15:49:46 <Kevin_Kofler> #topic Open discussion 15:49:50 <Kevin_Kofler> Not really. 15:50:11 <Kevin_Kofler> One thing is that there's Akademy at Brno in 2½ weeks. I suppose the Brno folks will all come. :-) 15:50:27 <tosky> eh 15:50:39 <dvratil> the Brno folks organize it, so I think it would be nice of us to show there :-))) 15:50:43 <Kevin_Kofler> :-) 15:51:11 <Kevin_Kofler> I'm planning to come Saturday morning to Monday evening (the 2 conference days and the workshop day). 15:51:56 * rdieter will miss everyone, please say hi and pass on hugs as appropriate 15:54:45 <Kevin_Kofler> Anything else? 15:55:53 * danofsatx can't think of any KDE specific bugs to address (other than the liveuser one from this morning) 15:57:59 <Kevin_Kofler> If someone's bored here, getting the system-config-printer (and through it GTK+ and Python) deps out of kde-print-manager would be nice… 15:58:28 <Kevin_Kofler> dantti already said he'd accept patches to replace that stuff with native C++ code or with a C library shared with s-c-p. 15:58:32 <rdieter> good point, do we have any bug open tracking that yet? 15:58:49 <Kevin_Kofler> No. I think it'd be best tracked upstream though. 15:59:02 <Kevin_Kofler> We're probably the least affected distro from that issue. 15:59:29 <Kevin_Kofler> Some other distros just do not ship the dependency enabled and so the affected features just don't work there. 15:59:35 <danofsatx> does that even work? I have so many issues with it I just use the CUPS web interface..... 16:00:01 <Kevin_Kofler> Having the stuff be pure KDE without that D-Bus service would probably also make it easier to maintain IMHO. :-) 16:01:00 * Kevin_Kofler still wants to eventually be able to ship a Fedora Remix without GTK+. 16:01:38 <Kevin_Kofler> (Am I still the only one here with that goal?) 16:02:53 <Kevin_Kofler> (Ideally I'd even like the official Fedora KDE to have no GTK+ on it, but that would also require porting things like setroubleshoot and ABRT. I'd just zap SELinux and ABRT from my remix.) 16:04:12 <rdieter> It's a nice goal, and your investigations make it sound doable, but still needs a bit of work too 16:04:37 <Kevin_Kofler> The biggest part would be the installer, I think. 16:05:03 <Kevin_Kofler> But there's work done on a cross-distro Qt-5-based installer that would hopefully be usable by us. 16:05:56 <danofsatx> I have to go. Day job is calling.....stupid users and all. 16:07:15 <Kevin_Kofler> Otherwise, kde-print-manager needs to lose the s-c-p deps, the NM plugin packaging needs to be fixed (last I brought this up, the maintainers involved are not opposed to it, but we need to do the splittings) and there needs to be a KDE version of system-config-firewall and/or firewalld-config. (I personally like the good old static firewall, i.e. the RH/Fedora "iptables service", but firewalld is the new big thing 16:07:17 <Kevin_Kofler> nowadays.) 16:07:44 <Kevin_Kofler> And as I said, setroubleshoot and ABRT are also GTK+. 16:08:32 <rdieter> NM plugins stuff... yeah, Ive been meaning to help there, but my todo list always has higher-priority stuff 16:08:42 <Kevin_Kofler> The bad news is that I haven't been able to work on these items since I first brought them up. 16:09:21 <rdieter> As long as it's documented, then (theoretically) others can help too 16:10:21 <rdieter> fyi, looked over kf5-software-development in comps, and see it actually has only qt5 stuff, no kf5 packages yet at all 16:10:25 <rdieter> boo 16:10:43 <Kevin_Kofler> This is the stuff I specifically blacklisted because of GTK+ (after removing the stuff like SELinux that I didn't want to begin with): http://svn.calcforge.org/viewvc/kannolo/trunk/kickstart/kannolo.ks?revision=28&view=markup#l182 16:10:46 <rdieter> dvratil: is there a list of kf5 packages somewhere ? 16:10:53 <rdieter> I guess I can query pkgdb 16:11:31 <dvratil> https://fedoraproject.org/wiki/KDE_updates 16:12:03 <rdieter> nice 16:12:14 <dvratil> it was supposed to be a tree like with Qt, but the graph has become very messy because of the inter-dependencies 16:13:02 <rdieter> I could add kde4 builds there too 16:13:12 <Kevin_Kofler> So if we don't do the metapackage, I know what I'll have to stuff in one huge BuildRequires: line in the template specfile. :-p 16:13:18 <rdieter> (if that isn't documented elsewhere) 16:13:25 <dvratil> currently I have figured the largest possible groups of packages in tier 3 that can be built in parallel so that there are as little waitRepo tasks in chainbuild as possible 16:13:35 <Kevin_Kofler> BuildRequires: kf5-attica-devel kf5-karchive-devel kf5-kcodecs-devel … (snip dozens more) 16:14:31 <Kevin_Kofler> BTW: "Tier 4"?! I thought there were supposed to be only 3 tiers, and tier 3 stuff already able to depend on other stuff from the same tier? 16:14:37 <Kevin_Kofler> So why is there a tier 4? 16:14:51 <dvratil> Tier 4 is "portingAids" - transitional frameworks that will eventually die 16:15:02 <dvratil> or will be dissolved into other frameworks/applications 16:15:14 <Kevin_Kofler> KHTML will eventually die? :-( RIP! 16:15:54 <Kevin_Kofler> QtWebEngine needs to go away entirely, and QtWebKit is dying, it's time for everything to move (back) to KHTML! 16:17:52 <Kevin_Kofler> I think we're way into stuff that can be discussed on #fedora-kde though, time to end the meeting? 16:18:12 <tosky> dvratil: I can't find the document now, but I think there are two different things: Porting Aids on one side, frameworksintegration and kapidox on the other side 16:19:14 <Kevin_Kofler> Any objections to closing the meeting? 16:19:41 <dvratil> not from me 16:19:44 <pino|work> nope 16:19:52 <Kevin_Kofler> So, thanks for coming! 16:19:55 <Kevin_Kofler> #endmeeting