15:08:17 <rdieter> #startmeeting kde-sig
15:08:18 <zodbot> Meeting started Tue Aug  4 15:08:17 2015 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:08:18 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:08:21 <rdieter> #meetingname kde-sig
15:08:21 <zodbot> The meeting name has been set to 'kde-sig'
15:08:29 <rdieter> #topic roll call
15:08:38 <rdieter> hi all, friendly kde-sig meeting, who's present today?
15:09:07 <Kevin_Kofler> Present.
15:09:47 <tosky> here
15:09:48 <dvratil> hi
15:10:00 * dvratil finally made it after many weeks :)
15:10:30 <rdieter> #info rdieter Kevin_Kofler tosky dvratil present
15:10:36 <rdieter> #chair Kevin_Kofler tosky dvratil
15:10:36 <zodbot> Current chairs: Kevin_Kofler dvratil rdieter tosky
15:11:34 * jreznik_ is here but emergency with our dog, so I'd have to leave pretty soon
15:11:47 <tosky> pino|work: here?
15:11:52 <rdieter> :(
15:11:54 <pino|work> o/
15:12:09 <rdieter> #info pino|work present
15:12:11 <rdieter> #chair pino|work
15:12:11 <zodbot> Current chairs: Kevin_Kofler dvratil pino|work rdieter tosky
15:12:14 <pino|work> downsides of having 10 virtual desktops xD
15:12:20 <rdieter> #topic agenda
15:12:34 <rdieter> ok, any agenda topics folks are interested in?
15:12:40 <mustafam> New Here :) Mustafa
15:13:03 * rdieter throws out: akademy reports, f23/f24 changes/proposals (e.g. browsers)
15:13:16 <rdieter> #info mustafam present
15:13:18 <rdieter> hi
15:14:15 <Kevin_Kofler> Not the browser thing again… :-/
15:14:52 <rdieter> I said I'd bring it up from the ml thread
15:14:56 <jreznik> proposal - do not ship any browser by default, show ballot screen :)
15:15:09 <rdieter> lulz
15:15:28 <Kevin_Kofler> Uh, doing it as M$ does it, we'd ship Konqueror and show a ballot screen where you can select to replace it with another browser.
15:15:52 <rdieter> please, hold discussion for later... sounds like there's no other agenda topics, so let's start with fun: akademy reports
15:15:56 <rdieter> #topic akademy reports
15:15:58 <mustafam> I thought rdieter inveted us, maybe I invited myself :)
15:16:25 <rdieter> mustafam: all are welcome
15:16:32 <mustafam> thnx
15:16:37 <dvratil> Akademy was awesome \o/
15:16:50 <dvratil> I guess the biggest thing was Bluesystems introducing the Plasma Mobile thing
15:16:51 * rdieter sucks for not making it to akademy *again*
15:16:53 <Kevin_Kofler> rdieter: Even mailing list trolls who keep repeating the same complaints and can't take a "no"?
15:17:05 <dvratil> it looks really cool, but it is still a very early alpha preview
15:17:06 <rdieter> Kevin_Kofler: it could be argued you're doing the same thing (repeating)
15:17:19 <dvratil> (nothing better than DrKonqi popping up on a phone screen)
15:17:36 <Kevin_Kofler> dvratil: LOL :-)
15:17:45 <dvratil> I was asked by sebas to package plasma-mobile for Fedora, but I heard from jreznik someone already did that (??)
15:17:50 * jreznik bricked his ubuntu phone while trying to hack plasma on top of it
15:17:56 <tosky> for "small applications growing", gcompris got a lot of attention (and voices recorded)
15:18:04 <rdieter> I know there's a really old plasma-mobile pkg
15:18:06 <Kevin_Kofler> We have plasma-mobile packaged, but it's the old Plasma 4 version.
15:18:10 <rdieter> (kde4 based)
15:18:18 <Kevin_Kofler> (the "Plasma Active" one, not the new Plasma-5-based "Plasma Phone" one)
15:18:22 <jreznik> dvratil: no, I said with current frameworks version, it's not possible (kwayland) but we had plasma-active packaged
15:18:34 <dvratil> jreznik:  ah! sorry
15:18:56 <jreznik> Kevin_Kofler: actually, there's some development happening too and it's already ported to frameworks
15:19:12 <rdieter> sounds fun though, I'd love to help anyone interested in working to package/polish this stuff for fedora
15:19:30 <Kevin_Kofler> OK, so there are 2 things calling themselves "Plasma Mobile" now, one that's also called "Plasma Active" and one that's also called "Plasma Phone"? What a mess!
15:19:39 <jreznik> Kevin_Kofler: yep
15:19:48 <Kevin_Kofler> Package naming is going to be fun.
15:19:56 <Kevin_Kofler> I think both are using plasma-mobile naming.
15:20:16 <rdieter> nod (fun), step 1:  get those 2 to agree on unique naming
15:20:29 <jreznik> and in the end it should not matter - you will have all installed and your plasma will behave based on what form factor your convertible laptop is :)
15:21:02 <jreznik> rdieter: as I said - eventually it will end as the same thing, just maybe plasma shell subpackage
15:21:19 <Kevin_Kofler> I suppose the difference from the Plasma shell point of view is being optimized for a different screen size range?
15:21:20 <jreznik> (that's what makes sense)
15:21:31 <jreznik> Kevin_Kofler: yep
15:21:44 <Kevin_Kofler> Because things like whether to ship a dialer application is really application territory.
15:21:51 <tosky> about things that could be interesting, not part of the official talks (just in bof), phabricator seems to have got quite a lot of interest; others team will test it, so expect to find some stuff there
15:21:57 <jreznik> Kevin_Kofler: again, yep
15:22:14 * rdieter googles phabricator
15:22:25 <Kevin_Kofler> (It makes sense to have a dialer on a phone, or on a tablet that can pretend to be a phone (GSM, some reasonable sound I/O), not on a WiFi-only tablet. :-) )
15:22:28 <tosky> also, there is a gsoc project to implement a OCS-compatible server
15:22:45 <tosky> and they are progressing well (there was also a blog on planetkde)
15:23:22 <rdieter> nice infrastructure stuff... I do recall ocs currently is a bit of a sore-point, not being open or managed by kde.org folks (right?)
15:24:15 <tosky> yes, exactly, let's say that there are many non-technical issues
15:24:37 <Kevin_Kofler> Yes, it's an open standard, but the (so far only) server-side implementation is proprietary and hosted by one person / company (who happen(s) to be involved with KDE, but still decided against opening the server source, against initial promises).
15:24:49 <Kevin_Kofler> (it = OCS)
15:24:59 <rdieter> <nod>, we don't need to get into the gory details
15:25:03 <Kevin_Kofler> So it's great to have a Free implementation now.
15:25:20 <Kevin_Kofler> Hopefully there'll be also an instance hosted on KDE infrastructure.
15:26:05 <rdieter> anything else akademy-related to report?
15:26:42 <dvratil> from what I attended: we did a huge amount of work on KDE PIM 15.08 (yay!) and jgrulich had Solid BoF with lamarque and is now the plasma-nm maintainer
15:26:50 <tosky> there is a blog post from jgrulich with his report
15:27:04 <tosky> also dvratil showed sandboxed applications
15:27:10 <tosky> and a lot of hacking around
15:27:12 * rdieter watches the sandbox video
15:27:16 <rdieter> er, watched
15:27:49 <rdieter> moving on ...
15:28:06 <rdieter> #topic f23 (and f24) change/spin proposals
15:28:48 <Kevin_Kofler> dvratil: KDE PIM 15.08 with no KNode (and also no Akregator?). :-(
15:28:54 <rdieter> ok, let's get the unfun one out of the way, I want to take a quick poll/vote to see if there's enough support to consider changing default browsers (no discussion please)
15:29:04 <Kevin_Kofler> dvratil: This is going to be a big problem.
15:29:20 <Kevin_Kofler> We'll end up having to ship 2 kdepim stacks.
15:29:22 <Kevin_Kofler> Grrr!
15:29:26 <dvratil> Kevin_Kofler: Akregator will make it to the release
15:29:39 <Kevin_Kofler> OK, so that leaves KNode.
15:29:46 <Kevin_Kofler> How am I supposed to read Gmane without KNode?
15:29:50 <dvratil> KNode is dead (but there was a proposal for simple nntp resource that would work with KMail)
15:30:07 * rdieter mumbles that we can continue to ship a kdepim4 for any non-ported apps
15:30:15 <rdieter> including knode
15:30:24 <dvratil> rdieter:  not really. You can only ship non-Akonadi apps from kdepimlibs4
15:30:26 <Kevin_Kofler> Are you volunteering? It's going to be a PITA to package.
15:30:40 <Kevin_Kofler> dvratil: There's the kdepim-noakonadi fork.
15:30:59 <rdieter> dvratil: true, does knode not count as non-akonadi ?
15:31:09 <Kevin_Kofler> But it's going to be a PITA to get working.
15:31:11 <dvratil> rdieter:  so KNode yes, KJots for instance not
15:31:25 <Kevin_Kofler> I looked into an ldd of KNode, it drags in the world including akonadi.
15:31:33 <Kevin_Kofler> (the current F21 KNode)
15:31:41 <rdieter> oh :(  yeah, looks like it links akonadi-contact.so
15:31:57 <dvratil> that should be indirect
15:32:01 <dvratil> could probably be cut-off
15:32:04 <Kevin_Kofler> It sure is.
15:32:15 <rdieter> k
15:32:30 <Kevin_Kofler> As I said, I think we'll need to revert kdepim4 to kdepim-noakonadi, and probably also fork (or simply revert to an old version) kdepimlibs, to get this working.
15:32:40 <rdieter> knode/akregator (like Kevin_Kofler) are what I was interested in personally
15:32:57 * rdieter doesn't care about any of the akonadi stuff
15:33:06 <tosky> akregator will be in the release, so it's just knode
15:33:22 <dvratil> consensus of the PIM team is that KNode can be brought back is mantainer steps up and is willing to port it to Akonadi (eventually)
15:33:23 <Kevin_Kofler> So we'll have to figure out how to get a decent knode package.
15:33:29 <rdieter> just mentioning it, I'll be happy as long as it's shipped/available *somewhere*
15:33:30 <dvratil> s/is/if/
15:34:10 <dvratil> but let's move on, this is offtopic
15:34:12 <tosky> dvratil: why don't you blog about the nntp resource proposal and try to find a guinea pi... volunteer for that?
15:34:13 <Kevin_Kofler> KJots, I'm personally OK with just letting it die (I don't use it), though it should be possible to ship an ancient pre-Akonadi version in principle.
15:34:49 <Kevin_Kofler> I also don't understand why KNode actually HAS to migrate to Akonadi.
15:34:51 <rdieter> ok, the unfun part of the meeting....
15:34:53 <Kevin_Kofler> It just works right now.
15:34:55 <rdieter> proposal: f23 to consider change default browser shipped in plasma spin.
15:35:03 <Kevin_Kofler> It'd just become slower and more memory-hungry, like KMail.
15:35:14 <rdieter> no discussion (we've already had plenty), just vote please.
15:35:17 <Kevin_Kofler> rdieter: -1
15:35:51 <Kevin_Kofler> The only thing that changed since last time is that Firefox made an additional unfriendly move: it forbids (!) installing unsigned extensions.
15:35:51 <tosky> so +1 is to consider a change?
15:35:53 <rdieter> a -1 vote implicitly means sticking with konqueror
15:36:03 <rdieter> +1 means consider changing to something else
15:37:21 <rdieter> we dont' have a quorum here, but if there's little support, we can probably drop the topic without taking it onlist for more vote/feedback
15:37:35 <tosky> so +1
15:38:16 <Kevin_Kofler> drop the topic → +1 :-) (and of course my -1 for the proposal stands)
15:38:45 <rdieter> dvratil, pino|work : ?
15:38:45 <dvratil> -1 from me (/me personally believes we should go for Firefox with Konqueror as a fallback (for many reasons), but that would again lead to a useless flamewar and no decision at the end
15:39:07 <dvratil> and /me prefers to avoid this kind of discussions
15:39:58 <rdieter> <nod> konq is small, so could be mostly harmless to continue to include it, even if it's not the default
15:40:00 <mustafam> dvratil: So you will not vote for your preference to avoid a flame war?
15:40:11 <rdieter> sounds like it,
15:40:42 <dvratil> mustafam:  I'm avoiding wasting our time on something that we can hardly ever make consensus about (we've been through this before)
15:40:43 <pino|work> rdieter: yes? (sorry, got a phone call)
15:40:46 * rdieter is +1
15:40:48 <mustafam> With whom? You are the KDE SIG, I am not so  can't vote
15:41:11 <rdieter> pino|work: what's your opinion on proposal: f23 to consider change default browser shipped in plasma spin.
15:41:19 <pino|work> rdieter: yes please
15:42:01 <rdieter> ok, I count +3/-2 , so probably worth pursuing further (onlist), to get feedback from other kde-sig'ers not present here
15:42:24 <rdieter> other ideas I had...
15:42:50 <rdieter> #info proposal currently at +3/-2, will pursue further feedback onlist from kde-sig members
15:43:12 <Kevin_Kofler> I'm also not happy with the "consider changing to another browser" wording, with no concrete proposal as to what that browser would be. That's either a ground for another flamewar, or you're implying Firefox by the backdoor.
15:43:14 <rdieter> proposal: disable kwallet migration (by default)
15:43:26 <Kevin_Kofler> rdieter: -1
15:43:33 <Kevin_Kofler> Migration is essential for upgrades.
15:43:36 <rdieter> Kevin_Kofler: once we decide to change, I will propose firefox as the replacement , yes
15:44:07 <rdieter> Kevin_Kofler: If I were to come up with a way to enable migration *only* for upgrades, would that satisfy you?
15:44:10 <Kevin_Kofler> The migration running on new accounts is a bug. That needs to be fixed.
15:44:19 <Kevin_Kofler> Just disabling it for everyone is broken.
15:44:20 <rdieter> right, that's the case I want fixed basically
15:44:27 * dvratil agrees with Kevin_Kofler
15:44:31 <Kevin_Kofler> Yes, that part I agree with, of course.
15:44:41 <Kevin_Kofler> But disabling the migration entirely is a bad solution.
15:44:43 <rdieter> the migration has led to at least several confused mailing list dicussions already
15:44:51 <tosky_> (sorry, technical issue)
15:44:55 <rdieter> imho, it's way more trouble than it's worth in the current incarnation
15:45:17 <rdieter> I strongly believe migration as-is, causes more harm than good
15:45:45 <rdieter> at my site, I've yet to see a single user not confused by that process
15:46:14 <rdieter> (in short, I'm going to disable it at my site regardless due to that, but would rather not have to do that, and implement in fedora for everyone)
15:46:20 <Kevin_Kofler> I think we'd get even more user complaints about "losing" all their passwords.
15:47:00 <dvratil> I think this will be more or less solved with Applications 15.08 - when KDE PIM goes for KWalelt5 there won't be much other users of KWallet4 letft...
15:47:14 <Kevin_Kofler> If they already don't understand the current process, how can you expect them to know how to run the migration manually?
15:47:34 <Kevin_Kofler> dvratil: Is Konqueror also going to be ported? It's the main user of KWallet4 for me.
15:47:45 <rdieter> I don't think anything in kwallet (prior to kdepim) was worth migrating
15:47:56 <dvratil> hmm, Konqueror is probably still KDe4
15:48:08 <rdieter> wifi secrets are easily re-entered (after upgrade)
15:48:09 <mustafam> I think it is possible to disable in the LiveDVD, so we don't affect upgrades
15:48:10 <tosky> okular too
15:48:25 <tosky> konqueror is in kde-baseapps, which is still kdelibs4
15:48:46 <rdieter> mustafam: good question (about live image), but I think no wallet exists on initial login, so => no migration
15:48:48 <Kevin_Kofler> rdieter: I have a lot of Konqueror passwords in it, but of course, Konqueror is still KDE 4, so migrating now is actually bad, because nothing is going to migrate the new stuff Konqueror still adds to the old wallet, ewww…
15:48:57 <Kevin_Kofler> (which is why I think the upstream setup with the 2 wallets is broken)
15:49:06 <rdieter> migrating doesn't delete kwallet4 existing content, so why is that bad?
15:49:16 <rdieter> it only copies stuff (not moves)
15:49:25 <Kevin_Kofler> Because Konqueror is still KDE 4 and so will add NEW passwords to the OLD wallet.
15:49:41 <Kevin_Kofler> So then I'd have to delete the KWallet5 and rerun the migration when Konqueror actually gets ported.
15:49:41 <rdieter> both wallets are still supportd, and kde4 apps will still use kwallet4
15:49:47 <rdieter> so ha, the topic even confuses Kevin_Kofler
15:49:57 <Kevin_Kofler> No, you don't understand the problem.
15:50:03 <Kevin_Kofler> At time t, the migration runs.
15:50:10 <Kevin_Kofler> At time t'>t, Konqueror gets ported.
15:50:23 <Kevin_Kofler> What happens to all the passwords Konqueror writes between t and t'?
15:50:28 <rdieter> right, I would argue kf5 ported apps should be migrating their own secrets as needed
15:50:29 <Kevin_Kofler> What is going to migrate them?
15:50:47 <rdieter> migrating stuff once ... is wierd/silly/confusing
15:51:03 <rdieter> but, seems like I'm the only one that thinks that, so let's move on
15:51:05 <Kevin_Kofler> The only reasonable solution would be to patch libkwallet4 to use the new wallet.
15:51:12 <pino|work> rdieter: indeed (things migrating stuff they need/want)
15:51:19 <mustafam> If both kwallet4 and kwallet5 exist, they must synchronize, I don't know if this is possible
15:51:33 <rdieter> I wouldn't mind Kevin_Kofler's suggestion of a single/unified wallet either
15:51:41 <rdieter> but that doesn't currently exist
15:51:58 <Kevin_Kofler> mustafam: I THINK it just needs a global search&replace of the D-Bus service name. BUT, I haven't compared the interfaces. So there may or may not be more changes needed.
15:52:21 <Kevin_Kofler> And the migrator may also need special care, depending on how it does the migration.
15:53:33 <rdieter> lastly: proposal: simplify/sanitize baloo-file configuration.  includes: index stuff in document-centric folders only (e.g. ~/Documents, ~/Photos, ~/Videos ~/Music), consider porting kcm-balooadv
15:53:52 <Kevin_Kofler> And also, if KWallet5 should ever change its interface, we'd have to backport the client lib changes.
15:54:25 <Kevin_Kofler> rdieter: +1 as it's better than the status quo.
15:54:46 <Kevin_Kofler> But my personal preference (and counterproposal) would be to disable the file indexer by default entirely.
15:54:58 <rdieter> Kevin_Kofler: that's a possibility too
15:55:02 <Kevin_Kofler> (That's what I'm going to set up for me anyway.)
15:55:07 <rdieter> and easier to implement :)
15:55:14 <tosky> document-centric folder would be good, I guess
15:55:50 <rdieter> I *think* I got baloo upstream to agree to that idea in pricipal awhile back, but looks like no one ever implemented it... so while I'm at it, I'll make efforts to upstream that part
15:58:56 <rdieter> ok, seems no objections at least :)
15:59:01 <rdieter> #topic open discussion
15:59:04 <rdieter> anything else for today?
15:59:13 * danofsatx finally showed up
15:59:33 <mustafam> Muon Discover is a nice Software Center (something like Gnome Software) that uses AppSteam, I don't think removing Apper is good, but what about adding Muon?
16:02:17 * heliocastro arrived late ( doctor apointment )
16:02:35 <rdieter> mustafam: apper is (still) largely broken, you still think it worth shipping it?
16:03:05 <mustafam> rdieter: For searching packages not yet have AppData
16:03:24 <mustafam> And any other non-GUI package
16:03:25 <rdieter> since we have some late arrivals, care to chime in on our recent vote/proposal?
16:03:40 <rdieter> proposal: f23 to consider change default browser shipped in plasma spin
16:03:51 <rdieter> danofsatx, heliocastro: ^^, vote is currently at +3/-2
16:04:15 <heliocastro> +1
16:04:21 <heliocastro> I'm fine to be firefox
16:04:31 <heliocastro> konq or anything else is hurting us
16:04:58 <Kevin_Kofler> The proposal didn't even say that the replacement would be Firefox.
16:05:43 <rdieter> we'll consider that separately (though we could have done it all-at-once)
16:05:47 <rdieter> danofsatx: ?
16:05:48 <Kevin_Kofler> And please see the mailing list discussion about why Firefox would hurt us most.
16:07:03 * rdieter wonders if we lost danofsatx
16:07:13 <mustafam> And the same thread for why Konq should be replaced
16:07:15 <danofsatx> Sorry, still clearing paperwork
16:07:29 <rdieter> danofsatx: if you don't have time to consider/vote now, we can do it after meeting?
16:07:53 <danofsatx> Unfortunately, Konquerer and reKonq do not support the primary plugins I use, mainly ad blockers and lastpass.
16:08:06 <Kevin_Kofler> mustafam: We can discuss replacing Konqueror if and when there is an alternative KDE browser (that isn't at least as dead, as Rekonq unfortunately is).
16:08:09 <danofsatx> So, I'd be ok with using FF as the default. But I don't really want to.
16:08:18 <Kevin_Kofler> Right now, there is just no reasonable alternative to Konqueror.
16:08:30 <rdieter> danofsatx: +1 or -1 :)
16:08:59 <danofsatx> a very reluctant +1...it's an added step most folks do immediately after install anyhow.
16:09:23 <rdieter> #info browser votes now at +5/-2
16:09:38 <rdieter> I'll take futher proposal for replacement (firefox) onlist
16:09:43 <rdieter> thanks everyone
16:09:47 <rdieter> #endmeeting