**** BEGIN LOGGING AT Mon Aug 21 03:00:02 2017
Aug 21 08:13:52 <Tofe> Morning!
Aug 21 08:14:02 <Tofe> ok, my testing is now rebuilt
Aug 21 09:21:15 <Herrie|Pre3> Morning!
Aug 21 09:21:21 <Herrie|Pre3> Tofe: Good to hear
Aug 21 09:21:58 <Herrie|Pre3> I still had some issues with JaMa's latest meta-qt5 and webengine so trying various things. But as you know that takes time :P
Aug 21 09:22:41 <Herrie|Pre3> it again stopped building with weird errors which seemed toolchain related so I'm reverting back to what worked for me yesterday and add bits back in where needed
Aug 21 09:23:28 <Tofe> Herrie|Pre3: I just heard that Nemo (based on Mer) will soon use OE+Halium, and that they are already using Qt 5.9; I'm a bit surprised, so I'm investigating :)
Aug 21 09:24:50 <Herrie|Pre3> Tofe: Well that's nice progress at their end :)
Aug 21 09:25:07 <Herrie|Pre3> Surprised by the OE switch (not so much Halium)
Aug 21 09:25:30 <bshah> Tofe: well using as in not functional yet btw :P
Aug 21 09:25:38 <bshah> (qt 5.9)
Aug 21 09:27:19 <JaMa> Herrie|Pre3: I've finished building it with upstream layers, now building LuneOS for qemux86 with your changes for meta-webos-ports
Aug 21 09:28:10 <Tofe> bshah: ah, ok, yes that makes more sense -- and I'm very glad OE is being used by another phone-related project, we'll be able to share progress here and there
Aug 21 09:29:28 <JaMa> Herrie|Pre3: and you probably don't need this with Pyro, but for Rocko I had to add "qtwebengine: fix build with glibc-2.26"
Aug 21 09:29:48 <bshah> Tofe: the issue we are currently having is lipstick or minimer rendering nothing on screen
Aug 21 09:29:59 <bshah> they "run" but nothing on screen
Aug 21 09:30:39 <bshah> otherwise test_hwcomposer already work
Aug 21 09:31:49 <Tofe> bshah: the compositor has been migrated to the newest QtWayland, right ? Maybe the problem is there ?
Aug 21 09:32:04 <bshah> I am not sure about that..
Aug 21 09:32:07 <bshah> sorry :p
Aug 21 09:32:22 <Herrie|Pre3> JaMa: I was getting "strip: unable to recognise the format of the input file" at one try and "gcc: error: unrecognized command line option '-mflooat-abi=hard' with another try
Aug 21 09:32:25 <Tofe> bshah: where can I find the sources for lipstick or minimer ?
Aug 21 09:32:53 <Herrie|Pre3> Both after cleansstate without your latest commit it seems. Could be I just need to rebuild who qt again :P
Aug 21 09:33:03 <bshah> Tofe: IIRC, locusf is using the OE recpie from astroidos
Aug 21 09:33:13 <Tofe> ok
Aug 21 09:33:24 <JaMa> Herrie|Pre3: ok, that's arm specific I won't see it on qemux86 build
Aug 21 09:33:40 <JaMa> it might be issue in that gn patch for selecting host compiler
Aug 21 09:33:55 <JaMa> maybe it's passing -mflooat-abi=hard from target arm build in host x86_64 build
Aug 21 09:34:21 <JaMa> maybe the patch from qt fork was modified _after_ I included it in meta-qt5
Aug 21 09:35:51 <Herrie|Pre3> JaMa: I stripped all the meta-qt5 patches now and only using the 3 upstream ones. That worked yesterday. If that works I'll start adding yours back 1 by 1 I guess
Aug 21 09:37:39 <JaMa> Herrie|Pre3: yes http://code.qt.io/cgit/yocto/meta-qt5.git/diff/recipes-qt/qt5/qtwebengine/0001-Force-host-toolchain-configuration.patch looks a bit different than https://github.com/meta-qt5/qtwebengine-chromium/commit/b1a6f73d49a340e99145a4c4cf70dc796ed632ff + https://github.com/meta-qt5/qtwebengine/commit/5106be504b7edb7bc75309d581dfd33a89ed04fc
Aug 21 09:39:02 <Herrie|Pre3> Just my webengine compiles take forever...
Aug 21 09:39:07 <Herrie|Pre3> Any way to speed that up?
Aug 21 09:39:15 <bshah> s/my/everyones/
Aug 21 09:39:26 <JaMa> nope, takes forever here as well
Aug 21 09:39:37 <JaMa> it's a bit faster on huge icecc farm
Aug 21 09:39:53 <JaMa> "only a bit faster"
Aug 21 09:40:09 <Herrie|Pre3> JaMa: OK.... Already got the parallel make on 5 and bb_number_threads on 12. Helps for rest of build but not for webengine :P
Aug 21 09:40:31 <JaMa> I use bb_number_threads = 2
Aug 21 09:40:48 <JaMa> I doubt that 12 helps a lot, how many cpu cores you have?
Aug 21 09:41:30 <nizovn> in my experience most of qtwebengine time takes linkage, which is single thread
Aug 21 09:41:57 <Herrie|Pre3> 6 cores
Aug 21 09:42:03 <JaMa> not most of it, it takes long (especially if you don't have a lot of ram or don't use gold)
Aug 21 09:42:07 <Herrie|Pre3> AMD Phenom II X6 1055
Aug 21 09:42:19 <Herrie|Pre3> I have 16gb
Aug 21 09:42:21 <JaMa> but it's still only few % of the overall time (at least here)
Aug 21 09:42:25 <Herrie|Pre3> Use gold ?
Aug 21 09:42:34 <JaMa> gold linker instead of bfd
Aug 21 09:42:57 <Herrie|Pre3> Ah wait 8gb I have in builder
Aug 21 09:43:08 <Herrie|Pre3> It's miniITX so uses SO-DIMM
Aug 21 09:43:10 <JaMa> Herrie|Pre3: but you do use gold :)
Aug 21 09:43:11 <JaMa> meta-luneos/conf/distro/include/luneos-features.inc:WEBOS_DISTRO_FEATURES_LD = "ld-is-gold"
Aug 21 09:43:21 <Herrie|Pre3> Largest it would accept is 2 * 4GB
Aug 21 09:43:36 <JaMa> Herrie|Pre3: I would use 7 for parallel make and 2 for bb threads
Aug 21 09:44:05 <JaMa> Herrie|Pre3: with your 5 and 12 you can in theory get 60 gcc processes at the same time, when 12 do_compile tasks run in paralel
Aug 21 09:44:21 <JaMa> which is terrible for your system and you will also probably run from swap at that time
Aug 21 09:44:36 <Herrie|Pre3> Ok will change that :P
Aug 21 09:44:55 <JaMa> with 7 and 2, you'll get more gcc processes for qtwebengine and less distractions from the rest of recipe while building it
Aug 21 09:45:08 <JaMa> s/recipe/recipes/g
Aug 21 09:45:53 <JaMa> more bitbake threads usually means also a lot of IO (like package tasks) running in paralell to other recipes building)
Aug 21 09:46:41 <Herrie|Pre3> JaMa: Well they usually all finish anyway and wait for webengine to finish
Aug 21 09:47:34 <Herrie|Pre3> JaMa: I use standard luneos-features.inc so must be using gold
Aug 21 09:47:49 <Herrie|Pre3> All is on 500GB SSD so should fly theoretically :P
Aug 21 09:47:58 <Herrie|Pre3> But CPU is quite old already
Aug 21 09:48:13 <Herrie|Pre3> Might upgrade to some nice Threadripper in the future :P
Aug 21 09:48:53 <JaMa> Herrie|Pre3: they will pretty much finish anyway even with just 2 bitbake threads as well :)
Aug 21 09:49:07 <JaMa> Herrie|Pre3: yes Epyc is nice :)
Aug 21 09:49:24 <JaMa> it doesn't fly even when builing in ram :)
Aug 21 09:58:06 <JaMa> Herrie|Pre3: I've pushed one more change to jansa/master-5.9-rebase which _might_ fix the issue you were seeing, but no promisses
Aug 21 09:58:20 <JaMa> it's just refresh of that patch from qt.io
Aug 21 09:58:59 <Herrie|Pre3> JaMa: OK will try that when this build finishes
Aug 21 10:02:22 <nizovn> mflooat-abi looks like a typo somewhere
Aug 21 10:05:13 <Herrie|Pre3> nizovn: That's me fat fingering should be mfloat :P
Aug 21 10:05:24 <nizovn> ah ok :)
Aug 21 10:10:45 <JaMa> Herrie|Pre3: do you have newer wip/qt59 branch somewhere?
Aug 21 10:10:47 <JaMa> Patch 0003-QWaylandWindow-reset-window-should-reset-mask.patch does not apply (enforce with -f)
Aug 21 10:10:50 <JaMa> ERROR: qtwayland-5.9.2+gitAUTOINC+7f70da6a64-r0 do_patch: Function failed: patch_do_patch
Aug 21 10:11:31 <JaMa> err not wip/qt59, but herrie/qt59
Aug 21 10:14:33 <Herrie|Pre3> JaMa: Ah I removed that one locally to get it to build
Aug 21 10:14:37 <Herrie|Pre3> But didn't push it yet
Aug 21 10:14:45 <Herrie|Pre3> Let me do that in a minute
Aug 21 10:20:11 <Herrie|Pre3> JaMa: Done
Aug 21 10:21:39 <Tofe> Herrie|Pre3: yup, we need that patch :)
Aug 21 10:22:38 <Tofe> In general, on our side, for Qt 5.9, we should have the exact same number of patches for the recipes
Aug 21 10:25:51 <Herrie|Pre3> Tofe: They did something in qtwayland for which I'm not sure it does the same as yours
Aug 21 10:25:59 <Herrie|Pre3> Updating the patch is easy in general :P
Aug 21 10:26:09 <Tofe> Herrie|Pre3: I can have a look
Aug 21 10:27:25 <Herrie|Pre3> They added a mFrameCallback = nullptr
Aug 21 10:28:14 <Tofe> Herrie|Pre3: that's good, but it doesn't fix the mask unfortunately
Aug 21 10:29:35 <Herrie|Pre3> Tofe: OK I'll update the patch
Aug 21 10:29:42 <Tofe> I should propose our patch upstream, when I have a minute
Aug 21 10:33:18 <Tofe> JaMa: does it really make sense to separate qml and C++ in qtquickcontrols2 in meta-qt5 ? It's more prone to mistakes than helping, I think
Aug 21 10:33:54 <Tofe> (but maybe it's too late to change it now...)
Aug 21 10:36:35 <Herrie|Pre3> Tofe: Can you have a look at the keyboard focus patch? They did some bits there as well that might solve it but not sure
Aug 21 10:37:08 <Tofe> Herrie|Pre3: yup
Aug 21 10:37:43 <Herrie|Pre3> JaMa: Patch is updated and back
Aug 21 10:40:15 <Tofe> Herrie|Pre3: yes, they fixed it another way, we can drop this patch
Aug 21 10:43:55 <Herrie|Pre3> Tofe: OK
Aug 21 10:51:13 <JaMa> Tofe: you mean for the packaging? maybe we can let one of them rrecommend the other, but as you say it's probably a bit late as the same packaging rules are shared for all qt5 components not just qtquickcontrols2
Aug 21 10:51:23 <JaMa> Herrie|Pre3: ok thsnks
Aug 21 10:51:25 <JaMa> thanks even
Aug 21 10:52:10 <Tofe> JaMa: yes, it was just about the packaging. I understand it's a common rule, though.
Aug 21 10:53:42 <Tofe> Herrie|Pre3: https://bugreports.qt.io/browse/QTBUG-62638 we'll see
Aug 21 10:56:53 <Herrie|Pre3> Tofe: Thnx
Aug 21 13:09:02 <Herrie|Pre3> JaMa: I get warnings on qtsensors license files with latest meta-qt5
Aug 21 13:09:08 <Herrie|Pre3> I.e. cannot copy
Aug 21 13:10:51 <Herrie|Pre3> Should be solved when you pick the licenses bit from upstream recipe by looks of it.
Aug 21 13:22:15 <JaMa> Herrie|Pre3: which branch?
Aug 21 13:22:38 <Herrie|Pre3> your rebase one
Aug 21 13:22:46 <Herrie|Pre3> Upstream 5.9
Aug 21 13:23:41 <JaMa> strange
Aug 21 13:23:44 <JaMa> it built here fine
Aug 21 13:23:46 <Herrie|Pre3> And your webengine needs the patch to fix the long filenames
Aug 21 13:23:55 <Herrie|Pre3> JaMa: It builds but gives warning
Aug 21 13:23:56 <JaMa> I've updated them in 3 other recipes
Aug 21 13:23:58 <Herrie|Pre3> So cosmetics
Aug 21 13:24:07 <JaMa> aha 3 other failed
Aug 21 13:24:10 <Herrie|Pre3> Yeah
Aug 21 13:24:51 <JaMa> did the update help with the -mfloat-abi issue?
Aug 21 13:26:10 <Herrie|Pre3> JaMa: It fails now because of the missing 0001-chromium-workaround-for-too-long-.rps-file-name.patch since I'm getting "File name too long" :P
Aug 21 13:28:55 <JaMa> ok, will look into it later (my paths are shorter), but no gtg
Aug 21 13:29:19 <Herrie|Pre3> JaMa: OK I added it locally and will rebuild shortly
Aug 21 16:13:28 <Herrie|Pre3> OK webengine finished building OK
Aug 21 17:52:21 <Tofe> Herrie: my 3 PRs (first use, luneos-components and browser) should be ok to merge now
Aug 21 18:06:49 <Tofe> Herrie|TP: if I want to tackle the qemux86 issues we currently have, is the build of august 5th sufficient?
Aug 21 18:07:10 <Herrie|TP> Tofe: Yeah should be
Aug 21 18:07:18 <Tofe> ok good
Aug 21 18:07:29 <Herrie|TP> Problem is you cannot ssh in and also mouse input seems broken.
Aug 21 18:07:58 <Herrie|TP> I saw some commits in qt that might suggest this has been fixed in 5.9 but haven't build to confirm yet
Aug 21 18:08:36 <Herrie|TP> Should be able to do that shortly though
Aug 21 18:08:53 <Tofe> ah, ok
Aug 21 18:10:28 <Herrie|TP> I haven't been able to test 5.9 image yet on Hammerhead. Even without our patches for webengine I should be able to start qml like firstuse right?
Aug 21 18:10:52 <Herrie|TP> webappmgr might crash I guess and of course our Enyo apps won't work
Aug 21 18:10:58 <Tofe> I think so, but the last page of firstuse uses a LunaWebEngineView
Aug 21 18:12:01 <Tofe> ah, you just mean unpatched, not "unbuild"
Aug 21 18:12:12 <Tofe> so yes, firstuse should work
Aug 21 18:12:43 <Herrie|TP> Tofe: OK. Little one taking bath now will try afterwards
Aug 21 18:12:44 <Tofe> Herrie|TP: do you need help with the patching of webengine?
Aug 21 18:13:22 <Herrie|TP> Getting our patches to work should be easy. All were updated so just need to do gyp-> gn
Aug 21 18:13:30 <Tofe> ok good :)
Aug 21 18:13:51 <Herrie|TP> Tofe yeah Chromium patch 2 is the gyp->gn stuff I think
Aug 21 18:13:56 <Herrie|TP> Rest is done
Aug 21 18:14:31 <Tofe> ok; I can also test a build on N5 at home when that's ready.
Aug 21 18:15:25 <Herrie|TP> You might want to double check webengine patches. They added some url, I did what I thought was logical
Aug 21 18:15:47 <Tofe> Is the current work pushed on GH ?
Aug 21 18:16:29 <Herrie|TP> yeah herrie/qt59 branch in meta-webos-ports
Aug 21 18:16:39 <Herrie|TP> It needs cleanup but builds
Aug 21 18:17:04 <Tofe> ok, I'll have a look at these patches
Aug 21 18:18:29 <Herrie|TP> I disabled them in our bbappend but should work. Was to avoid our patches were causing 5.9 build issues. They should patch OK. Just need to verify them with latest bleeding edge commits from upstream but don't think anything changed in files we're patchin
Aug 21 18:18:29 <Herrie|TP> g recently
Aug 21 18:21:09 <Herrie|TP> Tofe: Also luna-next headers like this are nasty, hardcoding version..
Aug 21 18:28:41 <Tofe> Herrie|TP: yeah, I'll see if we can shorten the path to exclude the version number
Aug 21 18:31:09 <Tofe> Herrie|TP: your modifications look good to me, but the real test will be on device of course :)
Aug 21 18:32:07 <Tofe> Herrie|TP: at some point it might be good to merge/squash some of the commits to have a log that is a bit more easier to understand
Aug 21 18:39:20 <Herrie> Tofe: Yeah like I said this is WIP
Aug 21 18:39:25 <Tofe> :)
Aug 21 18:39:27 <Herrie> Will clean up before PR-ing
Aug 21 18:39:35 <Herrie> Just pushing stuff as I see it :P
Aug 21 18:39:42 <Herrie> No cleaning up whatsoever
Aug 21 20:12:27 <Herrie> Tofe: I kicked off a new nightly with your changes
Aug 21 20:56:38 <Tofe> thanks
Aug 21 21:09:20 <Tofe> Herrie: https://github.com/webOS-ports/luna-next/pull/135 ;)
**** ENDING LOGGING AT Tue Aug 22 03:00:00 2017