15:01:07 #startmeeting kde-sig -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2012-07-17 15:01:07 Meeting started Tue Jul 17 15:01:07 2012 UTC. The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:07 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:01:14 #meetingname kde-sig 15:01:14 The meeting name has been set to 'kde-sig' 15:01:23 #topic roll call 15:02:19 Present. 15:02:41 * ltinkl present 15:03:17 * jreznik is here 15:03:38 present 15:03:45 * jgrulich present 15:04:24 #chair Kevin_Kofler ltinkl than jgrulich 15:04:24 Current chairs: Kevin_Kofler jgrulich jreznik ltinkl than 15:05:45 #info Kevin_Kofler jgrulich jreznik ltinkl than present 15:05:54 #topic Agenda 15:06:09 Uhm, who's jgrulich? 15:06:28 I'm new intern in RH 15:06:38 our new slave^H colleague :) 15:06:43 Welcome! :-) 15:06:52 and as the first topic today, he should introduce himself :) 15:06:56 ok, first topic :) 15:07:06 ltinkl: first let's collect agenda 15:07:20 hi, sorry I'm late 15:07:43 * jreznik is taking care of his new feature wrangler duties - there are a few interesting features from our POV 15:07:46 rdieter: hi! 15:07:56 #info rdieter present too 15:08:01 #chair rdieter 15:08:01 Current chairs: Kevin_Kofler jgrulich jreznik ltinkl rdieter than 15:09:06 jreznik: you mean new interesting features for F18? 15:09:19 ltinkl: yep 15:09:42 anything else? 15:11:28 ok, let's start 15:11:47 #topic Introduction of a new KDE SIG team member (jgrulich) 15:11:54 jgrulich: your turn :) 15:12:50 My name is Jan Grulich, i'm new intern in RH and i'm studying at Palacky University Olomouc :) 15:13:16 jgrulich: tell guys about your upstream contributions :) 15:14:10 jgrulich: welcome 15:14:24 and yep, welcome :) 15:14:37 As I already said: Welcome on board! 15:15:01 #link http://grulja.wordpress.com/ 15:15:26 i'm workin on google plasmoids. It was my bachelors work. 15:17:44 and btw. as you all know, I'm now the fedora program manager, it means less Fedora KDE work from my side (as a job), more as a contributor :) so I'm still here, still around! and we have jgrulich, so everything is fine :) 15:18:32 #info please welcome Jan Grulich (jgrulich) as a member of KDE SIG team 15:19:45 jgrulich: Looking at your blog, those are actually general Akonadi plasmoids with an option artificially restricting them to Google services by default, aren't they? I'd suggest defaulting ALL_COLLECTIONS to ON now that your thesis is complete unless there's a strong technical reason not to. 15:21:10 ALL_COLLECTIONS=ON is now default option, but i want rewrite this plasmoids to QML in future without dependency on Google 15:21:51 another QML into face of Kevin_Kofler :) 15:22:13 Why is everything being rewritten in QML? What a waste of time, rewrite to get something slower. :-( 15:22:27 jreznik: :D 15:23:31 But we're getting really off topic here. 15:23:34 ok, anything else on the topic? any task for jgrulich for the beginning? :) 15:24:20 #topic Features 15:24:50 http://fedoraproject.org/wiki/Features/KDE49 was approved on Monday's meeting, thanks guys for help with it! 15:25:39 is it in rawide repos? 15:25:49 #info KDE Plasma Workspaces 4.9 approved as Fedora 18 Feature 15:26:08 Caterpillar2: yep, not everything, it's still WIP 15:26:20 but the latest bits are availabe there 15:26:22 4.9.0 isn't even released yet. 15:26:33 Caterpillar2: and kde-unstable repo (4.8.97 currently) 15:26:34 We have the latest prerelease. 15:26:34 ok 15:26:54 Kevin_Kofler: ok, pre-release but it's looking good 15:27:46 it's rock solid, no problem encountered so far 15:28:10 rdieter: can I ask for kde-l10n? :) 15:28:25 ltinkl: ftbfs 15:28:29 oh 15:28:34 ok, nvm 15:28:43 Why is kde-l10n always broken? :-( 15:28:45 err, nevermind, that's calligra-l10n I was thinking of 15:29:07 btw what about the virtuoso issue and 4.9? we have 6.1.5... 15:29:11 sorry, i'll try to look at it today (unless someone else beats me to it) 15:29:15 rdieter: yep, calligra rc 15:31:22 phone call 15:32:01 arg, virtuoso has been available since march, and only now we hear that it has some serious regression. :( 15:32:03 guys, what about the virtuoso issue? 15:32:09 rdieter: yep, it's there 15:32:13 does not work at all 15:32:17 with 4.9 15:32:21 [17:21] ltinkl: short, Virtuoso maintainer (developer) is asking me to connect him to the packagers of the most used distros 15:32:29 from #solid 15:32:36 so, apparently options are to go back to 6.1.4 or wait for 6.1.6 available soon. I say wait for 6.1.6 15:32:54 soon = a few days, reportedly 15:33:05 Wait for 6.1.6, revert to 6.1.4 with the Epoch bump if 6.1.6 doesn't come in time for F18. 15:33:18 rdieter: I told afiestas to connect the virtuoso maintainer with you and to stop by #fedora-kde 15:33:44 i'm listening in #nepomuk-kde and #openlink-virtuoso already 15:33:54 so we should hopefully hear back from him soon 15:34:15 ok 15:34:43 * rdieter is cloning virtuoso githum repo, to start testing a snapshot build 15:34:50 github even. :) 15:35:18 There have been some user complaints about 6.1.5 a few days ago, it looks like the developers now acknowledge that it's broken. I wonder why it wasn't noticed sooner. 15:35:54 apparently it worked ok with 4.8, but 4.9 stuff tickles the regression (more?) 15:36:20 but that's just hearsay 15:37:28 ok, confirmed, folks in #nepomuk-kde just said 4.8 is fine 15:39:23 ok 15:39:26 * jreznik is back 15:39:45 Kevin_Kofler: +1 for the proposal 15:40:09 * jreznik is +1 to wait (but would like to see it before GA for proper testing - by beta max) 15:40:44 a new mail about Virtuoso 6.1.5 being buggy just arrived to kde-packager 15:41:33 "Virtuoso 6.1.4 is fine. And the virtuoso team have notified us that they'll be release 6.1.6 in a couple of days" 15:42:02 That's why I was saying "it looks like the developers now acknowledge that it's broken". :-) 15:42:34 Hopefully the "couple" of days won't be too many. :-) 15:43:18 so, everyone agrees with waiting for that few days (let's hope for a few days and not a few years ;-) 15:43:23 ? 15:43:58 I already said I agree. :-) 15:44:00 jreznik: +1, -1 for few years :) 15:44:09 else, I can work on packaging a 6.1.6 snapshot 15:44:47 #agreed to wait for 6.1.6, revert to 6.1.4 with the Epoch bump if 6.1.6 doesn't come in time 15:45:13 rdieter: let's add snapshot to the proposal 15:45:36 but if it will be released soon, I'm not sure it's worth investing time to create snapshot 15:46:29 sure, it's just insurance if a couple of days, ends up being weeks... :) 15:46:44 rdieter: yep 15:47:31 A snapshot is an acceptable fallback solution if it actually fixes the problem. 15:47:49 do we have a reference commit that fixes the issue? 15:48:36 I doubt it has been fixed already 15:49:11 no details about what is broken or what fixes it. :-/ 15:49:40 ok, so for now - it's nonsense to create a snapshot 15:50:15 and back to topic - there's a new feature ready for fesco - https://fedoraproject.org/wiki/Features/AvahiDefaultOnDesktop - do we want to join the train and enable Avahi by default for our spin (how much do we use Avahi?)... 15:52:09 Let everyone in your LAN (which can be a whole cable ISP or even the whole Internet in some configurations) print to your printer etc. by default? Sounds like a horrible security nightmare to me. 15:52:27 * rdieter isn't too famliliar with it, but tentative +1 to join and enable 15:53:06 avahi is only about discovery.... I thought 15:53:08 Kevin_Kofler: ...even on possibly otherwise "hostile" networks... 15:53:30 rdieter: but you know... 15:53:37 Hmmm, avahi both exports and imports stuff, it seems. 15:53:37 Kevin_Kofler: read https://fedoraproject.org/wiki/Desktop/Whiteboards/AvahiDefault 15:54:08 Enabling it by default will make importing "just work", but we need to be sure that things aren't shared (exported) if this hasn't been explicitly requested. 15:54:09 so seems like current Avahi defaults should be ok 15:54:25 but "should"... 15:54:40 jreznik: right, and if it isn't, fix it. :) 15:54:42 Having discovery of services shared by other machines just work by default makes sense. 15:55:47 and how does this affect KDE? 15:55:53 the discovery part is ok for me, it was patched to not export sensitive stuff... so... 15:56:16 ltinkl: that's the question how far is avahi stuff available in kde 15:56:20 * jreznik is not sure 15:56:45 there is AFAIK a kio slave but that's it 15:57:06 zeroconf:/ 15:58:23 anyone volunteer to investigate what can we gain by using avahi? if it is worth or not? 15:58:26 Dolphin -> Network -> Network Services 15:58:41 or any Open/Save dialog 15:59:06 it just prints an error message about mdnsd not running 15:59:33 could be a nice research task for jgrulich :) 16:00:20 seems to be running on my box, Loaded: loaded (/usr/lib/systemd/system/avahi-daemon.service; enabled) 16:00:39 rdieter: It's currently enabled, but firewalled, by default. 16:00:42 seems also to include dbus and socket activation. 16:00:49 (which makes it kinda useless) 16:00:53 oh heh, firewall 16:01:31 I wonder if the feature won't actually already enable Avahi for KDE without us having to do anything. 16:01:38 yep, firewall is one part of that feature 16:01:39 I think the idea is to just stop firewalling Avahi when installed. 16:01:49 yup 16:01:59 Kevin_Kofler: the feature is going to be enabled only on desktop spin 16:02:03 the question how (well) it works in KDE then 16:02:04 by default 16:02:29 * ltinkl notes we're running out of time 16:02:50 so yeah, for us - it's just make sure avahi is running too and not firewalled, the rest is done by avahi guy 16:03:04 ltinkl: yep :) 16:03:06 jreznik: It's not clear from the feature page what exactly they want to change and how. 16:03:16 I guess default firewall settings, but those really should NOT be spin-specific! 16:03:28 no no, the task for us is to make sure it works in KDE after having been enabled :) 16:03:35 Avahi should just be trusted by default by the firewall settings if that's the goal. 16:03:53 Kevin_Kofler: I also think it should not be spin specific, that's why I brought it here if we want to join (in case it's going to be implemented only on desktop spin) 16:04:05 ltinkl: yep 16:04:11 ok, we are 4 minutes over... 16:04:17 This feature needs to be sent back to the feature owners to ask for clarification. 16:04:33 I'm going to close the meeting -> #fedora-kde - thanks 16:04:58 Kevin_Kofler: it's up to FESCo, my job is to take a look, try to reach people but FESCo has to decide it 16:05:13 Kevin_Kofler: pls add it to Talk section, the best think we can do now :) 16:05:28 #endmeeting