**** BEGIN LOGGING AT Sat Aug 26 03:00:02 2017
Aug 26 06:46:56 <Herrie|2> Morning!
Aug 26 06:47:25 <Herrie> Tofe: Hmmz weird: I don't really see anything obvious when comparing qt59 version and pyro version of that patch
Aug 26 06:57:50 <Tofe> Morning!
Aug 26 06:58:23 <Tofe> Herrie: there is only the gyp->gn migration, could a little mistake result in such a weird behavior ?
Aug 26 07:02:50 <Herrie> Tofe: It could be the palm service bridge?
Aug 26 07:04:35 <Herrie> That we don't fully do yet
Aug 26 07:04:49 <Herrie> I.e. where it misses the dependencies
Aug 26 07:05:37 <Herrie> Basically the part #FIXME, needs updating for GN
Aug 26 07:05:40 <Herrie> In the patch
Aug 26 07:12:35 <Tofe> Herrie: I fixed a thing or two in that patch, which were incorrect (mainly the generated .h/.pp part)
Aug 26 07:14:14 <Tofe> but that didn't change the gn error thing
Aug 26 07:21:23 <Tofe> ok so bootstrap.py, the file patched by meta-qt5, is different when we add our chromium first patch
Aug 26 07:36:04 <Tofe> the "patches/series" file in src/3rdparty, created by bitbake when computing the patches to apply, contains only our patch, not the chromium patches from meta-qt5
Aug 26 07:40:47 <Tofe> ok, I got it I think: we had "patchdir=./src/3rdparty", while meta-qt5 had "patchdir=src/3rdparty"; both point to the same directory, but bitbake thinks its two separate things, so it teats them separately. When creating the "patches/series" file for our patches, it then overwrites by mistake the one that was created for meta-qt5 in the same directory.
Aug 26 07:40:52 <Tofe> JaMa: ^
Aug 26 07:41:07 <Herrie> Tofe: That could explain
Aug 26 07:41:14 <Tofe> Herrie: I'll push my changes to my fork and propose a PR for your branch
Aug 26 07:42:40 <Herrie> Tofe: OK
Aug 26 07:45:02 <Tofe> https://github.com/webOS-ports/meta-webos-ports/pull/233
Aug 26 07:45:54 <Tofe> Now I get the "out->additionalFeatures = data.additionalFeatures();" error, and I'm going to fix that
Aug 26 07:52:13 <Herrie> Tofe: I'll cleanup my qt59 repo sometime
Aug 26 07:52:29 <Tofe> Herrie: well, the convergence isn't over yet :)
Aug 26 08:00:01 <Herrie> Tofe: I said sometime :P
Aug 26 08:00:31 <Tofe> I think I fixed that compilation error
Aug 26 08:02:42 <Herrie> :D
Aug 26 08:06:47 <Tofe> I don't know how far this will bring us, but I've sent you the patch via PR
Aug 26 08:14:46 <Herrie> OK
Aug 26 08:15:00 <Herrie> WE'll we'd need to add some webengine config bits too still
Aug 26 08:15:05 <Herrie> But that should require recompile
Aug 26 08:15:19 <Herrie> I.e. for codecs, printing, plugins, webrtc etc
Aug 26 08:15:27 <Herrie> Since it's configuration
Aug 26 08:16:29 <Herrie> Tofe: You're doing hammerhead or qemu?
Aug 26 08:20:16 <Tofe> hammerhead
Aug 26 08:33:59 <Herrie> Tofe: OK I'll do qemux86 at my end then
Aug 26 09:26:08 <Tofe> ah, almosts "lunaservice.h:21:18: fatal error: glib.h: No such file or directory"
Aug 26 09:26:20 <Tofe> maybe that's related to the missing bits in .gn
Aug 26 10:04:09 <Herrie> Tofe: likely
Aug 26 10:04:18 <Herrie> Didn't know how  to do that
Aug 26 10:04:41 <Herrie> https://chromium.googlesource.com/experimental/chromium/src/+/refs/wip/bajones/webvr/tools/gn/docs/cookbook.md
Aug 26 10:04:56 <Herrie> https://chromium.googlesource.com/chromium/src/tools/gn/+/HEAD/docs/faq.md
Aug 26 10:05:30 <Tofe> I'm looking into this
Aug 26 10:06:15 <Tofe> Herrie: it's something like https://paste2.org/4aDkmXaW, but it still doesn't find glib.h
Aug 26 10:13:57 <Tofe> ah, I think I may have found what was wrong; just a little detail
Aug 26 10:14:11 <Tofe> https://paste2.org/s5bH69Ij
Aug 26 10:24:03 <Tofe> oh no... the PalmServiceBridge V8 source code has to be adapted again...
Aug 26 12:11:03 <Herrie> Tofe: Nothing too serious I hope?
Aug 26 12:13:54 <Tofe> well, it's the "onservicecallback" attribute again: storing a callback function is very unusual with chromium code, and as time passes it's more and more tricky to do it
Aug 26 12:17:36 <Herrie> They never do callbacks in Chromium :P ?
Aug 26 12:18:31 <Tofe> They always to "myFunction(callback)"
Aug 26 12:18:36 <Tofe> do*
Aug 26 13:47:06 <Herrie> Tofe: No way to use a similar approach as Chromium so we don't need to update all time? But I guess not, otherwise you would've done it already :P
Aug 26 13:47:49 <Tofe> Herrie: not without breaking the apps
Aug 26 13:57:01 <Tofe> Herrie: https://github.com/webOS-ports/meta-webos-ports/pull/235
Aug 26 14:04:30 <Herrie> Tofe: Well taht's progress already
Aug 26 14:04:36 <Herrie> :D
Aug 26 14:13:58 <Herrie> I guess another tricky part will be luna-webappmanager
Aug 26 14:14:09 <Herrie> Due to the private headers and other headers that don't get staged
Aug 26 16:00:02 <Tofe> I've put the Qt version number in the include path too there ?
Aug 26 16:12:10 <Herrie|Pre3> Tofe: I'll play a bit with webengine config in meanwhile. ie plugins etc
Aug 26 16:18:05 <Herrie|Pre3> Since those were migrated from gyn too :P
Aug 26 16:18:21 <Herrie|Pre3> But seems straightforward
Aug 26 16:27:05 <Herrie|Pre3> Tofe: No it seems QT uses some more includes now in the private headers we use in luna-webappmanager but those don't get staged like the private headers... So no easy way to have them available to luna-webappmanager at least me & JaMa didn't see an easy w
Aug 26 16:27:05 <Herrie|Pre3> ay. JaMa wasn't too happy on the private header use in general, but I saw we aren't the only ones there
Aug 26 16:28:16 <Herrie|Pre3> I saw other projects using the private headers too
Aug 26 16:34:34 <Tofe> ah yes: "QtWebEngine/private/qquickwebenginescript_p.h:57:25: fatal error: user_script.h"
Aug 26 16:35:42 <Herrie|Pre3> Tofe: Yup
Aug 26 16:36:06 <Herrie|Pre3> So we'd need to stage these user script files somehow :P
Aug 26 16:36:48 <Herrie|Pre3> Or if we don't need them patch them out from the staged private headers
Aug 26 16:37:08 <Tofe> I'll first see if we still need that include :)
Aug 26 16:37:18 <Herrie|Pre3> Tofe: Yeah ;)
Aug 26 16:37:43 <Herrie|Pre3> I think there's a reason there were private headers that were used not only by us :P
Aug 26 16:38:01 <Herrie|Pre3> But they might have made it more public now :P
Aug 26 16:38:22 <Herrie|Pre3> Some of these bits could still date back from the webkit->webengine migration I guess in QT
Aug 26 16:38:35 <Herrie|Pre3> So they might have finally restored it :P
Aug 26 16:38:56 <Tofe> The user scripts have evolved a little bit yes - but not much though
Aug 26 16:39:47 <Tofe> ah: https://doc.qt.io/qt-5/qquickwebenginescript.html
Aug 26 16:39:59 <Tofe> public since 5.9 ;)
Aug 26 16:41:06 <Herrie|Pre3> Tofe: :)
Aug 26 16:41:23 <Tofe> it builds now
Aug 26 16:41:27 <Herrie|Pre3> :D
Aug 26 16:41:28 <Tofe> I'll PR it
Aug 26 16:43:05 <Tofe> do you have something special in your qt-5.9 branch ?
Aug 26 16:43:26 <Herrie|Pre3> Tofe: Not really I'd say
Aug 26 16:43:40 <Herrie|Pre3> Just locally a webengine patch for config that I need to push
Aug 26 16:43:53 <Herrie|Pre3> It was mainly 5.9 migration for webengine
Aug 26 16:44:13 <Herrie|Pre3> And related bits
Aug 26 16:44:15 <Tofe> ok so I'll PR from master
Aug 26 16:44:40 <Herrie|Pre3> master?
Aug 26 16:44:55 <Tofe> or should I take your branch ?
Aug 26 16:45:07 <Herrie|Pre3> Ah you mean my lunawebappmgr qt59 branch?
Aug 26 16:45:12 <Tofe> yes
Aug 26 16:45:27 <Herrie|Pre3> Don't remember check
Aug 26 16:45:30 <Herrie|Pre3> On the road now
Aug 26 16:45:35 <Tofe> ok :)
Aug 26 16:45:49 <Herrie|Pre3> But I guess 5.9 might be better because we didn't do whole migration yet
Aug 26 16:45:58 <Herrie|Pre3> And it would break 5.8 build
Aug 26 16:46:23 <Tofe> there's various tries to get the #include user_script to work
Aug 26 16:46:42 <Herrie|Pre3> Ah, just make a master-next then and pr it there
Aug 26 16:46:56 <Tofe> yup
Aug 26 16:46:56 <Herrie|Pre3> I should be home in 10-15 and can make it if you don't have access
Aug 26 16:47:10 <Tofe> I don't think I have access
Aug 26 16:47:26 <Tofe> I'll create the branch on my fork, just to have the commit somewhere
Aug 26 16:50:33 <Tofe> https://github.com/Tofee/luna-webappmanager/commit/928cea67deffaff66d0a7fa6090685bc96718910
Aug 26 16:51:11 <Tofe> now let's continue the build...
Aug 26 17:09:26 <Tofe> ...and rootfs completed
Aug 26 17:26:20 <Herrie> Tofe: We still need the other private headers?
Aug 26 17:28:28 <Herrie> Tofe: OOh nice
Aug 26 17:41:37 <Tofe> oops, I forgot to disable my halium code... well well...
Aug 26 17:42:05 <Tofe> Herrie: flawless victory!
Aug 26 17:44:16 <Tofe> well, except that enyo apps don't work
Aug 26 17:44:52 <Tofe> though it's not the error I would have expected: "LunaWebAppManager[2255]: [2255:2466:0826/194429.231536:ERROR:gl_surface_qt.cpp(661)] Requested OpenGL implementation is not supported. Implementation: 0"
Aug 26 17:50:17 <Tofe> "ERROR:surface_factory_qt.cpp(68)] eglGetProcAddress not found" ... looks familiar...
Aug 26 17:54:36 <Tofe> I propose we revert that https://github.com/qt/qtwebengine/commit/d4c621f6a6b87f2a86069fa393b9f7c4f9e7b9ad
Aug 26 17:56:58 <Tofe> I just don't want to rebuild qtwebengine :(
Aug 26 18:15:36 <Tofe> ok, yes, revert this commit did the job
Aug 26 18:15:41 <Tofe> I can start enyo apps
Aug 26 18:26:41 <Tofe> here it is https://github.com/webOS-ports/meta-webos-ports/pull/236
Aug 26 18:27:18 <Tofe> of course, we have bugs in the additionalFeatures code :) the most visible is the powermenu, which doesn't show up anymore, maybe even crashes webappmanager
Aug 26 18:53:19 <Herrie|TP> Tofe: That's not a bad start at al
Aug 26 18:53:27 <Herrie|TP> + l
Aug 26 18:53:31 <Herrie|TP> !
Aug 26 18:54:01 <Herrie|TP> Strange about the egl code by that has been problematic since 5.4 I think in one way or another...
Aug 26 18:54:26 <Herrie|TP> They patch it but never properly fix it so it works for us it seems :-P
Aug 26 20:16:43 <Tofe> Yeah I don't know what was the big issue with these hardcoded paths... anyway, it works if we revert that little change
Aug 26 20:26:06 <Herrie> Tofe: building qemu here
Aug 26 20:26:14 <Herrie> See if mouse issue is gone
Aug 26 20:44:13 <Tofe> I do hope so
**** ENDING LOGGING AT Sun Aug 27 03:00:01 2017