15:05:27 <rdieter> #startmeeting kde-sig
15:05:27 <zodbot> Meeting started Tue Jan 13 15:05:27 2015 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:05:27 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:05:32 <rdieter> #meetingname kde-sig
15:05:32 <zodbot> The meeting name has been set to 'kde-sig'
15:05:35 <rdieter> #topic roll call
15:05:38 <jgrulich> hello
15:05:48 <rdieter> friendly kde-sig meeting, who's present today?
15:07:04 <Kevin_Kofler> Present.
15:08:13 <dvratil> hello
15:08:27 <heliocastro> present
15:08:31 <tosky> ups, here
15:10:20 <pino|work> o/
15:10:33 <rdieter> #info rdieter jgrulich Kevin_Kofler dvratil heliocastro tosky pino|work present
15:10:41 <rdieter> #chair jgrulich Kevin_Kofler dvratil heliocastro tosky pino|work
15:10:42 <zodbot> Current chairs: Kevin_Kofler dvratil heliocastro jgrulich pino|work rdieter tosky
15:10:44 <rdieter> #topic agenda
15:10:47 <rdieter> what to discuss today?
15:11:02 <rdieter> 1.  apper/appstream (and related fun)
15:11:57 <heliocastro> Is the devel gcc+g++ discussion topic for here ?
15:12:24 <rdieter> heliocastro: we could, but I assume we/here would all mostly agree that's a bad idea
15:12:25 <Kevin_Kofler> We can talk about it, but it isn't our decision to make.
15:12:46 <heliocastro> We can talk about implication on our side if they move this ahead
15:12:59 <rdieter> heliocastro: ok
15:13:25 <rdieter> (though we can cheat, and put the needed deps low in our library stack, ie, Qt5, and be done with it mostly)
15:13:29 <Kevin_Kofler> Well, it means a copied&pasted BuildRequires: gcc-c++ in all our packages. For make, I think cmake should Require it if it doesn't already.
15:13:45 <Kevin_Kofler> And all our packages BR cmake directly or indirectly anyway (IMHO, they should BR it directly, but whatever).
15:14:08 <Kevin_Kofler> Oh sure, Requires: gcc-c++ in qt*-devel would work.
15:14:29 <Kevin_Kofler> Then at least OUR packages won't care.
15:14:41 <heliocastro> well, we could create a package that buildreq even cmake
15:14:51 <heliocastro> And we need just add this one on or build reqs
15:14:52 <rdieter> gtk-devel and friends could do the same
15:15:35 <rdieter> ok, let's get started
15:15:39 <rdieter> #topic apper/appstream
15:15:41 <Kevin_Kofler> heliocastro: We already have Requires: cmake in some -devel packages.
15:15:53 <Kevin_Kofler> Which is how some of our packages get away without BR cmake right now.
15:15:57 <rdieter> So, looks like apper's appstream support has some... fun... side effects
15:16:05 <heliocastro> Ok, let me share some thoughts on apper as well
15:16:19 <rdieter> in particular, appstream support seems to make the assumption: one app per package
15:16:32 <heliocastro> I talked with Daniel Nicoletti about it, and the whoe appstream thing
15:16:46 <heliocastro> He was not happy, he felt sideloaded by canonical when started
15:16:58 <rdieter> where "app" means something that provides a .desktop file under /usr/share/applications/
15:17:22 <rdieter> so apper displays the appstream data instead of the pkg information
15:17:41 <Kevin_Kofler> heliocastro: Our own Fedora / Red Hat folks added their own pieces of insanity to the Canonical spec though…
15:17:43 <rdieter> .bug 1180819
15:17:46 <zodbot> rdieter: Bug 1180819 kde software management tool shows incorrect package description - https://bugzilla.redhat.com/1180819
15:18:11 <rdieter> ^^ one specific example, of java-1.8.0-openjdk-devel provides a jconsole.desktop, so that description only mentions... well, jconsole
15:18:12 <Kevin_Kofler> The AppData spec comes from GNOME/RH/Fedora, and with it all the weird behavior of the AppData+.desktop→AppStream data collector.
15:18:20 <rdieter> another is packages that provide > 1 app
15:18:30 <rdieter> one problematic example there I found: kmail
15:18:48 <Kevin_Kofler> KDE would have been a trainwreck with AppStream just a few months ago.
15:19:00 <Kevin_Kofler> It's only due to the splitting craze that it works at all.
15:19:05 <rdieter> searching for kmail shows: ... wait for it... KTnef
15:19:19 <heliocastro> o.O
15:19:23 <Kevin_Kofler> The good old kde* modules wouldn't have worked at all with the Fedora AppStream implementation.
15:19:28 <tosky> so this specific java-1.8.0-openjdk-devel/jconsole.desktop issue is not Apper specific, but it hits also the GNOME software center or whatever it's called, is it correct?
15:19:50 <rdieter> tosky: gnome software (I think) *only* shows stuff that provides appdata too
15:19:52 <Kevin_Kofler> Correct, sorta…
15:20:09 <Kevin_Kofler> GNOME Software doesn't show normal -devel packages at all.
15:20:22 <Kevin_Kofler> So it's only due to jconsole that it might be shown at all, if it even is.
15:20:23 <rdieter> apper is different in that regard, showing both "Packages" and "Applications"
15:20:32 <tosky> oh, so there is another filter there, I see
15:21:01 <Kevin_Kofler> I guess it's not because it doesn't use GTK+ 2 or 3 nor Qt 4 or 5.
15:21:13 <rdieter> So, as I understand it, the best long term solution (given the current appstream design) is to modify packaging to have one "app" per package
15:21:16 <tosky> isn't it possible to show (in Apper) the package description and all the associated appdata files in a separate section?
15:21:19 <Kevin_Kofler> (Another censorship rule applied by the AppStream data collector.)
15:21:31 <rdieter> tosky: not currently (not without patching anyway)
15:21:39 <tosky> no, right, as a long term solution
15:21:45 <Kevin_Kofler> It might also get censored for not providing AppData with a screenshot.
15:22:23 <rdieter> Kevin_Kofler proposed in the short-term, to simply disable appstream support in apper, so that it displays *only* packages
15:22:34 <Kevin_Kofler> IMHO, the current Apper interface for AppStream is not useful at all.
15:22:49 <Kevin_Kofler> It just replaces the description for some packages with the one from AppStream. Whom does that help?
15:22:59 <rdieter> I find appstream useful, but there are still problematic packages where it doesn't work well
15:23:08 <tosky> so we will have the package descriptions "only" as before, oki
15:23:08 <Kevin_Kofler> There need to be separate pages for browsing packages and applications.
15:23:26 <heliocastro> rdieter: who's the fault, apper or packages ?
15:23:31 <rdieter> I agree apper's current implementation isn't ideal
15:23:40 <rdieter> heliocastro: packages
15:23:53 <rdieter> given appstream's current design assumption: one app per package
15:23:53 <Kevin_Kofler> Uh, it's not that clear-cut.
15:24:00 <Kevin_Kofler> hughsie says it's the packages' fault.
15:24:06 <Kevin_Kofler> IMHO, it's the assumptions that are broken.
15:24:14 <Kevin_Kofler> One app per package has never been the case.
15:24:31 <rdieter> except that's the design we're stuck with
15:24:38 <Kevin_Kofler> It's ridiculous to expect the whole distribution's packaging to change to accomodate such a flawed assumption.
15:24:53 <rdieter> so ignore it?
15:25:04 <rdieter> (I don't think that's a viable option to consider)
15:25:13 <Kevin_Kofler> IMHO, ignore AppStream, it's just broken.
15:25:25 <Kevin_Kofler> (i.e. disable all support for it in KDE)
15:25:32 <Kevin_Kofler> (Currently, only Apper is infected anyway.)
15:25:53 <rdieter> the 2 primary cases that look bad in apper currently:
15:26:15 <rdieter> * like openjdk case, where it provides an application, but that application is not the primary purpose/focus of the package
15:26:31 <rdieter> so apper showing *only* appdata there is misleading
15:26:47 <rdieter> * packages that provide > 1 application (like kmail)
15:27:40 <Kevin_Kofler> At least the first problem could be solved in Apper by always listing both the application and the package, though that would also mean duplicate entries for all the application packages, not sure how user-friendly that is.
15:27:47 <rdieter> so does anyone support the idea of disabling appstream support in apper?
15:28:20 <tosky> as a short term solution, with keeping an eye on other possible fixes, yes
15:28:40 <Kevin_Kofler> The second problem would need to be fixed in the AppStream generator, by generating 2 entries for the application, but then I guess apps (including probably Apper) would also need to be fixed to not assume that the package name is a valid key (in the database sense) there.
15:28:43 <rdieter> fwiw, I'm currently -1, against the idea, it makes fixing packages for appstream harder
15:28:47 <heliocastro> rdieter: Yes, as long the other solution still works
15:29:05 <rdieter> (I don't feel strongly though)
15:29:13 <Kevin_Kofler> I'm still +1 to my proposal of disabling AppStream support in Apper (in both F21 updates and Rawhide).
15:29:27 <Kevin_Kofler> It's just not ready for production use.
15:29:37 <Kevin_Kofler> And I'm not even sure whether it ever will be.
15:29:52 <rdieter> dvratil, jgrulich, pino|work : opinions/votes?
15:29:57 <Kevin_Kofler> Those flawed assumptions are not easy to fix (especially the packages with multiple .desktop files).
15:30:05 <tosky> rdieter: do you think keeping the current state even with those special case is better to not forget about fixing this in a proper way?
15:30:23 <Kevin_Kofler> And the Apper UI also needs a lot of work to handle applications nicely, which I don't think will happen any time soon either.
15:30:42 * tosky bbl, sorry
15:30:45 * pino|work got distracted by $work, reading last ~5m of backlog
15:31:18 <rdieter> tosky: I think sweeping the "problem" under the rug by disabling appstream, will mean less incentive to fix things
15:31:41 <rdieter> (and it's harder to test to identify problematic packages that way)
15:31:58 <rdieter> ^^ that's my primary concern
15:32:23 <rdieter> so far: +3/-1 (if I'm counting correctly)
15:33:02 <dvratil> hmm, I don't include to any side - I think it's a bad idea to ship something that does not work properly (been there, done that, burnt myself), on the other hand Rex is also right, as there will be less motivation to finish the implementation
15:33:07 <dvratil> incline
15:33:40 * rdieter changes mind, consider me +0
15:33:55 <ltinkl> seeing how dantti is very inactive lately, +1
15:34:00 <rdieter> so, +3/0/-0, currently (not that it makes much difference)
15:34:11 <ltinkl> in other words, there is not much hope the situation will get better
15:34:13 <Kevin_Kofler> IMHO, fixing those bugs is just a waste of time, as we would never ever reenable AppStream support.
15:34:22 <Kevin_Kofler> So just disable it and be done with it.
15:34:30 <rdieter> Kevin_Kofler: it'll help apps displaying in gnome-software
15:34:37 <heliocastro> ltinkl: Dantii is runnig two personal companies, barely has touching open source,only qt
15:34:44 <ltinkl> heliocastro: I know
15:34:56 <Kevin_Kofler> rdieter: That's something GNOME Software users should care about then. Not our problem.
15:35:02 <jgrulich> +0, I didn't pay attention enough to understand how those things work
15:35:07 <Kevin_Kofler> Especially for things like openjdk-1.8.0-devel that are NOT our packages.
15:35:21 <rdieter> Kevin_Kofler: you may not care, but I care how kde (and all) apps work in Workstation
15:36:30 <rdieter> well, consdering we already have +4 (and no one outright opposed), let's consider the proposal agreed
15:37:21 <rdieter> #agreed disable appstream support in apper
15:38:05 <rdieter> related fun to this is that investigations have identified what appear to be more missing features in PK-hif backend
15:38:32 <rdieter> including filters: show only latest versions, show only native arch
15:38:35 * heliocastro refuses to comment
15:38:38 <Kevin_Kofler> Can we have a tracking bug for them?
15:38:49 <rdieter> yes, I agree to create a tracking bug
15:38:50 <Kevin_Kofler> (As I said on #fedora-kde)
15:38:54 <pino|work> +1 on dvratil
15:39:43 <rdieter> while we're on the topic, is anyone looking into packaging muon yet?
15:39:58 <dvratil> rdieter: I can package it as part of the Plasma beta
15:40:11 <dvratil> I skipped it for now, but should be easy to add it
15:40:16 <rdieter> (it will likely suffer a lot of the same problems, due to PK-hif backend)
15:40:31 <rdieter> dvratil: great, thanks (though consider it low priority)
15:40:39 <dvratil> ok
15:40:48 <rdieter> anything else on apper/PK/related-fun ?
15:42:19 * rdieter takes that as no :)
15:43:04 <rdieter> #topic gcc in buildroot -devel thread
15:43:26 <heliocastro> So, the consequences:
15:44:08 <heliocastro> This leads to put us in our own ballparking, ignoreing exterior ?
15:44:30 <Kevin_Kofler> To sum up, script kiddies want to have the basics for compiling real software out of the default build root. :-(
15:45:00 <rdieter> Kevin_Kofler: if you could phrase your opposition without name-calling, that would be better
15:45:27 <rdieter> "script kiddies" or "real software"
15:46:13 <rdieter> I'm of the opinion that the default buildroot still serves a good purpose, and if it serves some reasonable large percentage of packages, then it's worth keeping
15:46:21 <Kevin_Kofler> OK, politically correct version: To sum up, packagers involved with scripting languages want to have the basics for compiling C/C++ software out of the default build root. :-(
15:46:34 <heliocastro> This is already become an official  proposition ?
15:46:56 <Kevin_Kofler> There seems to be a surprisingly high amount of support for it.
15:47:15 <rdieter> it's currently only being discussed, afaik
15:47:46 <heliocastro> Rephrasing: Is this have a slightly chance to become a serious proposition ?
15:47:46 <rdieter> a proposal was made to fpc to change it, but they rejected it (rightly so), this is a fesco decision
15:48:06 <Kevin_Kofler> FPC's rejection was just a jurisdictional thing though.
15:48:10 <rdieter> heliocastro: I believe fesco will be asked to consider it, yes
15:48:30 <rdieter> Kevin_Kofler: fpc would have rejected it on other grounds, if it came to that though
15:48:32 <Kevin_Kofler> They said they are not the competent body to make this decision and to ask FESCo instead.
15:48:34 <heliocastro> Ok, so we need prepare contingencies to not stop on a possible weeks meltdown
15:49:11 <rdieter> I think we (kde-sig) can mitigate things by adding Requires: gcc-c++ in Qt devel packages
15:49:28 <Kevin_Kofler> rdieter: Probably, but unfortunately, we have to assume that their declaration of non-competence also means they won't be blocking it if FESCo decides it.
15:49:38 <rdieter> (and theoretically, gtk -devel could add Requires: gcc , too)
15:49:50 <Kevin_Kofler> And Requires: make in cmake.
15:49:53 <rdieter> Kevin_Kofler: again, without the name calling please
15:50:18 <heliocastro> The logic says several people will try to rebuild packages just because someone said that it changed, and then we will expect  a huge delay queu on build systems until we could do real work
15:50:23 <Kevin_Kofler> "non-competence" as in "They're not the competent body", not "incompetence".
15:50:24 <Kevin_Kofler> :-)
15:51:03 <Kevin_Kofler> The FPC wouldn't be the body I'd accuse of the latter. ;-)
15:51:14 <rdieter> I don't see any difference?  the result is approx the same, you're labeling them as not competent
15:51:19 <heliocastro> question is, decision is not in our hands, right ?
15:51:35 <rdieter> heliocastro: correct, but we can voice our opinion in the -devel thread
15:51:50 <heliocastro> Ok, so we need prepare for the bad decision
15:52:00 <Kevin_Kofler> rdieter: http://en.wiktionary.org/wiki/competent
15:52:02 <rdieter> Kevin did so already, but weaken that position with name-calling and going too far the other way to suggeset cmake should be added... imho
15:52:05 <heliocastro> In any case, have a way to continue our work during the initial dark days
15:52:07 <Kevin_Kofler> "2. (law) Having jurisdiction or authority over a particular issue or question."
15:52:42 <rdieter> ah, so definition 2, I'd never heard that one before
15:52:46 <Kevin_Kofler> I don't claim they're not competent as in "1. Having sufficient skill, knowledge, ability, or qualifications."
15:52:51 <heliocastro> I really don't care who is, or point fingers, if is not my decision and i will need to deal with it, stop complain and lets make it work
15:53:18 <rdieter> though honestly, doesn't that make the example "judicial authority having competent jurisdiction" redundant?
15:53:39 <rdieter> whatever :) good to know
15:54:09 <rdieter> Kevin_Kofler: I still think it wise to avoid the possibility of misinterpretation by using different language
15:54:13 <Kevin_Kofler> Legal language is often somewhat redundant.
15:55:02 <rdieter> anything else to mention before moving on?
15:55:12 <rdieter> (I think we're largely in agreement)
15:55:13 <heliocastro> Nope
15:55:24 <Kevin_Kofler> So, I was saying: cmake should also get a Requires: make then.
15:55:37 <heliocastro> yes, agree. Just need a contingency plan if we foresee things go badly
15:55:38 <rdieter> Kevin_Kofler: that's reasonable
15:55:42 <Kevin_Kofler> Though strictly speaking, cmake can also generate other stuff, so I guess some users of ninja or the like might complain.
15:56:05 <rdieter> <nod>, though it's easy to argue in our context 'make' is the primary output target
15:56:10 <Kevin_Kofler> It's the usual tradeoff with dependencies.
15:56:17 <pino|work> fwiw, cmake in debian recommeds make (and recommends are enabled by default, but not on buildds) and suggests ninja
15:56:24 <rdieter> once soft dependencies are supported, we can do more, yeah
15:56:43 <rdieter> pino|work: thank
15:56:45 <rdieter> thanks
15:56:51 <pino|work> otoh make is part of the build-essential, which is installed in build roots
15:57:28 <rdieter> heh, rpm -e make hits only 2 pkgs that depend on it
15:57:36 <rdieter> redhat-lsb-core and openssl
15:58:02 <rdieter> bet it is not easy to make a fedora box without openssl currently
15:58:16 <rdieter> probably best not to rely on that though
15:58:27 <Kevin_Kofler> For CMake, I must say that I expected more packages to use it by now. It's incredible how few packages are using it. So many are still stuck on the legacy autocrap.
15:58:40 <Kevin_Kofler> (or on bizarre homegrown PITA build systems)
15:59:06 <rdieter> Kevin_Kofler: there are migrations happening, but learning new things takes time
15:59:21 <rdieter> (and folks usually get it wrong on the first or second tries)
15:59:39 <Kevin_Kofler> I should have checked before proposing it added to the minimal build root, that was probably a mistake indeed.
16:00:46 <rdieter> ok, let's move on
16:00:49 <rdieter> #topic open discussion
16:00:52 <Kevin_Kofler> There are less than 700 SRPMs that directly BR cmake in Rawhide, and even with the indirect ones, we're somewhere around 1000 I think (less than 300 SRPMs BR kdelibs4-devel, for example).
16:00:54 <rdieter> anything else for today?
16:01:19 <heliocastro> Nope from me
16:02:20 * rdieter close meeting 1 min
16:03:19 <rdieter> ok, thanks everyone
16:03:21 <rdieter> #endmeeting