15:23:20 <rdieter> #startmeeting kde-sig
15:23:20 <zodbot> Meeting started Tue Jan  5 15:23:20 2016 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:23:20 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:23:20 <zodbot> The meeting name has been set to 'kde-sig'
15:23:24 <rdieter> #meetingname kde-sig
15:23:24 <zodbot> The meeting name has been set to 'kde-sig'
15:23:27 <rdieter> #topic roll call
15:23:36 <dvratil> hello!
15:23:36 <rdieter> hi all, friendly kde-sig meeting, who's present today?
15:23:41 <jgrulich> hello :)
15:24:31 <rdieter> #info rdieter dvratil jgrulich present
15:24:35 <rdieter> #chair dvratil jgrulich
15:24:35 <zodbot> Current chairs: dvratil jgrulich rdieter
15:26:14 <tosky> hi
15:26:48 <rdieter> #info tosky present
15:26:51 <rdieter> #chair tosky
15:26:51 <zodbot> Current chairs: dvratil jgrulich rdieter tosky
15:26:56 <heliocastro> here
15:27:02 <rdieter> #info heliocastro present
15:27:04 <rdieter> #chair heliocastro
15:27:04 <zodbot> Current chairs: dvratil heliocastro jgrulich rdieter tosky
15:27:10 <rdieter> #topic agenda
15:27:20 <rdieter> what to discuss today?
15:27:28 <dvratil> I can give quick KF5 update
15:27:45 * rdieter has Qt-5.6.0 status/issues (new plasma user startup, in particular)
15:27:47 <dvratil> and we could discuss the Plasma 5 for Centos7 idea
15:29:08 <rdieter> ok, let's get started
15:29:16 <heliocastro> and my idea for CI
15:29:24 <rdieter> #topic KF5 update
15:29:25 <rdieter> heliocastro: ok
15:29:29 <rdieter> dvratil: go ahead
15:29:40 <dvratil> ok. So KF5 5.18 is in rawhide and updates are in Bodhi since today, so please go test :)
15:30:13 <dvratil> Plasma 5.5.3 release has been postponed until tomorrow, so once tarballs are out, I'll try to get it in as quickly as possible
15:30:33 <rdieter> excellent
15:30:40 <heliocastro> \o/
15:30:57 <dvratil> <EOF>
15:31:02 <rdieter> dvratil: I had one question, after looking closer at a lot of kf5 pkgs over the holidays
15:31:22 <rdieter> dvratil: was there a reason for splitting kf5-filesystem and kf5-rpm-macros ?
15:31:48 <dvratil> IIRC Kevin asked for that in the original review
15:31:51 <rdieter> I forget, because putting kf5-rpm-macros into kf5-filesystem would save at least 1 BuildRequires for all packages
15:32:13 <rdieter> dvratil: ok, I'll try to ask him after the meeting
15:32:30 <rdieter> I mean, that's how kde4 does it (puts macros.kde4 there)
15:32:43 <rdieter> so we could assume it's always present
15:32:44 <dvratil> " Daniel Vrátil 2014-04-16 08:47:43 EDT
15:32:45 <dvratil> It was decided on last KDE SIG meeting that we want to split the package to kf5-filesystem and kf5-rpmmacros (and eventually add kf5-settings if we decide we need it in future), so I renamed the base package to "kf5" and updated the request accordingly."
15:32:53 <dvratil> https://bugzilla.redhat.com/show_bug.cgi?id=1086447#c5
15:33:57 <rdieter> thanks, I'll try to find old logs, and get back you if I think think there's anything else worth doing
15:34:02 <dvratil> sure
15:34:19 <rdieter> #topic kf5/plasma5 for centos7
15:34:42 <rdieter> I assume doing kf5 is a first step (prerequisite)
15:34:47 <heliocastro> Can be done easily
15:34:50 <dvratil> so apparently there's an interest in having a modern desktop on Centos :)
15:34:51 <rdieter> dvratil: for epel-7 ?
15:35:05 <heliocastro> i alread ported few peackages for my lxqt build
15:35:13 <heliocastro> ported == just recompile
15:35:15 <heliocastro> no spec change
15:35:18 <dvratil> I updated my dvratil/epel-playground last night to have all frameworks
15:35:30 <dvratil> I'll try to look into having Plasma packages in the copr tonight maybe
15:35:47 <heliocastro> dvratil: Using which cmake ?
15:35:58 <dvratil> your cmake3
15:36:03 <heliocastro> greate, so worked
15:36:19 <rdieter> ok, so initial target is just copr for both kf5 and plasma5?
15:36:32 <rdieter> I can see kf5 being useful for epel-7
15:36:38 <dvratil> yeah, apps can go later
15:36:46 <dvratil> if at all
15:36:54 <dvratil> however if everything works, the question is do we (KDE SIG) want to maintain yet another branch of Plasma for EPEL, and where?
15:36:56 <heliocastro> But will be a pain to request packages for epel, no ?
15:36:57 <Kevin_Kofler> For the rpmmacros thing, IMHO it's cleaner to not have devel stuff in a package that everything requires, but I don't feel strongly about it, it's not like it's a big file.
15:37:22 <Kevin_Kofler> You maintain it, you decide.
15:37:37 <rdieter> Kevin_Kofler: ok, it's a balance of having devel stuff in -filesystem vs. an extra BuildRequires everywhere
15:37:48 * jreznik is here
15:37:51 <dvratil> should we try to get whole Frameworks to official EPEL repos? Does the montly released cycle make sense there?
15:38:18 <heliocastro> dvratil: It makes sense
15:38:19 <rdieter> dvratil: personally, *I* would like to see frameworks in epel eventually
15:38:32 <rdieter> but the quick release cycle could be a little problematic
15:38:46 <heliocastro> Is not our problem that redhat decided to fix gnome releases with rebases
15:38:51 <rdieter> just a nice-to-have thing
15:38:54 <Kevin_Kofler> The problem is that it'd likely take ages to get stuff through there and you'd either have to wait before doing the Plasma Copr builds or build newer Frameworks in Copr that override EPEL.
15:39:21 <rdieter> Kevin_Kofler: <nod>
15:39:32 <heliocastro> We have a nice place on copr, no need to worry. If they accept it better
15:39:38 <Kevin_Kofler> And you also can't replace system libraries with newer versions where needed, whereas in Copr you can.
15:39:52 <dvratil> we don't really need any replacement
15:40:01 <Kevin_Kofler> Qt 5?
15:40:05 <Kevin_Kofler> Or is that in EPEL too?
15:40:12 <dvratil> qt5 is in EPEL, or not?
15:40:17 <jgrulich> it is
15:40:27 <heliocastro> But old as hell
15:40:28 <rdieter> dvratil: well, I'd assume plasma5 would continue to replace kde4
15:40:28 <tosky> are official CentOS WG putting stuff on EPEL or to some special repositories?
15:40:34 <Kevin_Kofler> There may be other deps though. You'll see in the end.
15:40:51 <Kevin_Kofler> rdieter: Plasma of course, but Frameworks?
15:40:58 <dvratil> rdieter: yes, that's why Plasma would have to stay in COPR IMO
15:41:05 <rdieter> dvratil: +1
15:41:08 <Kevin_Kofler> Those could live in EPEL, but the problem might be required system libs.
15:41:13 <dvratil> we can't just replace KDE4 through EPEL
15:41:18 <jgrulich> epel has Qt 5.5.1
15:41:22 <Kevin_Kofler> dvratil: Of course.
15:41:29 <heliocastro> jgrulich: Ok, good
15:41:29 <dvratil> Kevin_Kofler:  and I only pulled libepoxy, dbusmenu-qt5 and polkit-qt5 into the copr repo, which is easy.
15:41:41 <dvratil> and qt 5.5 is new enough
15:41:53 <dvratil> + cmake3 of course, but that already is in epel (heliocastro?)
15:41:58 <Kevin_Kofler> I'd have expected more problematic system libs.
15:42:00 <tosky> because, for example,  RDO packages are hosted on baseurl=http://mirror.centos.org/centos/7/cloud/$basearch/openstack-liberty/
15:42:02 <rdieter> fwiw, epel Qt5 tracks fedora versions relatively closely
15:42:22 <tosky> but I don't know the rules on how to become involved as CentOS special groups
15:42:26 <heliocastro> dvratil: Nope, than was suppose to give the last word on that
15:43:00 <dvratil> we'll need to get that in first of course,. cmake3 is the prerequisite of everything
15:44:10 <tosky> and also RDO packages duplicated/overload some of the base packages, so it shouldn't be a problem
15:44:19 <tosky> I guess the path is the one described here: https://wiki.centos.org/SpecialInterestGroup
15:44:54 <rdieter> pardon my ignorance, but what does RDO stand for?
15:45:13 <tosky> it's a community packaging of OpenStack
15:45:23 <tosky> see for example: https://lists.centos.org/pipermail/centos-announce/2015-October/021441.html
15:45:25 <dvratil> well if we get Frameworks to EPEL, then we don't really need to care about Centos specifically, right?
15:46:09 <heliocastro> yep
15:46:17 <rdieter> going the centos SIG route seems like a lot of extra work, for what gain?
15:46:18 <heliocastro> in epel == in centos
15:46:23 <rdieter> (compared to just using epel and/or copr)
15:46:46 <rdieter> I suppose it could attract more contributors
15:46:49 <tosky> I guess it depends on how many epel dependencies are needed
15:47:01 <dvratil> so the plan would be get Frameworks to EPEL, setup @kdesig/plasma5-epel COPR to maintain up-to-date Plasma release?
15:48:34 <rdieter> dvratil: something like that, sounds good to me... though... I'm not sure using @kdesig would be good here
15:48:48 <dvratil> why?
15:48:51 <heliocastro> Do we need a separate set for epel ?
15:49:24 <heliocastro> can't be same packages for plasma5 on fedora and epel ?
15:49:25 <rdieter> dvratil: well, contributors to @kdesig must be members of kdesig group in FAS.
15:50:00 <rdieter> I can see cases where we may want to give access to plasma5-epel so someone, but not *all* of kdesig pkgs
15:50:27 <dvratil> hmm, indeed
15:50:46 <rdieter> though meh, I'd rather be more open in permissions than too closed
15:51:02 <heliocastro> Yes, what i was about to sau
15:51:20 <heliocastro> kde history, you're allowed until you do something wrong, which rarely happens
15:51:21 <rdieter> heliocastro has a point, about a common copr for both fedora and epel
15:51:37 <rdieter> but that could be more work
15:51:46 <heliocastro> Will be same package, same build, is one time work i think
15:51:59 <rdieter> dvratil: what do you think about a common copr for both fedora/epel ?
15:52:14 <dvratil> well copr for Fedora does not make much sense, since we already have Plasma in Fedora repos
15:52:24 <heliocastro> dvratil: Makes sense a lot
15:52:36 <dvratil> and we don't want to tell people "please add @kdesig/plasma" to get KDE on Fedora
15:52:41 <rdieter> for prereleases maybe
15:52:42 <heliocastro> We do not release all up to date things ever on fedora
15:52:51 <heliocastro> Yes, and testing
15:52:56 <dvratil> pre-releeases, testing - of course
15:52:59 <dvratil> but not for stable releases
15:53:07 <heliocastro> We can keep stable there and main repos
15:53:12 <heliocastro> no problem on that
15:53:14 <dvratil> (and then you don't want to have unstable releases of Plasmas as the only ones for EPEL)
15:53:50 <dvratil> so one stable copr for EPEL, one unstable copr for Fedora + EPEL
15:54:05 <heliocastro> Nope
15:54:06 <rdieter> ok, I was on the fence, but I think I'd tend to agree with dvratil that we don't need to mess with fedora buildroots in copr (for now)
15:54:06 <dvratil> (we already have @kdesig/plasma-5-unstable)
15:54:13 <heliocastro> Treat as rolling release
15:54:32 <dvratil> we already do rolling release for Fedora
15:54:32 <heliocastro> we do the stable on both sides
15:54:33 <rdieter> heliocastro: kf5/plasma5-wise, fedora is essentially a rolling release already
15:54:40 <heliocastro> I mean
15:54:58 <heliocastro> Ok, in this case i agree
15:55:05 <heliocastro> We just need to use same set of packages
15:55:11 <heliocastro> no duplicate efforts
15:55:19 <dvratil> that's easy; new COPR supports remote distgits
15:55:35 <dvratil> you specify git repo, path to spec file, branch to build from
15:56:08 <heliocastro> Yep, and this plays on my side
15:56:14 <heliocastro> for the next topic :-)
15:56:24 <dvratil> so we can build our EPEL packages from F22 branches in Fedora distgit for example, so that will make the sharing much easier
15:56:38 <rdieter> ok, moving on
15:56:40 <rdieter> dvratil: +1
15:56:40 <dvratil> (although I tried last night and it did not work yet)
15:56:41 <rdieter> good idea
15:57:11 <rdieter> moving on....
15:57:34 <rdieter> #topic qt-5.6.0/plasma5 initial startup failures
15:58:07 <rdieter> so I was able to reproduce the rawhide problem on f23 yesterday
15:58:33 <rdieter> seems the *first* login to plasma5 (with qt-5.6.0-beta) yields a non-functional plasmashell
15:58:48 <heliocastro> race condition ?
15:58:59 <rdieter> .bug 1283348
15:59:02 <zodbot> rdieter: Bug 1283348 Black screen on KDE live session (with qemu-kvm) - https://bugzilla.redhat.com/1283348
15:59:09 <rdieter> heliocastro: a race condition that happens *every* time ? :)
16:00:00 <rdieter> my test (on f23) was login to plasma5 with user empty ~/.local, ~/.kde, ~/.config
16:00:03 <heliocastro> Only on first login, right ?
16:00:08 <rdieter> heliocastro: yes
16:00:17 <rdieter> kill/restart plasmashell and all was fine
16:00:34 <heliocastro> So, plasmashell starts, try to see settings, there's none, don't know what to do
16:00:36 <heliocastro> black
16:00:49 <rdieter> if anyone with more qt5/plasma5 fu than me can try testing/debugging that, would be my hero
16:00:50 <heliocastro> then we kill, usually it saves the settings
16:01:05 <heliocastro> Next time plasmashell have settings to read
16:01:17 <heliocastro> Sounds like missing defaults on first run
16:01:21 <rdieter> the bug filed above seems to match approximately when qt-5.6 landed in rawhide
16:01:56 <rdieter> we already had some other wierdness on initial login before (with qt-5.5)
16:02:00 <heliocastro> I can try reproduce, but only on weekend
16:02:11 <heliocastro> Need to do step by step on startkde
16:02:51 <rdieter> https://bugs.kde.org/show_bug.cgi?id=353962
16:02:54 <rdieter> the other issue ^^
16:02:56 <tibbs|w> I was having this as well.
16:03:00 <tibbs|w> The black screen thing.
16:03:28 <tibbs|w> Am happy to try things out on my rawhide laptop if that would help.
16:03:49 * jgrulich can test too tomorrow
16:03:54 <rdieter> also, Qt upstream has a candidate fix for ...
16:03:56 <rdieter> .bug 1291003
16:03:58 <zodbot> rdieter: Bug 1291003 qt-5.5 segfault on QFileDialog without parent - https://bugzilla.redhat.com/1291003
16:04:02 <rdieter> pulled into our latest qt5-qtbase builds
16:04:12 <rdieter> (the 5.6.0 only ones so far)
16:04:31 <rdieter> I'll do more testing, before working on any backport to 5.5
16:04:37 <heliocastro> rdieter: The three screens issue that i had before gone in last three or four updates ago
16:04:42 <jgrulich> rdieter: that explains why I couldn't find F22/F23 update in bodhi
16:05:08 <jgrulich> rdieter: I can test that fix on 5.5.1 tomorrow too
16:05:16 <rdieter> jgrulich: ok, great
16:05:29 <jgrulich> I remember experiencing it with plasma-nm
16:06:44 <rdieter> arg, I just hit the crash with the latest build.  good news:  my fault, I'd put the patch into git, but not actually applied it yet :(
16:07:07 <rdieter> ok, any other qt5 issues worth mentioning?
16:07:14 <rdieter> (else, can move on to CI topic)
16:07:30 <Kevin_Kofler> Is QtWebEngine on for discussion today?
16:07:47 <heliocastro> nope in the topics
16:07:48 <rdieter> Kevin_Kofler: we can if you want
16:07:58 <Kevin_Kofler> I can give a short report of what I have.
16:08:03 <heliocastro> Go ahead
16:08:33 <Kevin_Kofler> So I took over the review to get it moving again:
16:08:36 <Kevin_Kofler> .bug 1295549
16:08:38 <zodbot> Kevin_Kofler: Bug 1295549 Review Request: qt5-qtwebengine - Qt5 - QtWebEngine components - https://bugzilla.redhat.com/1295549
16:09:04 <Kevin_Kofler> I updated the package to 5.5.1 first, and fixed the most obvious issues (like bogus BuildRequires).
16:09:19 <Kevin_Kofler> 5.5.1 is working now, but not really interesting in the end.
16:09:38 <Kevin_Kofler> So I started working on 5.6 beta, and I almost have that going too.
16:09:53 <Kevin_Kofler> What I need to fix (regressions compared to the 5.5.1 package) is:
16:10:20 <Kevin_Kofler> * Upstream's unbundling support does not run the replace_gyp_files.py script, I need to patch it to do that so we don't have 2 lists of "use_system_*".
16:11:11 <Kevin_Kofler> * The external libffmpegsumo.so is not being built, I need to (re)add the flag to the config so that ffmpegsumo is replaceable.
16:11:55 <Kevin_Kofler> But the build is running to the end (choked only on the file list because of the ffmpegsumo issue), so we should be good to go soon. I'll update the review as soon as I have 5.6 beta building.
16:12:36 <Kevin_Kofler> The no-sse2 patch and the GStreamer stuff, I want to work on after review.
16:12:59 <Kevin_Kofler> (no-sse2 SHOULD be good to go, but I haven't even tested compiling yet, so…)
16:13:20 <Kevin_Kofler> (GStreamer, I haven't tried to backport/forward-port/port those patches to QtWebEngine.)
16:13:40 <rdieter> agreed
16:13:54 <rdieter> focus on review-blocker stuff for now
16:14:01 <Kevin_Kofler> I hope we can get this in now. The unbundling is not as aggressive as I'd like, but by the new policies it should be fine. (Everything that upstream supports unbundling and where it actually builds unbundled is unbundled.)
16:14:05 <rdieter> polish/nice-to-have stuff can come later
16:15:10 <Kevin_Kofler> I even have one case where only Chromium upstream supports unbundling, QtWebEngine upstream is not set up for it (re2), it's a trivial patch to make that work, and we had it unbundled in 5.5.1, so I did it.
16:15:31 <Kevin_Kofler> (just one flag to pass to gyp, and to the unbundling script when I fix QtWebEngine to call it)
16:15:49 <rdieter> Kevin_Kofler: thanks for the update
16:15:59 <rdieter> moving on ...
16:16:05 <rdieter> #topic CI proposal
16:16:05 <Kevin_Kofler> Oh, and I looked at Qupzilla: 2.0.0 is not out yet, probably also because Qt 5.6.0 is not out yet either. I can look into packaging a snapshot for testing.
16:16:13 <Kevin_Kofler> But first I want the lib going.
16:16:14 <rdieter> heliocastro: ^^
16:16:17 <heliocastro> kk
16:16:23 <Kevin_Kofler> Now that should be all from the QtWebEngine front.
16:16:30 <heliocastro> So i just get some greenlight from kde-sysadmin
16:16:46 <heliocastro> and we're going to the plan kde jenkins + copr ahead
16:17:12 <heliocastro> Basically, the jenkins will deal with all commands from git
16:17:17 <heliocastro> distgit better yet
16:17:29 <heliocastro> And do the builds automatically
16:17:51 <heliocastro> The tarballs will be generated in a daily basis direct from kde servers
16:18:17 <heliocastro> and we will not touch specs unless something fials in terms of file packaging
16:18:30 <dvratil> (so all the time :-))
16:18:41 <heliocastro> What we will need is keep the copr specs up to date with the rawhide
16:18:53 <heliocastro> dvratil: Don't be so optimistic :-P
16:19:04 * Kevin_Kofler thinks that's going to be a maintenance nightmare rebasing patches, or we'll lose important patches.
16:19:14 <dvratil> that we can do since Copr can now talk to distgit
16:19:28 <heliocastro> We will not touch patches
16:19:38 <heliocastro> If a patch fail, we win
16:19:42 <Kevin_Kofler> So all the builds will fail.
16:19:46 <heliocastro> since we can detect this before release
16:19:54 <heliocastro> That's the idea of nighlty
16:20:13 <heliocastro> We detect first the issue, and on the day of release we juse
16:20:14 <heliocastro> release
16:20:30 <Kevin_Kofler> Rebasing at every release sounds much more practical to me, but then again my methods already failed to scale to the flood of tarballs we get now, so maybe you're right in the end.
16:20:35 <heliocastro> The intention *is fail*
16:21:02 <rdieter> rather, fail faster :)
16:21:16 <heliocastro> I'll be surprised ( and proud of us ) if we have minimal or none failures
16:21:22 <Kevin_Kofler> Give it a try and see it yourself. I don't have to deal with the fallout. :-p
16:21:44 <heliocastro> I'll start small with kf5 packages
16:22:04 <heliocastro> Just need sort out how to make the things work on ubuntu lxc jenkins container
16:22:17 <heliocastro> Sine we'll be using kde machines
16:22:28 <heliocastro> Why all this ?
16:22:40 <heliocastro> we will be very tied to kde project as we never were before
16:22:44 <Kevin_Kofler> Can't you put a Fedora container on the Ubuntu machines somehow?
16:23:05 <Kevin_Kofler> At least it'd put the Cloud image to some use. ;-)
16:23:17 <heliocastro> I don't know, but i don't care at this point, since the commands will be dealing with git directly
16:23:21 <rdieter> Kevin_Kofler: if I understand, there should be nothing fedora-specific going on there anyway
16:23:43 <heliocastro> no build will be done instead of copr
16:23:44 <rdieter> shouldn't matter, other than possible unfamiliarity with the environment
16:24:04 <rdieter> heliocastro: +1
16:24:14 <Kevin_Kofler> The Copr client isn't packaged for Ubuntu, is it?
16:24:22 <heliocastro> I can do that, no issue
16:24:44 <heliocastro> Bit distgit not need specifically our copr-cli
16:25:13 <heliocastro> The point is i will try avoid any excessive iteraction with sysadmin,
16:25:17 <heliocastro> not want add burden
16:25:25 <heliocastro> Just want use the service as a helper
16:25:59 <heliocastro> But that's it, a big experiment
16:26:13 <heliocastro> And i'm positive on this be working
16:26:40 <heliocastro> kf5 working, will extend to plasma and maybe Qt
16:26:43 <rdieter> heliocastro: thanks, please give periodic status reports onlist when you make any progress
16:26:50 <heliocastro> Tep
16:26:54 <heliocastro> Yep
16:27:02 <rdieter> #topic open discussion
16:27:07 <rdieter> anything else for today?
16:27:19 * heliocastro can't look to the german keyboard layout :-P
16:27:33 <jgrulich> DevConf in a month, who is coming? :)
16:27:38 <heliocastro> Ohhh
16:27:43 * heliocastro want
16:27:47 <tosky> ehm, I will be there of course
16:28:04 * Kevin_Kofler planning to come, too.
16:28:18 <jgrulich> tosky: that's obvious for Brno people :)
16:28:23 <rdieter> I'd hoped to come again, but my procrastination probably means no fedora/redhat subsidy this time
16:29:21 <rdieter> fyi for spectators, devconf is FEBRUARY 5-7
16:29:37 <heliocastro> devconf is a better idea since brussels are too military crazy for fossdem
16:29:38 <rdieter> http://www.devconf.cz/
16:30:15 <rdieter> for those going, should try to get a kdesig hackfest day or 2 again
16:30:40 <dvratil> \o/
16:30:48 <rdieter> i recall last year devconf was my first time trying plasma5
16:31:46 * heliocastro mark on calendar "ask wife if we can go and skip setup apartment" :-)
16:33:41 <rdieter> k, let's wrap meeting, we're a bit over time , thanks everyone
16:33:47 <rdieter> #endmeeting