15:00:20 <rdieter> #startmeeting kde-sig
15:00:20 <zodbot> Meeting started Tue Mar 21 15:00:20 2017 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:20 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:20 <zodbot> The meeting name has been set to 'kde-sig'
15:00:22 <rdieter> #topic roll call
15:00:30 <rdieter> hi all, friendly kde-sig meeting, who's present today?
15:00:31 <lupinix> hi :)
15:01:02 <tosky> hi
15:01:04 <pino|work> o/
15:01:07 <than> present
15:01:09 <dvratil> hi
15:01:21 <rdieter> #info rdieter lupinix tosky pino|work than dvratil present
15:01:27 <rdieter> #chair lupinix tosky pino|work than dvratil
15:01:27 <zodbot> Current chairs: dvratil lupinix pino|work rdieter than tosky
15:01:37 <mbriza> hello
15:01:55 <rdieter> #info mbriza present
15:01:56 <rdieter> hi
15:01:59 <rdieter> #chair mbriza
15:01:59 <zodbot> Current chairs: dvratil lupinix mbriza pino|work rdieter than tosky
15:03:08 <rdieter> #topic agenda
15:03:13 <rdieter> ok, what to discuss today?
15:03:34 <rdieter> old one from last week possibly: using lookaside cache for uptsream patches
15:03:59 <lupinix> open topics from last meeting: qt 5.8, lookaside cache, voting @gnome-software
15:04:22 <rdieter> ok
15:04:46 <rdieter> anything else?
15:05:14 <lupinix> nothing else here
15:05:21 <rdieter> ok
15:05:32 <rdieter> #topic f26 PackageKit/package-management
15:06:08 <rdieter> so, since last week I learned that discover offers the ability to install standalone packages (with some bugs/quirks, bugs filed)
15:06:13 * jreznik_ is here
15:06:18 <rdieter> #info jreznik_ present
15:06:25 <lupinix> dnfdragora guys added that option as well
15:06:36 <rdieter> so I'm not nearly as strongly in favor of pushing for gnome-software as before
15:07:01 <rdieter> we still lack a packagekit session interface support
15:07:49 <rdieter> looks like upstream (apol mostly) had an interest in looking into adding it to discover (future feature)
15:08:14 <lupinix> yes
15:08:21 <rdieter> so, how important does everyone else feel about PK session support?
15:08:41 <rdieter> *right now*.  enough that it warrants using gnome-software?
15:08:52 <lupinix> no
15:08:55 <lupinix> not for me
15:09:13 <rdieter> lupinix: can you explain why?
15:09:22 <rdieter> (that's one part i don't understand)
15:09:46 <rdieter> I mean, it would serve a single purpose, and not get in the way otherwise (imho)
15:09:59 <lupinix> because (as i explaned @last meeting) we have much redundant functionality then and also gnome-software does not integrate well
15:10:29 <rdieter> the PK session interface support isn't important to you then?
15:10:38 <lupinix> yes
15:10:51 <rdieter> are you thinking about *you* or our users?
15:11:45 <rdieter> because it pains me when users report things not working or lacking auto-install drivers/codecs.  and our answer is: yeah we know, we choose to keep it broken :-/
15:11:45 <lupinix> users, for myself i only use dnf for codecs etc. anyway and also remove things like discover
15:12:07 <rdieter> does that not bother you?
15:12:41 <lupinix> it does, but bad integration bothers me too
15:12:55 <rdieter> integration trumps functionality?  really?
15:13:11 <rdieter> that's the part I do not understand
15:13:23 <lupinix> it's simply my opinion ;)
15:14:02 <rdieter> can you help me understand?  becuase to me: first and foremost, something needs to work.  very much secondary is polish and look-and-feel, integration
15:15:35 <rdieter> by your definition, as long as something integrates, it doesn't matter how badly it actually works
15:15:43 <lupinix> well, i don't see a big improvement on auto install of codecs, especially as people have to find out first that they need to add rpmfusion first anyway
15:16:02 <rdieter> lupinix: so you're saying the PK session interface isn't important (to you)
15:16:18 <mbriza> isn't that going to get magically solved in f26?
15:16:20 <rdieter> make up your mind :)  first you say it was lack of integration :)
15:16:30 <rdieter> which is it?  both?
15:16:55 <lupinix> mbriza: magically solved?
15:17:19 <mbriza> well i don't know the details but there is work going underway for the possibility to install 3rd party software in fedora
15:17:19 <rdieter> mbriza: I'm not aware of any magic solution
15:17:33 <mbriza> with some kind of "trusted" 3rd party repositories
15:17:44 <mbriza> dunno if it includes codecs too
15:18:00 <rdieter> mbriza: curated 3rd-party metadata only repos, for appdata discovery, I believe
15:18:14 <rdieter> pretty sure that won't include codecs (for legal reasons)
15:19:04 <lupinix> my point is: as long as users have to google etc. to get codecs anyway, we don't need pk session be default to install them. users have to get into it anyway
15:19:10 <rdieter> mbriza: anyway, that's a separate issue
15:19:22 <mbriza> rdieter: i'm not keeping track of that, i just thought it'd solve this too in some way
15:19:26 <rdieter> lupinix: it's more than just codecs, though that's one main use of the feature
15:19:52 <rdieter> lupinix: includes also printer drivers (just got a bug files about drivers failing to auto-install)
15:20:19 <rdieter> .bug 1433510
15:20:19 <zodbot> rdieter: Bug 1433510 – KONICA MINOLTA PP1350W - https://bugzilla.redhat.com/1433510
15:20:51 <rdieter> lupinix: so do we tell ^^, sorry, kde-sig chooses not to support that
15:21:02 <rdieter> it's not important
15:21:42 <lupinix> it is important, but not important enough to pull in gnome software @my opinion
15:22:27 * rdieter shakes head, that's just sad :(
15:22:29 <Kevin_Kofler> +1
15:22:34 <Kevin_Kofler> (to lupinix)
15:22:55 <Kevin_Kofler> And also, this has been broken for a couple releases already.
15:23:01 <rdieter> ok, since no one else is talking, sounds like no one else feels strongly either
15:23:07 <Kevin_Kofler> Printer driver auto-installation last worked many moons ago.
15:23:16 <Kevin_Kofler> At least we'll stop claiming it works.
15:23:32 <rdieter> Kevin_Kofler: we'd hoped it would get fixed, sooner or later... but much time has passed and the likelyhood is close to zero now
15:23:51 <Kevin_Kofler> I wonder whether we should consider disabling the system-config-printer support in kde-print-manager entirely, auto-installation of drivers is its main purpose.
15:23:52 <rdieter> which is why I'm proposing to actually *do* something about it now
15:24:11 <Kevin_Kofler> It would kill another GTK+ dependency (see my p-m-no-s-c-p builds in the Kannolo Copr).
15:24:22 <rdieter> no, please no
15:24:39 <rdieter> it can still work for users who choose to actually install a (working) PK session client
15:24:42 <rdieter> (like gnome-software)
15:25:22 <rdieter> anyway, I guess we can move on, nothing useful or constructive is coming from further discussion here
15:26:00 <rdieter> oh, related:  I submitted changes to include plasma-discover by default, and use it as default rpm mime handler
15:26:07 <rdieter> and to drop apper
15:26:14 <rdieter> per last meeting
15:26:25 <lupinix> thanks :)
15:27:29 <rdieter> #topic use of lookaside cache
15:28:30 <rdieter> So, to explain this topic.  When doing recent kf5/plasma updates, I started putting patches pulled from upstream SCM into lookaside cache instead of adding them to git
15:28:58 <rdieter> it makes things a little easier to script mass updates for me
15:29:16 <rdieter> (because obviously newer versions already include the patches, so they get dropped automatically)
15:29:36 <rdieter> but some folks didn't like that for various reasons
15:29:42 <Kevin_Kofler> rdieter: IMHO, the default RPM MIME handler should be dnfdragora, once the changes for https://github.com/manatools/dnfdragora/issues/15 are in Fedora.
15:29:43 <rdieter> including Kevin_Kofler
15:29:52 <Kevin_Kofler> It handles GPG key imports correctly, Discover does not.
15:30:02 <rdieter> Kevin_Kofler: I don't recall, did we agree on that last meeting?
15:30:06 <rdieter> that wasn't in my notes
15:30:41 <Kevin_Kofler> The commit implementing the main part of #15 (minus .desktop file tweaks that could be done downstream in a few minutes if needed) was not there last week. :-)
15:31:07 <rdieter> ok, so you're proposing something new, not yet discussed
15:31:25 <Kevin_Kofler> (Sorry for bringing this up late, when you wanted to move on already, I was AFK for a couple minutes.)
15:32:12 <rdieter> I *think* I vaugely agreed that we could include it by default, for package management purposes
15:32:22 <lupinix> yes
15:33:06 <rdieter> any objections to including dnfdragora (and qt interface) by default on kde spin?
15:33:19 <rdieter> (or comments?)
15:33:55 <rdieter> Kevin_Kofler: ^^ may be possible to be handled via rich deps
15:33:57 <lupinix> we voted on that last week afair
15:34:01 <pino|work> nope (objections)
15:34:28 <rdieter> ok, let's 'just do it', sorry I forgot that part (had to leave abruptly)
15:34:29 <Kevin_Kofler> No objections from me, I proposed it. :-)
15:34:43 <lupinix> https://meetbot.fedoraproject.org/fedora-meeting/2017-03-14/kde-sig.2017-03-14-15.06.log.html at 15:44:35
15:34:46 <Kevin_Kofler> I guess the default RPM file handler discussion can be had once the dnfdragora changes are complete in Fedora.
15:34:51 <rdieter> once mime handler is supported, then we can consider using it
15:34:55 <rdieter> right
15:35:09 <rdieter> can't use it before it's ready :)
15:35:14 <Kevin_Kofler> So now to the next topic. :-)
15:35:16 <Kevin_Kofler> For the lookaside cache patches, I have several issues with that:
15:35:18 <Kevin_Kofler> * They hide the contents of the patches from cgit, requiring to clone the repository and run fedpkg sources to get them.
15:35:19 <Kevin_Kofler> * You do not even document where those patches come from. IMHO, if you really want to ship a patch as an upstream source, there needs to be at least the commit ID as a specfile comment (ideally in the form of a commits.kde.org link) as per:
15:35:21 <Kevin_Kofler> https://fedoraproject.org/wiki/Packaging:SourceURL
15:35:52 <rdieter> maybe, but that would defeat the purpose of doing it in the first place :(
15:36:02 <rdieter> that would be more work, not less
15:36:10 <Kevin_Kofler> I would complain less if the commits.kde.org links were in the specfile, because that gets me quickly to the upstream patch from the cgit.
15:37:00 <lupinix> are only upstream patches @lookaside or all patches
15:37:03 <Kevin_Kofler> Right now, we have something shipped as an upstream source file with no clue as to where/how it can be obtained, which is IMHO a violation of the above packaging guideline.
15:37:09 <rdieter> lupinix: only upstream
15:37:26 <rdieter> Kevin_Kofler: that's a fair criticism.
15:37:42 <pino|work> or use patches got as `git format-patch`, so they have metadata such as commit id, message, author, etc
15:37:44 <rdieter> ok, if I continue the practice, I'll include links or commit id's
15:37:58 <Kevin_Kofler> pino|work: That does not help because you have to get the patch first to retrieve the metadata.
15:38:01 <rdieter> pino|work: they are from format-patch
15:38:13 <Kevin_Kofler> Extracting the commit ID from the patches for the specfile should be doable with a script.
15:38:20 <rdieter> the metadata is in the patches, but that's not good enough
15:39:37 <rdieter> well, it's a gray area, but like I said, it's a valid criticism
15:39:49 <rdieter> getting the metadata now requires a little extra work (fedpkg sources)
15:40:13 <rdieter> any other comments?
15:40:36 <lupinix> for me links in spec to the commits (so can get the patch by copy paste the link) would be fine
15:40:51 <rdieter> (bonus of this method is that upstream patches don't litter git history/size)
15:41:02 <pino|work> having patches as normal files would be better imho...
15:41:31 <rdieter> some of our plasma pkg repos are getting sizable, fwiw
15:41:32 <lupinix> in general yes, but i see rdieter's point of "auto clean up"
15:41:32 <Kevin_Kofler> The point of the lookaside cache is really to not litter git with binary files. Patches are text files that git handles very well. :-)
15:41:37 <Kevin_Kofler> So I agree with pino|work there.
15:42:15 <Kevin_Kofler> rdieter: How do you produce the PatchNNN: lines in your specfiles for upstream patch series? Do you write them by hand or do you use a script?
15:42:21 <rdieter> so git binary patches are ok for lookaside, otherwise not?
15:42:32 <rdieter> Kevin_Kofler: I've done both
15:42:40 <rdieter> if it's just a small number, by hand
15:42:56 <Kevin_Kofler> Because if you already have a script, that would be a good place to automatically produce the comments with the commits.kde.org links.
15:43:15 <rdieter> I'll try to do that, ok
15:43:29 <rdieter> I think that's fair, even if it's a little more work
15:44:21 <rdieter> #info rdieter to work on including commit id's or commits.kde.org links for future lookaside patches
15:44:37 <Kevin_Kofler> Grep the specfile for the tarball name, extract the repo name from there. Extract the commit hash from the patch. Then you can build a commits.kde.org URL.
15:45:20 <rdieter> and we do have sources.basename to leverage as well
15:45:30 <rdieter> used by other scripts
15:45:49 <rdieter> anything else?
15:46:04 <lupinix> sounds good to me, nothing else here
15:46:14 <rdieter> #topic open discussion
15:46:37 <rdieter> skipping Qt 5.8, see no heliocastro, but we can talk a bit about it too, if anyone has something to add
15:46:39 <lupinix> we had the qt 5.8 topic last week that has been postponed
15:46:41 <lupinix> ok
15:46:57 <lupinix> was also mostly a request by Kevin_Kofler
15:46:58 <rdieter> I don't have anything new on the topic
15:47:14 <rdieter> Kevin_Kofler wants newer QtWebEngine everywhere
15:47:22 <rdieter> :)
15:47:30 <lupinix> well, with serious reason: security fixes
15:48:25 <lupinix> it is bad that we have to update whole qt to get these fixes… or have to try to backport
15:48:32 <rdieter> upstream's handling of Qt 5.8 vs 5.9, is still a bit unfortunate and bad no matter what we do
15:48:42 <lupinix> yes :(
15:49:26 <rdieter> anyway, I still think the prior tenative plan is best: import 5.8 into rawhide asap, then we can consider options
15:49:47 <lupinix> yes
15:50:03 <tosky> just today another bug was found due most likely to 5.8
15:50:06 <rdieter> (and start more seriously testing it)
15:50:15 <tosky> https://bugs.kde.org/show_bug.cgi?id=377748
15:50:29 <rdieter> ouch
15:51:29 <tosky> there was a list apparently but it was lost on notes.kde.org
15:51:33 <tosky> list of bugs
15:51:35 <rdieter> we already knew upgrading to 5.8 wouldn't be smooth wrt plasma
15:51:50 <rdieter> :(
15:52:00 <lupinix> yes, so import @f26 is no solution for now :(
15:52:55 <rdieter> As an aside, I started working on (kf5) calligra3 packaging yesterday
15:53:01 <rdieter> and todo: kexi 3
15:53:46 <rdieter> (I'd worked a bit on in a few weeks ago, but I lost my work-in-progress somewhere, probably due to switching machines/laptops)
15:55:59 <lupinix> nice
15:56:33 <rdieter> anything else worth mentioning before ending meeting
15:56:34 <rdieter> ?
15:57:16 * lupinix wonders whether there is any solution @qtwebengine security… i'm even start to think that firefox as default is better as it gets updates quickly… (as i consider security > integration)
15:57:29 <lupinix> s/i'm/i
15:57:38 <lupinix> until that is solved…
15:58:26 <lupinix> imho that can be solved with upstream only, and i'm wondering why they don't take care about security fixes in time, as they also sell that stuff
16:00:10 <Kevin_Kofler> Well, in theory I could try backporting security fixes from 5.8.0 to 5.7.x, and from 5.9.x to 5.8.0 or 5.7.x. It's just that it's a lot of work.
16:00:12 <lupinix> but even with firefox we have that @several places @kdepim now
16:00:45 <Kevin_Kofler> And in between upstream releases, there is not much I can do because I would have to track down all the fixes in the huge Chromium history myself, they only do mass backports for Qt releases.
16:01:08 <lupinix> yes, i know :( that has to be fixed upstream, not downstream
16:01:17 <rdieter> I don't think there's any option other than to rely on Qt project and their releases (and policy)
16:01:53 <rdieter> and if you want things better, the best way to help is to contribute to Qt project directly
16:01:58 <lupinix> i'm wondering whether KDE has the power to discuss that topic with them
16:02:21 <Kevin_Kofler> At least QtWebEngine GETS security fixes, unlike the ancient QtWebKit we ship.
16:02:30 <Kevin_Kofler> We should ship the community branch for Qt5WebKit.
16:02:43 <Kevin_Kofler> But I have no plan as to users of Qt4WebKit (KNode, Amarok, …).
16:03:19 <lupinix> hard plan would be to retire… but not good solution wither…
16:03:21 <lupinix> *either
16:03:34 <Kevin_Kofler> The community branch does not support Qt 4, the conditionals were removed by the Qt Project even before the community picked it up, and the community developers are also adding more Qt-5-isms (new signal/slot syntax etc.).
16:04:02 <lupinix> .nextmeetingds
16:04:04 <lupinix> .nextmeetings
16:04:04 <zodbot> lupinix: One moment, please...  Looking up the channel list.
16:04:07 <Kevin_Kofler> So readding Qt 4 support would be a pain. The team that picked it up clearly does not care.
16:04:09 <zodbot> lupinix: In #fedora-meeting is CommOps IRC Meeting (starting in 25 minutes)
16:04:11 <zodbot> lupinix: In #fedora-meeting is DotNet IRC Meeting (starting in 2 hours)
16:04:14 <zodbot> lupinix: In #fedora-meeting-1 is Server SIG (starting in 3 hours)
16:04:17 <lupinix> ok, not blocking another meeting
16:04:17 <zodbot> lupinix: In #fedora-meeting is G11N  (starting in 12 hours)
16:04:20 <zodbot> lupinix: In #fedora-meeting is Diversity Team IRC Meeting (starting in 18 hours)
16:04:21 <pino|work> lupinix-the-spammer :p
16:04:25 <lupinix> :D
16:04:34 <Kevin_Kofler> But it would help if we had at least the current Qt5WebKit.
16:04:36 <rdieter> Kevin_Kofler: we could consider dropping (qt4) qtwebkit
16:04:44 <rdieter> not sure how much that would affect though
16:04:54 <Kevin_Kofler> No more KNode and Amarok? Not a realistic plan IMHO.
16:04:56 <rdieter> it's painful, but may be for the best
16:05:08 <rdieter> I thought amarok could be built without it
16:05:16 <rdieter> I could be wrong though
16:05:20 <Kevin_Kofler> KNode could be downgraded to the last version that used KHTML, that would be around 4.3 I guess, would also kill Akonadi 4 for good.
16:05:32 <pino|work> knode doesn't use akonadi
16:05:45 <Kevin_Kofler> It doesn't use it, but it links it!
16:05:48 <rdieter> indeed, kdepim4 BR: kdelibs4-webkit-devel
16:05:51 <rdieter> :(
16:05:52 <pino|work> not by itself
16:05:56 <Kevin_Kofler> The whole kdepim stack has to be downgraded by a pre-Akonadi version.
16:06:04 <Kevin_Kofler> *kdepim4
16:06:06 <rdieter> ok, may need to defer that decision
16:06:11 <rdieter> Kevin_Kofler: don't be silly
16:06:11 <pino|work> oh joy, not again that please
16:06:14 <Kevin_Kofler> That would then also remove the QtWebKit dep.
16:06:21 <Kevin_Kofler> How is it silly?
16:06:31 <Kevin_Kofler> We are shipping an unmaintained branch either way.
16:06:45 <pino|work> yeah, in favour of another html engine (khtml) which is even way more old and unmaintained than anything else mentioned here so far
16:06:46 <Kevin_Kofler> So better ship one that does not depend on Qt4WebKit and KDE 4 Akonadi.
16:06:49 <rdieter> oh, you amended "whole kdepim stack" to just kdepim4
16:07:04 <Kevin_Kofler> The kdepim 5 stack has no pre-Akonadi version. :-)
16:07:23 <rdieter> kdepim4 doesn't actually *use* or need akonadi
16:07:24 <pino|work> knode in 4.3 is way too old
16:07:31 <rdieter> (at least the parts we build, do not)
16:07:46 <Kevin_Kofler> KHTML is actually NOT vulnerable to many of the Chromium / QtWebKit vulnerabilities around there.
16:08:00 <Kevin_Kofler> And ones that are reported against KHTML, I backported the fixes to even the kdelibs3 version.
16:08:04 <pino|work> just because nobody cares to inspect it anymore
16:08:13 <tosky> no, just no
16:08:14 <Kevin_Kofler> I think it is in a much better shape security-wise than the dead Qt4WebKit with many known CVEs.
16:08:28 <pino|work> lol please, get back to the real world
16:08:53 <Kevin_Kofler> KNode is not a web browser, KHTML is more than enough for it.
16:09:00 <rdieter> looks like the list of what depends on qtwebkit is still quite large, so dropping isn't really a good option (yet)
16:09:57 <pino|work> rdieter: see https://wiki.debian.org/Qt4WebKitRemoval for example (what's in debian currently)
16:10:18 <pino|work> (sure, i know fedora is not debian, still there are common packages)
16:10:40 <rdieter> list looks close to what I just generated, yeah
16:10:48 <Kevin_Kofler> For KNode, I see really no other option than switching back to KHTML if we want to drop Qt4WebKit and keep KNode.
16:11:03 <Kevin_Kofler> It's either KHTML or Qt4WebKit.
16:11:24 <pino|work> let's forget about that until there's the pressing need to drop qt4webkit, shall we?
16:11:51 <Kevin_Kofler> Many arbitrary code execution CVEs not a pressing need?
16:12:08 <rdieter> it will take careful planning and would be a fair amount of work.
16:12:24 <pino|work> sure, then pick the list of qt4webkit users, and start work on them
16:12:27 <rdieter> Kevin_Kofler: who's going to work on it, will it be a priority over other important tasks?
16:12:32 <pino|work> port them, or drop them
16:12:34 <Kevin_Kofler> The whole kdepimlibs and kdepim4 stack needs to be downgraded.
16:12:49 <pino|work> lol no
16:13:01 <Kevin_Kofler> And KDE 4 akonadi retired as it should, it is just sitting there with no purpose now.
16:13:13 <Kevin_Kofler> I'll try to work on it.
16:13:18 <rdieter> Kevin_Kofler: true, akonadi4 exists only so kdepim4 can build
16:13:32 <rdieter> but that's just one piece of the bigger puzzle
16:13:46 <rdieter> no point in handling kdepim4 alone, and leaving everything else
16:13:59 <rdieter> (well, little point)
16:14:01 <pino|work> rdieter: kdepimlibs 4.x needs it too, and some of the libraries of it are used in other projects (at least, that's what i remember looking at what's in debian currently)
16:14:43 <pino|work> eg kmymoney and calligra use akonadi libraries from kdepimlibs
16:14:50 <rdieter> pino|work: yeah
16:15:25 <pino|work> so knode will be a problem only when it is the last user of kdepimlibs
16:16:24 <rdieter> dnf repoquery --whatrequires kdepimlibs-akonadi --alldeps  => calligra, kgpg, kmymoney, knode, kpilot, pykde4, slfphone, simon, syncevolution-kde
16:17:50 <pino|work> hm kgpg too? isn't framework-based now?
16:18:19 <rdieter> hrm, f25's kgpg is still kde4-based, 16.12.x releases include kf5 port
16:18:21 <rdieter> my bad
16:18:28 <pino|work> np
16:18:29 <rdieter> I did repoquery on my f25 box
16:18:49 <rdieter> and can soon remove calligra from the list
16:19:26 <rdieter> so, not viable easily, not without a lot of work at least
16:19:51 <mkyral_> Kevin_Kofler: it is possible to build kdepim without webkit: try the option -DKDEPIM_NO_WEBKIT:BOOL=ON https://bugs.kde.org/show_bug.cgi?id=328866
16:19:59 <Kevin_Kofler> pino|work: Do they use libraries that necessarily use Akonadi, or do they just use libraries that happen to use Akonadi in current kdepimlibs, but did not in older versions?
16:20:31 <lupinix> have to leave now, bye
16:20:33 <rdieter> mkyral_: nice
16:20:41 <rdieter> we may want to consider that
16:20:50 <Kevin_Kofler> mkyral_: Ah, so using QTextBrowser? Does that include KNode?
16:21:17 <pino|work> rdieter: and given there's pykde4, there's also the challenge to know what actually uses the akonadi bindings (hopefully noone)
16:21:20 <Kevin_Kofler> I think RHEL does not build KNode at all, so the patch (which comes from RHEL) is only for KMail.
16:21:29 <Kevin_Kofler> (patch that got upstreamed)
16:21:37 <rdieter> pino|work: anything that tries wont' work anyway, no real loss
16:21:56 <mkyral_> rdieter, Kevin_Kofler: i tried a scratch build on a VM (don't have the VM anymore) and the only notable difference was a little bit 'uglier' rendering of some email headers. I did not try knode though, IIRC
16:23:48 <Kevin_Kofler> Hmmm, KNode does not directly link against QtWebKit!
16:23:55 <Kevin_Kofler> It must come through the messageviewer.
16:24:01 <mkyral_> Kevin_Kofler: RHEL does not build almost anthing from kdepim, unfortunatelly (ditched due to the webkit dependency, not added back again)
16:24:05 <Kevin_Kofler> So I guess building with QTextBrowser should work.
16:24:15 <Kevin_Kofler> https://cgit.kde.org/kdepim.git/tree/knode/CMakeLists.txt?h=KDE/4.14#n111
16:24:25 <Kevin_Kofler> It even links KHTML explicitly, for some reason.
16:24:49 <Kevin_Kofler> (Is it in fact already using KHTML, not QtWebKit? Or is that a leftover from ancient times?)
16:25:15 <rdieter> we're almost out of time, can continue in #fedora-kde
16:25:23 <rdieter> any last thoughts before ending?
16:26:53 <mkyral_> Kevin_Kofler: the patch was for fixing the broken build of kmail, there was nothing else failing to build
16:27:08 <rdieter> ok, thanks everyone!
16:27:12 <rdieter> #endmeeting