15:16:25 <rdieter> #startmeeting kde-sig
15:16:25 <zodbot> Meeting started Tue Mar 17 15:16:25 2015 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:16:25 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:16:28 <rdieter> #meetingname kde-sig
15:16:28 <zodbot> The meeting name has been set to 'kde-sig'
15:16:31 <rdieter> #topic roll call
15:16:39 <rdieter> hi all, friendly kde-sig meeting, who's present today?
15:16:52 <dvratil> hi all
15:16:53 <Kevin_Kofler> Present.
15:16:56 <jgrulich> hi
15:17:02 <dvratil> and happy birthday, rdieter :)
15:17:09 <jsmith> Yeah, happy birthday Rex :-)
15:17:27 <jgrulich> I'm joining to dvratil and wish rdieter happy birthday :)
15:18:06 <rdieter> thanks everyone
15:18:14 <tosky> oh, uh, me too, happy birthday!
15:18:21 * jreznik is here
15:18:24 <rdieter> heliocastro, than: ping
15:18:40 <tosky> I bet pino|work is here too
15:18:42 <Kevin_Kofler> Happy birthday Rex!
15:18:46 <pino|work> indeed
15:18:53 * satellit listening
15:19:20 <rdieter> #info rdieter dvratil Kevin_Kofler jgrulich dvratil tosky pino|workj jreznik satellit present
15:19:33 <rdieter> #chair dvratil Kevin_Kofler jgrulich dvratil tosky pino|work jreznik satellit
15:19:33 <zodbot> Current chairs: Kevin_Kofler dvratil jgrulich jreznik pino|work rdieter satellit tosky
15:19:42 <rdieter> #topic agenda
15:19:45 <rdieter> what to discuss today?
15:20:00 <dvratil> I can give KF5 update update and KTp "5" update
15:20:47 <rdieter> alright, let's start with that
15:21:00 <rdieter> #topic kf5/ktp-5 status update
15:21:19 <dvratil> so, latest KF5 5.8.0 update is done in rawhide
15:21:26 <rdieter> woo
15:21:30 <dvratil> and builds are running for F20, F21 and F22
15:22:11 <dvratil> for KTp, the "big news" is that the Frameworks 5 version will be included in KDE Applications 15.04
15:22:43 <Kevin_Kofler> Nice.
15:22:44 <dvratil> so I started submitting the new dependencies for review - it's mostly the SSO stuff, so sigon-qt5, libaccounts-qt5, kaccounts etc.
15:23:32 <dvratil> the existing KTp packages (ktp-*) will just need version bump and new dependencies (we can probably copy those from my Copr packages)
15:23:49 <rdieter> are all those dependencies hard requirements?  or are some/all optional?
15:23:57 <dvratil> they are all hard deps
15:24:07 <rdieter> ok
15:24:16 <dvratil> they are all needed for the new accounts management
15:24:38 <dvratil> also since KPeople is now a Framework (as of KF5 5.8.0), we can retire libkpeople once 15.04 is shippe
15:24:52 <dvratil> d
15:24:56 <tosky> (kaccounts* are part of Applications 15.04 as well)
15:25:21 <dvratil> indeeed, they are also pending review
15:25:29 <dvratil> well, kaccounts-integration for now, still working on the other one :)
15:26:35 <dvratil> that's all, I guess
15:27:57 <rdieter> thanks, relatedly, reminds me of the next kf5-ported app I was going to look closer at:  okteta
15:28:27 <rdieter> (and the fact that we'll need a okteta4 compat pkg, similar to kate4, konsole4 for the kpart used in other apps like kdevelop)
15:28:51 <Kevin_Kofler> Also used in Krusader, though Krusader has a builtin fallback.
15:29:27 <rdieter> moving on...
15:29:31 <rdieter> #topic open discussion
15:29:36 <rdieter> anything else for today?
15:29:36 <dvratil> I have one more topic
15:29:38 <dvratil> :)
15:29:45 <rdieter> dvratil: ok, go ahead
15:29:48 <dvratil> sorry, forgot about it
15:30:01 <dvratil> I wrote the rpm script that add the CMake provides to packages
15:30:18 <rdieter> #topic cmake-related auto-provides
15:30:29 <dvratil> so for example qt5-qtbase-devel can Provides: cmake(Qt5Core) cmake(Qt5Gui) cmake(Qt5Widgets) etc.
15:30:32 <Kevin_Kofler> Yay!
15:30:49 <dvratil> so packages can BR: cmake(Qt5Core)  instead of qt5-qtbase-devel
15:30:57 <dvratil> now the question is: where do we want to put it?
15:31:05 <dvratil> the script, I mean
15:31:22 <rdieter> dvratil: initially, I'd say see if we can get it included in cmake pkg probably.  long-term, rpm itself
15:31:37 <heliocastro> Agreed
15:31:45 <dvratil> but Qt does not depend on CMake, does it?
15:31:55 * rdieter checks
15:31:59 <heliocastro> I don't think rpm needed. Only cmake is enough
15:32:23 <rdieter> dvratil: qtbase BuildRequires: cmake at least
15:32:30 <dvratil> ah, awesome then
15:32:41 <rdieter> dvratil: does the script need cmake to be present for it to work?
15:32:53 <dvratil> no
15:33:05 <dvratil> just python ;)
15:33:16 <rdieter> of course, if cmake (and the script) isn't in the buildroot , then the auto provides won't happen either :)
15:33:50 <dvratil> the script: https://paste.kde.org/p1rb3da8d
15:34:14 * Kevin_Kofler wonders how many packages install .cmake files without BRing cmake (or anything that Requires cmake).
15:34:38 <Kevin_Kofler> Of course, we could also put it in a cmake-rpm-macros subpackage and have cmake Require cmake-rpm-macros.
15:34:46 <Kevin_Kofler> Then you could also BR only cmake-rpm-macros.
15:34:56 <Kevin_Kofler> But I'm not sure such micromanagement is really necessary.
15:35:01 <rdieter> Kevin_Kofler: good question, I'd guess none (or a small number at most)
15:35:01 <Kevin_Kofler> cmake doesn't have all that many dependencies.
15:35:28 <rdieter> we'll find out :)
15:36:07 <dvratil> who's cmake maintainer in Fedora
15:36:08 <rdieter> dvratil: thanks for working on that
15:36:25 <dvratil> np, can't wait to use it in Frameworks :)
15:36:25 <rdieter> dvratil: orion is primary I think, I'm a comaintainer
15:36:34 <rdieter> .whoowns cmake
15:36:36 <zodbot> rdieter: orion
15:36:57 <dvratil> ok, I'll send him mail with the script and CC you
15:36:58 <rdieter> dvratil: can you file a bug about it?
15:37:03 <dvratil> right, even better
15:37:07 <dvratil> :)
15:37:12 <rdieter> transparency++
15:37:24 <dvratil> yep
15:37:24 <rdieter> thanks
15:37:28 <dvratil> ok, will do afte the meeting
15:37:52 <rdieter> anything else on cmake provides?
15:38:04 <dvratil> nothing from me
15:38:19 <rdieter> k, I have one too :)
15:38:22 <rdieter> #topic muon
15:38:42 <rdieter> so somebody helpfully made a muon copr, and I tried it out
15:39:04 <rdieter> it I think it's pretty nice.  so cleaned it up a bit, and submitted it for pkg review
15:39:09 <Kevin_Kofler> I see there's only muon-discover and muon-updater, no traditional package manager? :-(
15:39:17 <rdieter> .bug 1202591
15:39:20 <zodbot> rdieter: Bug 1202591 Review Request: muon - A collection of package management tools for KDE - https://bugzilla.redhat.com/1202591
15:39:29 <rdieter> muon-discover can be traditional...ish
15:39:41 <rdieter> there's a toggle for "enable technical packages"
15:39:52 <rdieter> then it shows everything
15:40:20 <Kevin_Kofler> With the same kind of problems as AppStream-enabled Apper?
15:40:23 <rdieter> but I'm mostly interested in muon-updater (since we still lacked any native update tool)
15:40:45 <rdieter> Kevin_Kofler: good question, I've only looked at it for ~20-30 minutes so far
15:41:16 <Kevin_Kofler> I think muon-updater is the way to go, I don't see the Plasma 5 port of the Apper plasmoid being ready any time soon (it's been vaporware for months now).
15:41:22 <rdieter> like I said, I'm mostly interested in muon-updater, having  muon-discover is a bonus
15:41:38 <Kevin_Kofler> And going back to an old pre-plasmoid Apper updater also doesn't look that great (and would also lock us into kdelibs4).
15:41:41 <jgrulich> if you are looking for an applet for updates, ltinkl (with little support of me) wrote this one https://github.com/caybro/plasma-pk-updates
15:41:50 <jgrulich> it works pretty well
15:42:19 <rdieter> jgrulich: ok, can you or ltinkl work on packaging it for review?
15:42:24 <Kevin_Kofler> jgrulich: Is that ready to be shipped in F22 now?
15:42:34 <rdieter> having more options would be nice
15:42:40 <jgrulich> rdieter: Kevin_Kofler: yes and I would say yes
15:43:06 <Kevin_Kofler> So you think we should use that by default for F22? Then we need to get it in ASAP.
15:43:41 <rdieter> depends on testing results and feedback, I think it's premature to make any decisions yet
15:44:04 <rdieter> but getting both in asap would be a "good thing(tm)"
15:44:13 <jgrulich> I've told to ltinkl to publish it so it gets more attention
15:44:37 <Kevin_Kofler> Time is running short, and we can't really ship F22 without a working GUI updater.
15:44:49 <Kevin_Kofler> Isn't it even a Beta criterion that the GUI updater needs to work?
15:45:03 <Kevin_Kofler> Alpha gets away with command-line-only, which is why F22 Alpha was shippable as is.
15:45:23 <rdieter> <nod>
15:45:44 <jgrulich> http://www.imagehosting.cz/?v=updatejuj.png
15:45:57 <Kevin_Kofler> The directory structure is fun, with "declarative" containing imperative code, while all the declarative QML code is under "plasma". :-)
15:46:13 <rdieter> fyi, the aforementioned copr, https://copr.fedoraproject.org/coprs/scorpionit/Muon/
15:46:18 <Kevin_Kofler> I know what it's intended to mean ("declarative" = plugins for QtDeclarative), but it's still funny.
15:46:38 * satellit yumex? used in some lives
15:46:51 <jgrulich> I can try to package it tomorrow and submit it for review
15:46:58 <rdieter> satellit: a last resort, yes
15:47:39 <Kevin_Kofler> That doesn't have an updater applet.
15:47:42 <Kevin_Kofler> You have to run it manually.
15:47:45 <Kevin_Kofler> So it's crap UI.
15:47:46 <rdieter> that all said, should we keep apper around, or retire it?
15:48:07 <Kevin_Kofler> rdieter: Keep Apper, drop the plasmoid that doesn't work anymore from packaging.
15:48:18 <rdieter> ok
15:48:24 * rdieter is torn
15:48:28 <Kevin_Kofler> And maybe add Requires: plasma-pk-updates for upgrade path.
15:49:08 <rdieter> any other comments on muon (and friends)?
15:49:36 <Kevin_Kofler> And we can decide whether to ship Apper or Muon Discover (or both) on the spin. But we should have them both in the repo.
15:50:26 <rdieter> fwiw, muon doesn't seem to have any configuration for when/how to check for updates as far as I can tell
15:50:45 <Kevin_Kofler> By the way, the PackageKit-hif comps patch might FINALLY get merged soon. I took over the pull request and am trying to finally get it past hughsie.
15:50:59 <rdieter> except for button "check now" , which didn't work.  arguably, that's still a PK bug, since 'pkcon update' said no updates too
15:51:08 <rdieter> at least until I did:  pkcon refresh force
15:51:22 <Kevin_Kofler> That's probably the same bug we have in Bugzilla for Apper on F21.
15:51:31 <rdieter> yes
15:51:50 <rdieter> symptoms are the same at least
15:51:54 <Kevin_Kofler> I also hit that yesterday doing a fresh install of F21 KDE (on a MacBook).
15:52:13 <Kevin_Kofler> I'll have to remember the "pkcon refresh force" workaround.
15:52:24 <Kevin_Kofler> (I ended up just using command-line yum instead.)
15:52:33 <rdieter> try just 'pkcon refresh' first
15:52:57 <rdieter> moving on...
15:53:02 <rdieter> #topic open discussion
15:53:05 <rdieter> anything else for today?
15:53:27 <satellit> initial setup in f22?
15:53:41 <rdieter> satellit: what about it?
15:54:18 <satellit> get text based sometimes and graphical on other installs with root but no user
15:54:41 <rdieter> so initial setup isn't running properly?
15:54:53 <jgrulich> rdieter: what about NetworkManager-config-connectivity-fedora? I would include it in our spin
15:55:02 <satellit> works but text is disconcerting
15:55:05 <rdieter> jgrulich: <nod>, I asked onlist about that this morning
15:55:21 <jgrulich> rdieter: I know, I'm answering here
15:55:28 <rdieter> jgrulich: ok, I'll add it
15:55:30 <Kevin_Kofler> satellit: Issues with broken oxygen-gtk3? That should be fixed now (Adwaita always used).
15:55:36 <rdieter> satellit: disconcerting how?
15:55:38 <satellit> k
15:55:45 <rdieter> or just looks funny?
15:55:49 <Kevin_Kofler> There may be other issues we don't know about yet though.
15:56:03 <satellit> not expected in graphical install to drop to text based I-S
15:56:08 <Kevin_Kofler> jgrulich: -1 to NetworkManager-phone-home!
15:56:21 <jgrulich> rdieter: if we won't include it I would say that users would never figure out that it's possible to check for connectivity by installing this package
15:56:30 <rdieter> Kevin_Kofler: remember, this is about sane defaults for most users, not particularly what *you* want. :)
15:56:43 <Kevin_Kofler> And also our updaters phone home, too. :-)
15:56:50 <rdieter> jgrulich: I agree, it's not in comps currently
15:56:53 <Kevin_Kofler> So I guess we don't have to be that paranoid.
15:57:23 <Kevin_Kofler> But technically, it is a "phone home" feature, it pings Fedora servers each time you connect to a network to check whether the Internet is reachable from that network.
15:57:36 <Kevin_Kofler> I can also see that causing more problems than it solves in some setups.
15:57:41 <Kevin_Kofler> Train WiFi, for example.
15:57:53 <Kevin_Kofler> You have a steady LAN and an intermittent WAN.
15:57:53 <rdieter> the problem being?
15:58:17 <Kevin_Kofler> If that now checks for Internet availability during a service interruption, it will conclude that the network is local-only.
15:58:18 <rdieter> it tells you when your internet connectivity is working (or not).  nothing more, nothing less
15:58:39 <Kevin_Kofler> Then you get back into an area with mobile broadband reception, so the uplink from the train LAN is working again, and NM won't notice.
15:58:52 <rdieter> NM will reping, and then notice
15:59:00 <jgrulich> Kevin_Kofler: there is an interval when it should re-check it again
15:59:00 <Kevin_Kofler> (and still claim you're not on the Internet, which in turn may lead apps such as Konversation to stay disconnected)
15:59:13 <Kevin_Kofler> jgrulich: Just in time to be in the next tunnel. ^^
15:59:26 <Kevin_Kofler> I think this really WILL hurt this use case.
15:59:32 <rdieter> if you have a connection going up and down in the span of minutes, you have bigger problems, imo
15:59:52 <Kevin_Kofler> This is the normal way things work in WiFi-enabled trains in Austria.
15:59:59 <Kevin_Kofler> And they go up and down within seconds, not minutes.
16:00:08 <rdieter> jgrulich: is this just about the nm icon, or does NM report being disconnected too
16:00:09 <rdieter> ?
16:00:11 <Kevin_Kofler> The LAN stays up, mind you, but uplink is intermittent.
16:00:16 <jgrulich> rdieter: just icon
16:00:28 <rdieter> ok, so Kevin_Kofler's case of konversation not connecting is invalid
16:00:36 <Kevin_Kofler> jgrulich: Uh, there is some flag set in NM that apps can check.
16:00:46 <Kevin_Kofler> The applet gets the info from somewhere, too.
16:00:55 <Kevin_Kofler> Now what the apps will do depends on the apps.
16:01:00 <jgrulich> Kevin_Kofler: there is a connectivity property
16:01:09 <Kevin_Kofler> It may well be that Solid/KDE/Konversation ignores it entirely.
16:01:43 <jgrulich> https://developer.gnome.org/NetworkManager/0.9/spec.html#type-NM_CONNECTIVITY
16:02:29 <jgrulich> without NM-config-connectivity-fedora it would recognize only NONE and FULL connectivity
16:02:52 <jgrulich> with ^^ it actually knows whether you are able to reach the full internet or not
16:03:05 <rdieter> running short on time, any final thoughts?
16:03:53 <Kevin_Kofler> How do they detect PORTAL?
16:04:59 <jgrulich> Kevin_Kofler: captive portal would probably return something else that NM expects
16:05:20 <Kevin_Kofler> This new accounts stuff also suffers from splitomania, there are already 6 packages for review. :-(
16:05:58 * Kevin_Kofler misses the time where we had kdenetwork that contained the whole Kopete and a bunch of other stuff.
16:06:11 <Kevin_Kofler> Now we have 6+ packages for one single feature of KTP.
16:06:41 <jgrulich> Kevin_Kofler: NM tries to get https://fedoraproject.org/static/hotspot.txt and compare the text there, if it would be a captive portal it would return something else
16:07:08 <jgrulich> Kevin_Kofler: and in case of limited connectivity it would not able to even retrieve that file
16:08:04 <jgrulich> just guessing, I'm not sure how it works
16:08:24 <Kevin_Kofler> So to sum up the connectivity-fedora stuff:
16:08:44 <tosky> I wonder how android does the captive portal detection - maybe another special page? But that's OT
16:08:58 <jgrulich> tosky: I would say it would be similar
16:08:59 <Kevin_Kofler> + it allows giving the user (and maybe some apps) to give accurate feedback on whether we have a working Internet connection (as opposed to an island LAN)
16:09:09 <Kevin_Kofler> - it phones home (each time you connect to a network)
16:09:41 <Kevin_Kofler> - the status may be inaccurate for networks with intermittent uplink (e.g. train WiFi)
16:09:49 <jgrulich> Kevin_Kofler: I don't think other apps are using it, it's new in networkmanager-qt and solid doesn't have connectivity property implemented
16:10:33 <Kevin_Kofler> Well, there are also applications outside of the KDE universe. ;-)
16:11:31 <Kevin_Kofler> The thing is, if apps indeed don't use it, then what is it good for?
16:11:46 <jgrulich> plasma-nm uses it
16:12:08 <rdieter> for the systray icon, which is where we started :)
16:12:32 <Kevin_Kofler> But does that alone justify pinging Fedora servers at every connection?
16:13:03 <Kevin_Kofler> Oh, also, if fedoraproject.org goes down, the thing will think you have no Internet.
16:13:30 <rdieter> it's just advisory
16:13:38 <Kevin_Kofler> "What other servers? You mean the Internet is more than fedoraproject.org?" ^^
16:13:40 <rsc> Does Fedora run an anycast network? If not, it does not make sense to ping a Fedora server for Internet connection tests.
16:14:48 <nirik> we have 10 servers that are 'fedoraproject.org' in 10 datacenters around the world.
16:15:46 <rsc> Yes, but will the tool ping all of them if one is down? How about dual-stacking (IPv4 vs. IPv6). What if one or multiple locations suffer routing issues? Pinging multiple server takes more time. What if DNS resolving does not work? Hardcoding of IPv4 and IPv6 addresses?
16:16:31 <rdieter> looks like there's a related discussion going on in #fedora-devel too at the moment, I'd suggest continuing there
16:16:40 <nirik> they are in dns by geoip region, they have both ipv4 and ipv6, if dns resolving or network issues happen it will think you are not online. it doesn't hardcode.
16:19:45 <rdieter> let's wrap the meeting then, so we don't get lost in an offtopic forest full of trees.
16:19:48 <rdieter> thanks everyone!
16:19:50 <rdieter> #endmeeting