**** BEGIN LOGGING AT Mon Sep 04 03:00:01 2017
Sep 04 06:28:49 <Tofe> Morning!
Sep 04 07:54:18 <Herrie|Pre3> Morning!
Sep 04 12:00:14 <Herrie|Pre3> Tofe: For the 5.9 migration: You think it makes sense to keep using pyro branch or should make it pyro-next seeing that meta-qt5 doesn't have 5.9 in pyro? I guess it's more of a JaMa question but he's not around :P
Sep 04 12:03:03 <Tofe> Herrie|Pre3: right now I want stabilization :) so if pyro-next is still "experimental", I would stick to what we know works, i.e. meta-qt5/master (+fixed SRCREV) + pyro
Sep 04 12:04:55 <Herrie|Pre3> Tofe: Well I mean for meta-webos-ports. Pyro-next doesn't exist currently so could create it
Sep 04 12:05:05 <Herrie|Pre3> Or merge to existing pyro
Sep 04 12:05:50 <Tofe> Is it problematic to keep pyro with our 5.9 patches ?
Sep 04 12:06:33 <Tofe> It's true that having pyro everywhere *should* work in theory
Sep 04 12:07:18 <Tofe> In that perspective, yes, a pyro-next or pyro-5.9 branch would make sense
Sep 04 12:07:56 <Herrie|Pre3> Tofe: No it's not... Just normally we keep the branch names in sync. I.e. our pyro = oe-core/pyro, meta-oe/pyro and meta-qt5/pyro
Sep 04 12:08:12 <Herrie|Pre3> But meta-qt5/pyro only supplies qt 5.8
Sep 04 12:08:39 <Tofe> yes, ok I understand... yes, let's go for pyro-next or pyro-5.9 then
Sep 04 12:09:03 <Herrie|Pre3> I guess I'll prepare my clean branch and from there can PR to either current pyro or pyro-5.9/next. Will wait for JaMa to show up for PR I guess
Sep 04 12:10:27 <Tofe> Herrie|Pre3: I guess that we can stick to meta-qt5/master for now, it'll be one less branch to maintain
Sep 04 12:10:48 <Herrie|Pre3> Yeah we can
Sep 04 12:11:01 <Tofe> if it's moving too much, we could consider a pyro-next here too, eventually
Sep 04 12:11:07 <Herrie|Pre3> And when they branch it off to Rocky or whatever use that instead
Sep 04 12:11:21 <Tofe> yup
Sep 04 12:11:25 <Herrie|Pre3> Since they'll normally use master for bleeding edge
Sep 04 12:11:29 <Tofe> ok, we have a plan :)
Sep 04 12:11:35 <Herrie|Pre3> OK 5.9 clean almost ready at my end
Sep 04 12:11:41 <Tofe> great
Sep 04 12:11:50 <Herrie|Pre3> Will just pr some custom branches to our master branches
Sep 04 12:12:11 <Tofe> I think I may have found why the "height" of popup enyo windows isn't correct -- might be related to the QtWayland upgrade
Sep 04 12:13:00 <Herrie|Pre3> Tofe: OK they broke it in a wrong way or solved our hackidy hack way :P
Sep 04 12:13:16 <Herrie|Pre3> I remember we were forcing some minimum heights in the past :P
Sep 04 12:13:23 <Herrie|Pre3> But that was on Chromium side
Sep 04 12:14:29 <Tofe> That's actually something else: chromium is limiting the height to the height of the screen -- and the latter is zero in our case. It's because the QtWayland output isn't configured correctly on compositor side, I think
Sep 04 12:15:54 <Tofe> I'll first try a quick fix which just forces the configuration, and then try a clener fix which makes the "default" configuration work as-is
Sep 04 12:17:50 <Herrie|Pre3> Tofe: OK. I'm working on some small QML bits here and there too :)
Sep 04 12:18:22 <Tofe> ok :)
Sep 04 13:41:06 <Herrie|Pre3> Tofe: OK I think I captured everything in herrie/qt59-clean for now. So please PR changes there.
Sep 04 13:47:44 <Tofe> ok !
Sep 04 13:48:57 <Tofe> yes, looks great
Sep 04 14:48:01 <Tofe> it would be good to try https://www.webcomponents.org/element/vguillou/swipe-action/demo/demo/index.html in our 5.9 browser
Sep 04 15:03:42 <Herrie|Pre3> Tofe: On my QtCreator on desktop it works :P
Sep 04 15:04:22 <Tofe> Herrie|Pre3: it's more to see how it's going to deal with touch
Sep 04 15:04:39 <Tofe> but it's good that it works on desktop already :)
Sep 04 15:12:18 <Herrie|Pre3> Tofe: A little sluggish on TP but works
Sep 04 15:13:59 <Herrie|Pre3> Need to test on N5 tonight
Sep 04 15:15:17 <Tofe> ok good :)
Sep 04 15:20:32 <Herrie|Pre3> I pushed the luneos-component browser UA through too.
Sep 04 15:20:37 <Herrie|Pre3> Not to forget :P
Sep 04 15:47:20 <EricBlade> some press coverage for LuneOS
Sep 04 15:47:21 <EricBlade> http://www.salon.com/2017/09/03/remember-palms-webos-maybe-not-but-apple-and-google-definitely-do/
Sep 04 15:57:12 <Herrie|Pre3> novaldex: I'll get you those php scripts over
Sep 04 15:57:29 <Herrie|Pre3> You have any idea how the Preware feeds were generated previously?
Sep 04 15:58:46 <Herrie|Pre3> Ah I think I see how
Sep 04 15:59:39 <Herrie|Pre3> Seems there is a http://github.com/webos-internals/build that's kicked off by a Jenkins job for LuneOS
Sep 04 15:59:47 <Herrie|Pre3> I guess we could do similar for legacy
Sep 04 16:00:48 <Herrie|Pre3> ka6sox: ping
Sep 04 16:12:01 <novaldex> Herrie|Pre3: thanks
Sep 04 16:12:14 <novaldex> interesting to know about the Jenkins job, does it still work?
Sep 04 16:15:05 <Herrie|Pre3> novaldex: Well LuneOS one is manual. Legacy one not sure where it runs.. ka6sox or scoutcamper might know
Sep 04 16:16:27 <novaldex> if we run into issues we could in theory replicate the LuneOS version for Legacy
Sep 04 16:18:13 <Herrie|Pre3> Well it basically runs a Makefile
Sep 04 16:40:13 <Tofe> Ok, my compositor patch fixed the height issue for the windows. but it looks like the bottom of the window is below the gesture area, it's weird
Sep 04 17:09:15 <Tofe> no, the positionning is alright, it seems it's the size which is wrong
Sep 04 17:09:21 <Tofe> it should be 30 units
Sep 04 17:09:26 <Tofe> not 25
Sep 04 17:10:08 <Tofe> here https://github.com/webOS-ports/luna-systemui/blob/webOS-ports/master/data/PowerdService.js#L212
Sep 04 17:49:07 <Herrie|2> Tofe: OK
Sep 04 17:49:22 <Herrie|2> Anyway it was always wrong either on phone or TP
Sep 04 17:50:25 <Tofe> That's unfortunate, given that the "units" metrics is there exactly to solve this issue
Sep 04 17:50:58 <Tofe> we can look at it more, but I prefer it to be too big than to be cut off
Sep 04 17:57:58 <ka6sox> Herrie|2, ping?
Sep 04 18:03:04 <Herrie|2> ka6sox: You remember how the legacy preware feeds are generated?
Sep 04 18:03:24 <Herrie|2> I.e. the ones using https://github.com/webos-internals/build
Sep 04 18:03:45 <Herrie|2> Also any thoughts on what were the 2 bugs that prevented this from getting out in the open? https://github.com/webos-internals/build/pull/28
Sep 04 18:04:16 <ka6sox> oh gosh..let me think.
Sep 04 18:04:43 <ka6sox> I know how they are generated...it would take me a little while to recreate the builder but I could.
Sep 04 18:05:20 <ka6sox> how much of this do you think would work and how much work to move to the new framework?
Sep 04 18:06:58 <Herrie|2> ka6sox: We want to bring some critical patches that are all over the various locations to a central feed
Sep 04 18:07:18 <Herrie|2> We have this for LuneOS: http://jenkins.nas-admin.org/job/luneos-preware-feeds/
Sep 04 18:08:19 <ka6sox> okay what do you need from me? (so I get the right things)
Sep 04 18:23:39 <Herrie|2> ka6sox: 1. Do legacy feeds still get generated? 2. If so where?
Sep 04 18:25:38 <Herrie|2> 3. We'd like to merge patches to: https://github.com/webos-internals/patches
Sep 04 18:25:48 <Herrie|2> 4. Generate updated feeds
Sep 04 18:27:17 <ka6sox> okay the builder got turned off...I can get it moved to someplace that we can start it up again from.
Sep 04 18:27:52 <ka6sox> then as far as merges go i ahve the ability to make that happen too...let me sort through that this week...(holiday here today)
Sep 04 18:43:54 <Herrie|TP> ka6sox: Thnx
Sep 04 18:44:19 <Herrie|TP> I guess we could move it to our regular jenkins. Setting up the job should be easy enough.
Sep 04 18:44:49 <Herrie|TP> Seems it just runs a Makefile. I can copy our LuneOS feed job and adjust the URL
Sep 04 18:45:47 <Herrie|TP> Since anyway same people are looking after legacy & LuneOS it seems. We'd just need to have some people to merge patches. I'd be happy to volunteer for that if that's OK with you & rwhitby
Sep 04 18:45:56 <Herrie|TP> Maybe together with novaldex...
Sep 04 18:46:01 <Herrie|TP> novaldex: ^
Sep 04 18:47:16 <Herrie|TP> We'd just need some more diskspace at some point @ bonaire but I think novaldex might have raised that already.
Sep 04 18:47:17 <ka6sox> yes, I'm thinking that, I just need to setup GH to be able to handle that.
Sep 04 18:47:32 <ka6sox> yes, i just spoke with him on this.
Sep 04 18:47:45 <ka6sox> you will need to run a cleanup script after each build
Sep 04 18:47:57 <Herrie|TP> We do already....
Sep 04 18:48:07 <ka6sox> but I know logs/shared states take space.
Sep 04 18:49:35 <Herrie|TP> I from my end can delete images but that only does 20GB or so each time I do it and it gradually gets less
Sep 04 18:50:09 <Herrie|TP> Problem is qtwebengine/chromium which eats a lot and it's there a number of times... for each arch...
Sep 04 19:11:26 <Herrie|2> ka6sox: Added this one quickly: http://jenkins.nas-admin.org/job/webos-preware-feeds/
Sep 04 19:11:33 <Herrie|2> Should theoretically work I guess
Sep 04 19:11:37 <Herrie|2> But we'd need to test it sometime
Sep 04 19:12:46 <ka6sox> what builder do you have that setup to work on?
Sep 04 19:15:22 <Herrie|2> Should be bonaire I guess
Sep 04 19:18:01 <Herrie> Yup Bonaire
Sep 04 19:18:49 <ka6sox> okay, I'll look at that job later today, I'm dealing with some other things here (its a BBQ day here..so I'm working on that)
Sep 04 19:40:50 <Herrie> Priorities :D
Sep 04 19:40:57 <Herrie> BBQ of course!
Sep 04 19:43:03 <Tofe> Herrie: little good news about disk space though: qtwebengine takes less space now that the main debug symbols aren't included by default
Sep 04 19:43:49 <Tofe> It means one (--> me ;) ) has to rebuild it when a tough debug pops up, but hopefully that won't happen often
Sep 04 20:31:17 <Herrie> Tofe: OK
**** ENDING LOGGING AT Tue Sep 05 03:00:00 2017