15:01:06 <rdieter> #startmeeting kde-sig
15:01:06 <zodbot> Meeting started Tue May 30 15:01:06 2017 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:06 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:06 <zodbot> The meeting name has been set to 'kde-sig'
15:01:11 <rdieter> #meetingname kde-sig
15:01:11 <zodbot> The meeting name has been set to 'kde-sig'
15:01:16 <rdieter> #topic roll call
15:01:25 <rdieter> hi all, friendly kde-sig meeting, who's present today?
15:02:04 <lupinix> hi
15:02:23 <pino|work> o/
15:02:33 <CRCinAU> \\o
15:02:49 <tosky> hi
15:02:53 <rdieter> #info lupinix pino|work CRCinAU tosky present
15:04:36 <rdieter> #topic agenda
15:04:39 <rdieter> ok, what to discuss today?
15:04:47 <rdieter> f26 related issues/blockers (of course)
15:05:31 <tosky> can you please give a summary of the status? Due to some work-related duties and then preparation for a small vacation I'm a bit out of sync
15:05:33 * heliocastro here
15:05:35 <tosky> (more then usual at least :)
15:05:43 <rdieter> sure
15:05:46 <rdieter> #info heliocastro present
15:06:46 <rdieter> mkyral says present (in #fedora-kde) :)
15:07:01 <lupinix> mkyral: give us a "hello" :D
15:07:08 <mkyral> hi there
15:07:18 <heliocastro> I want add a topic: Fedora on KDE CI
15:07:24 <rdieter> ok, added
15:07:38 * rdieter can give brief calligra3 status report
15:07:59 <rdieter> I guess we can have a general topic on status reports (can do Qt-5.9 at the same time then)
15:08:23 <rdieter> ok, let's get started
15:08:29 <rdieter> #topic f26 issues/blockers
15:08:45 <rdieter> the only blockery item I recall is the plasma-pk-updates one, where it shouldn't run on the live image
15:09:14 <rdieter> .bug 1436873
15:09:14 <zodbot> rdieter: Bug 1436873 – KDE live environment notifies of available updates - https://bugzilla.redhat.com/1436873
15:09:56 <rdieter> I think that's the only one I see for beta or final listed @ https://qa.fedoraproject.org/blockerbugs/
15:10:38 <rdieter> will anyone have interest/time to look into that?  (sorry, I haven't)
15:10:50 <rdieter> it's only a final blocker, so we still have some time
15:10:51 <heliocastro> What is the strategy ? Disable it by default ?
15:11:05 <rdieter> heliocastro: we want it disabled on live image, but enabled once installed
15:11:25 <lupinix> no time here :( research project did not get expanded → have to search for anew job @next weeks…
15:11:46 <rdieter> even if you only have implementation ideas, please make a note in the bug
15:12:01 <rdieter> the current hack of modifying the related .desktop file no longer works (apparently)
15:12:27 <rdieter> ie, https://bugzilla.redhat.com/show_bug.cgi?id=1436873#c1
15:12:30 <heliocastro> rdieter: There's the dirty-and-easy solution
15:12:31 <lupinix> my only ugly (!) hack would be deleting that .desktop file in live init
15:12:51 <rdieter> heliocastro: that is?
15:12:57 <CRCinAU> For clarification of the minutes, is everyone in agreement that there are currently ZERO blockers on the beta criteria as per: http://fedoraproject.org/wiki/Fedora_26_Beta_Release_Criteria
15:13:09 <rdieter> I think we may end up having to delete both plugin and .desktop file(s)
15:13:09 <lupinix> i only see the no longer working solution there
15:13:11 <heliocastro> rdieter: a bash profile script
15:13:19 <heliocastro> pointing to update-alternatives
15:13:30 <heliocastro> So, install the .desktop files elsewhere
15:13:44 <rdieter> use alternatives ?  eek, that's worse the deleting the files :)
15:13:51 <heliocastro> Is not
15:14:18 <rdieter> I think so, but I also have a strong dislike of alternatives
15:14:32 <heliocastro> Me too, but is serves for thys purpose
15:14:32 <rdieter> though I don't think that'll help here
15:14:40 <heliocastro> Why not ?
15:15:10 <rdieter> So, how for package to distinguish between live vs real install?
15:15:22 <heliocastro> we have a env var, right ?
15:15:24 <rdieter> I guess we could tweak the alternative in the live kickstart
15:15:38 <rdieter> ok, env var + script could help too
15:15:45 <heliocastro> yes, that's it
15:16:01 <rdieter> but I really don't think we have to do that far, deleting the file(s) on the live image will be much simpler and accomplish the same goal
15:16:32 <rdieter> though I would prefer a cleaner solution, if possible, but requires someone more knowledgable of plasma internals
15:16:53 * heliocastro can check
15:17:18 <rdieter> deleting files I guess is far from clean too, rpm -V would notice
15:17:42 <rdieter> I guess I don't care as long as it works
15:18:35 <heliocastro> How long we have until have a proper solution ?
15:19:38 <rdieter> it's a final blocker... so release will block until it's fixed theoretically :)
15:19:45 <heliocastro> Ahaha
15:19:52 <heliocastro> Ok, not much time
15:20:05 <rdieter> june 20 is final freeze, so ideally before that
15:20:21 <rdieter> https://fedoraproject.org/wiki/Releases/26/Schedule
15:20:23 <rdieter> accordingn to ^^
15:20:48 <rdieter> sooner the better of course
15:21:16 <CRCinAU> can I ask a plainly dumb question - as someone booted the live image and confirmed that the value is actually changed in the related .desktop files once the live image is started?
15:21:31 <tosky> so, let's put it this way: deleting the file makes the system not clean, but as the live environment is only valid for the live and not propagated to the installed system, it should not matter
15:21:33 <tosky> is it correct?
15:21:42 <rdieter> tosky: correct
15:22:00 <heliocastro> The install still is a propagation of the live image ?
15:22:12 <rdieter> CRCinAU: not that I'm aware of, but as the file modification trick worked for f25 release, i think it's safe to assume too
15:22:39 <rdieter> heliocastro: it is, minus modifcations made after the image was made
15:22:46 * lupinix does the same thing (deleting .desktop file) for dnfdragora updater applet @lxqt spin, works just fine
15:22:58 <rdieter> (modifications include editing or deleting files as mentined here)
15:23:03 <CRCinAU> rdieter: my point is, has the value actually been changed in the result of the live image, and the update notification is being reenabled by something else - or has the change failed in the first place and its acting as designed.
15:23:21 <rdieter> lupinix: your .desktop is autostart though, different case than plasma applets
15:23:33 <lupinix> true
15:23:35 <rdieter> CRCinAU: I know what you mean
15:23:40 * than is present
15:23:42 <rdieter> I'm saying: unlikely
15:24:00 <rdieter> #info than present
15:24:02 <rdieter> than: hi
15:24:18 <CRCinAU> rdieter: unlikely that the file has been changed? or ...?
15:24:27 <than> hi all
15:24:31 <rdieter> CRCinAU: yes (both cases you mentioned)
15:24:47 <rdieter> or rather, unlikely the file isn't what we expect
15:24:53 <than> rdieter:  did you add ‎mkyral‎‎ to our kdesig
15:25:06 <rdieter> than: no, but I was planning on discussing that today
15:25:16 <than> ah ok
15:26:04 <rdieter> anything else on the topic?  otherwise, any help/input on the bug would be appreciated
15:26:19 <CRCinAU> rdieter: I looked on my desktop install, the sed snippet worked as expected...
15:26:39 <CRCinAU> as in, at least it changed the values that its designed to tweak.
15:27:01 <tosky> if the file is removed from the image, shouldn't side effect be found by regression testing (including a simple installation)?
15:27:18 <tosky> the point is: even if ugly, maybe better try it now?
15:27:48 <rdieter> tosky: I think so
15:29:55 <rdieter> moving on...
15:30:10 <rdieter> #topic adding mkyral to kdesig fas group
15:30:36 <rdieter> mkyral has been doing some good work on copr for newer plasma builds
15:30:39 <lupinix> i'm fine with that as mkyral does excellent work @copr
15:31:12 <rdieter> and it's been suggested that we bring them on as plasma comaintainer (sponsor into packager/kdesig groups)
15:31:40 <rdieter> any comment?
15:31:45 <rdieter> fwiw, I'm ok with it
15:32:05 <rdieter> or in particular, any objections? (otherwise, we'll likely 'just do it')
15:32:50 <tosky> (no objections)
15:33:04 <heliocastro> None from my side
15:33:53 <rdieter> mkyral: do you have a FAS account already?  (I guess so, same as irc nick?)
15:34:11 <mkyral> rdieter: i think so, lemme check
15:34:17 <lupinix> well without fas account no copr account?
15:34:45 <lupinix> .fasinfo mkyral
15:34:45 <rdieter> lupinix: yeah, I think you're right
15:34:45 <zodbot> lupinix: User: mkyral, Name: Martin Kyral, email: mkyral@redhat.com, Creation: 2012-10-18, IRC Nick: None, Timezone: UTC, Locale: en, GPG key ID: None, Status: active
15:34:48 <zodbot> lupinix: Approved Groups: +gitbeakerlib cla_fpca cla_done
15:34:59 <mkyral> rdieter: yep
15:35:00 <lupinix> even with fancy @redhat.com mail :D
15:35:10 <rdieter> ok, I see no objections, I'll sponsor into packager, kdesig groups after meeting
15:35:18 <rdieter> mkyral: congrats, use your powers for good :)
15:35:20 <mkyral> rdieter: thanks
15:35:31 <mkyral> rdieter: i'll do :)
15:35:41 <rdieter> #topic Fedora on KDE CI
15:35:43 <rdieter> heliocastro: ? ^^
15:35:43 <CRCinAU> someone else for me to harass ;)
15:35:47 <heliocastro> Hey
15:36:01 <heliocastro> So, bBen Cooksley approach me and the new CL has docker features
15:36:23 <heliocastro> So, we now have KDE testing Fedora in a near future
15:36:47 <heliocastro> Will be same as OpenSuse, etc, etc..
15:36:52 <lupinix> nice!
15:37:04 <rdieter> using a fedora docker image?
15:37:10 <heliocastro> The only current blocker comes from my part, that i decided not go with 5.8
15:37:29 <rdieter> a docker image generated how by whom?
15:37:38 <heliocastro> Extended Fedora docker image, ours + my entries
15:37:55 <rdieter> so something you make by hand or automated?
15:38:11 <heliocastro> Full fedora image is ours official
15:38:26 <heliocastro> and extended entries in my by hand, is in KDE source repo already
15:38:27 <heliocastro> a minute
15:38:52 <rdieter> (dont need gory details here, if that's what you're doing)
15:39:00 <rdieter> though would be nice to have extended info details onlist
15:39:24 <heliocastro> Yes, i know, but i did in a hurry to avoid loose the timing ( and my free time )
15:40:38 <rdieter> anyway, this is really good news
15:40:55 <rdieter> so how does the CI work?
15:41:05 <rdieter> and what does it do specifically?
15:41:06 <heliocastro> https://phabricator.kde.org/source/sysadmin-ci-tooling/browse/master/system-images/fedora/
15:41:29 <heliocastro> All commits of KDE will be tested automatically on this docker images
15:41:44 <heliocastro> If fails developers will notice
15:41:55 <heliocastro> This will include Windows for some apps too
15:41:59 <tosky> it's the testing instance of the new upstream CI
15:42:06 <heliocastro> yes
15:42:19 <heliocastro> That is about to be released.
15:42:23 <rdieter> commits ... will be tested automatcially... means what exactly?
15:42:26 <tosky> the new codebase makes it easier to support more distributions, in addition to more OSs, using docker
15:42:28 <rdieter> that things still continue to build?
15:42:42 <rdieter> does that include any sort of runtime testing?
15:42:52 <rdieter> and/or autotests?
15:42:55 <heliocastro> rdieter: Means that code will be released only if compiles properly and tests pass in all images
15:42:56 <tosky> so it's like the old one: whenever a commit is pushed to a tracked git repository, that repository is rebuilt
15:43:03 <rdieter> ok
15:43:06 <rdieter> nice
15:43:37 <heliocastro> So, theoretically we will need to worry only on the specifics of fedora
15:43:38 <rdieter> assuming we don't have any distro-specific things that break autotests :)
15:43:49 <heliocastro> They have centos as well too
15:43:53 <tosky> we will see it soon
15:44:10 <rdieter> not sure how they test centos, using epel kf5 ?
15:44:16 <rdieter> or they use their own builds?
15:44:38 <rdieter> (I guess it doesn't matter, but would be nice to know someday)
15:44:40 <heliocastro> kde is built, no kf5
15:44:47 <tosky> EPARSE
15:44:50 <heliocastro> Only Qt and other related deps are installed
15:44:51 <rdieter> so nothing that depends on kf5?
15:44:58 <heliocastro> Yes
15:45:03 <rdieter> k, they *could* if they used epel :)
15:45:10 <tosky> uhm, I don't see centos enabled so far on the new build server
15:45:18 <tosky> nor defined (https://cgit.kde.org/sysadmin/ci-tooling.git/tree/system-images)
15:45:32 <heliocastro> kdevelop guys are complaining, but if not there, i'll do it anywayrt
15:45:44 <mkyral> gotta go now
15:45:47 <mkyral> bye
15:45:53 <heliocastro> I have qt 5.9 compiled as wel for epel 7
15:45:54 <rdieter> mkyral: ok, thanks
15:45:57 <heliocastro> mkyral: See ya
15:46:03 <rdieter> heliocastro: in copr?
15:46:13 <heliocastro> Yep :-)
15:46:13 <mkyral> fyi: the 5.10.0 build in copr has just finished
15:46:30 <rdieter> (I assume, since newer rhel7 will include Qt5 5.6)
15:46:46 <rdieter> and Qt5 will be removed from epel7 soon
15:47:13 <rdieter> ironic that rhel gets 5.6 and new 5.9 lts release is on the horizon
15:47:35 <rdieter> <shrug>
15:47:36 <heliocastro> No time to have 5.9 unfortunately
15:47:44 <pino|work> well qt 5.9 as lts was announced quite recently
15:47:45 <heliocastro> 5.9 will be released next week
15:47:57 <rdieter> pino|work: true, a pleasant surprise
15:48:15 <pino|work> if they do a proper job in maintaing it, i guess
15:48:24 <heliocastro> 5.8 was kind of a disaster, but 5.9 is shaping really really good
15:48:47 <lupinix> pino|work: "if" means no… at least for qtwebengine it is a mess
15:49:08 <rdieter> move on?
15:49:18 <heliocastro> Move on
15:49:21 <lupinix> yes
15:49:22 <rdieter> #topic status updates
15:49:54 <rdieter> As heliocastro mentioned, Qt 5.9 release is soon, rc1 is in rawhide (right?)
15:50:12 <heliocastro> Yes, except for  !! webengine, of course
15:50:24 <rdieter> existing webengine is fine for our purposes
15:50:33 <heliocastro> But this will be deal with me tomorrow if Kevin manifest the lack of time
15:50:37 <rdieter> one question: how hard to push to get Qt 5.9 into f26 ?
15:50:45 <rdieter> (after beta freeze lifts of course)
15:51:05 <heliocastro> rdieter: copr has all for epel7, f25 and f26
15:51:06 <rdieter> Qt 5.9 +  plasma-5.10.x would be a nice combination I think :)
15:51:17 <heliocastro> So, is just recompiel
15:51:21 <heliocastro> *recompile
15:51:22 <rdieter> heliocastro: sure, that's a start, but there are a lot of rebuilds needed too
15:51:36 <lupinix> have to test with lxqt, with 5.8 there were some issues
15:52:12 <rdieter> ie, rebuild the set of packages that use/depend-on private api's
15:52:14 <heliocastro> Well, if Fedora main powers allow us to do, i would love to do this effort to jump to plasma 5.10 and qt 5.9
15:52:31 <rdieter> heliocastro: agreed
15:52:58 <heliocastro> I'm all about sucide missions
15:53:02 <heliocastro> suicide
15:53:10 <rdieter> since qt5-qtquick1 FTBFS against Qt 5.9... retiring that is needed for f26 too then
15:53:36 <lupinix> i guess we should retire before final freeze then
15:53:55 <rdieter> yep
15:54:03 <heliocastro> rdieter: And we need approve that remaining packages as well
15:54:31 <rdieter> heliocastro: nice-to-have, but not a necesity
15:54:38 <heliocastro> speech is needed
15:54:43 <heliocastro> the rest is nice to have
15:54:46 <rdieter> nothing has a hard depenency on these, is there?
15:54:52 <heliocastro> Nope
15:54:58 <rdieter> ok
15:55:13 <heliocastro> only for epel7, but then, different history
15:55:15 <rdieter> I agree though, qtspeech is more important than the other new modules
15:55:40 <tosky> certainly from Applications 17.08
15:56:16 <rdieter> fwiw, I've been working my way through kde-apps-17.04.x stack for rawhide (and f26)
15:56:28 <rdieter> got core packages, pim, multimedia stuff done so far
15:57:07 <rdieter> and graphics ones
15:57:27 <rdieter> graphics not built for f26 yet though
15:58:20 <rdieter> and picked up working on calligra3 stuff today
15:58:42 <rdieter> .bug 1441801
15:58:42 <zodbot> rdieter: Bug 1441801 – calligra3 tracker - https://bugzilla.redhat.com/1441801
15:58:44 <rdieter> tracks progress ^^
15:58:53 <rdieter> includes 4 new package reviews
15:59:11 <rdieter> this is first kf5-based calligra (office) suite
15:59:22 <rdieter> for anyone not familiar with it
15:59:57 <rdieter> still have local work-in-progress base calligra builds to work on (mostly updating large %files listings for new builds)
16:00:50 <heliocastro> rdieter: Maybe you can do smartass things, like generate cmake for first run,  check the build/installed-files.txt and push through script on the spec
16:01:01 <rdieter> test f25 builds @ https://copr.fedorainfracloud.org/coprs/rdieter/calligra3
16:01:15 * heliocastro thinking on create spec automatically based on the cmake output on configure
16:01:23 <rdieter> heliocastro: I already have that :)
16:01:38 <heliocastro> Hah :-)
16:01:48 * heliocastro high fives rdieter
16:01:52 <rdieter> hard part is that calligra has many subpackages, need to decide where to put the files
16:02:11 <rdieter> (well, something close to that anyway)
16:04:09 <rdieter> anyway, blocking on those 4 reviews, so as usual, any help there would be appreciated
16:04:22 <rdieter> ideally, I'd like this in time for f26 too, so we can ship one less kde4-based app
16:04:31 <rdieter> #topic open discussion
16:04:36 <rdieter> anything else for today"?
16:04:46 <heliocastro> Nope from me
16:04:54 <heliocastro> And i'm been kicked from the office
16:04:57 <heliocastro> Last one
16:05:13 * lupinix will have less time within next weeks to help
16:05:34 <lupinix> research project did not get expanded → have to investigate for new jobs…
16:06:48 * heliocastro need to go
16:07:01 <rdieter> alright, thanks everyone!
16:07:05 <rdieter> #endmeeting