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