**** BEGIN LOGGING AT Sun Jun 10 03:00:05 2018 Jun 10 06:16:18 morning Jun 10 07:12:09 Morning! Jun 10 07:26:36 mojomail almost fixed (wasn't an issue with gcc8, but newer boost), the reviews for OSE to be compatible with all Yocto releases prepared internally, lets see how long it will take to get them (or some of them) merged :) Jun 10 07:26:58 but it depends on migration of some other changes from internal build, so it might be blocked by that as well Jun 10 08:21:57 Tofe: I've integrated 2 new patches from https://github.com/Tofee/meta-webos-ports/commit/3f89630b93ee0009bc5110fd30710275471bbb85 into meta-webos-ports/master and qtwebengine(-chromium) repos, should it build now? :) Jun 10 08:32:21 will see in a bit [20/927] Jun 10 08:52:54 JaMa: my new patches lead to a link error, which isn't related to LuneOS (I think) @see above Jun 10 08:53:35 Though I realized I didn't activate the -embedded flag on my build... maybe that was the cause... Jun 10 08:53:39 I have to retry :) Jun 10 09:00:35 Ah, no, that was correct Jun 10 09:01:32 -embedded flag was removed in 5.11 IIRC Jun 10 09:02:25 yes, I just realized that; I think I just changed too much things and lost track of where I was Jun 10 09:39:03 Tofe: ok, I see this one as well Jun 10 09:42:19 Tofe: this issue exist without our luneos changes as well, I've disabled the plugins before https://github.com/shr-project/meta-webos-ports/commit/708c937faf72efbba7cc8cef8f1948f1392c3a85 Jun 10 09:45:25 JaMa: I think it would be enough to disable pepper plugins Jun 10 09:45:33 but yes, it looks like a Qt issue here Jun 10 09:46:11 I just don't know if the issue is that use_ozone is defined, or that USE_OZONE is missing Jun 10 09:50:18 Tofe: it was last updated in qtwebengine part here http://code.qt.io/cgit/qt/qtwebengine.git/diff/src/core/chromium_overrides.cpp?id=ab94349cb2fa073e8aec661a797de1cfc3819752 Jun 10 09:52:43 #if defined(USE_AURA) || defined(USE_OZONE) this looks weird Jun 10 09:53:39 ah no wait, maybe it's right, if they set "use_ozone = !USE_OZONE" Jun 10 09:53:59 so that implementation is either on Qt side of on Chromium side, but never both Jun 10 09:54:09 Then we should just pick that commit Jun 10 09:55:05 ah it's already there, ok, I misunderstood Jun 10 10:03:14 I'm checking the changes on chromium side, it was changed in 63 Jun 10 10:03:39 but looks ok on the "update to 63.*" commit Jun 10 10:04:45 are you sure that the 2nd implementation is from ozone? Jun 10 10:04:46 chromium/content/browser/renderer_host/pepper/pepper_truetype_font_list_ozone.cc:void GetFontFamilies_SlowBlocking(std::vector* font_families) { Jun 10 10:04:50 chromium/content/browser/renderer_host/pepper/pepper_truetype_font_list_pango.cc:void GetFontFamilies_SlowBlocking(std::vector* font_families) { Jun 10 10:05:06 I don't see either of these reported as enabled/disabled in log.do_configure Jun 10 10:06:09 but it was the ozone one, you're right Jun 10 10:06:10 temp/log.do_compile.1657:[14387/17902] CXX obj/content/browser/browser/pepper_truetype_font_list_ozone.o Jun 10 10:06:13 temp/log.do_compile.1657:[14391/17902] CXX obj/content/browser/browser/pepper_truetype_font_list_host.o Jun 10 10:10:35 https://chromium-review.googlesource.com/693159 Jun 10 10:13:44 I think they shouldn't have changed the #ifdef in chromium_overrides Jun 10 10:14:07 It doesn't make sense to change the logic only there Jun 10 10:18:21 /OE/build/owpb/webos-ports/tmp-glibc/work/i586-webos-linux/qtwebengine/5.11.0+gitAUTOINC+28e0320235_1785e2c1eb-r0/git/src/webengine/api/qquickwebengineview.cpp: In member function 'void QQuickWebEngineView::setDevicePixelRatio(qreal)': Jun 10 10:18:25 /OE/build/owpb/webos-ports/tmp-glibc/work/i586-webos-linux/qtwebengine/5.11.0+gitAUTOINC+28e0320235_1785e2c1eb-r0/git/src/webengine/api/qquickwebengineview.cpp:937:8: error: 'class QQuickWebEngineViewPrivate' has no member named 'setDevicePixelRatio'; did you mean 'devicePixelRatio'? Jun 10 10:19:15 more joy after dropping the 2nd implementation on ozone.cc with BUILDFLAG(ENABLE_PLUGINS) Jun 10 10:20:02 that's weird, why didn't I get that one Jun 10 10:20:42 that is from 0014-WebEngineView-re-introduce-devicePixelRatio-property.patch Jun 10 10:22:05 yes, but I've got that one too, plugins or no plugins Jun 10 10:23:25 so it built completely for you now? Jun 10 10:24:00 this is what I have for the linking issue: http://paste.ubuntu.com/p/8jTwYBxs9d/ Jun 10 10:24:16 at least as temporary hack to see what else might be broken Jun 10 10:24:58 and this is the log after http://paste.ubuntu.com/p/v7hbdQ9VPp/ Jun 10 10:25:52 well I got till the linker error, so I guessed that all the compile steps went ok Jun 10 10:26:12 for devicePixelRatio the fix will be easy it seems Jun 10 10:26:56 just replace "d->setDevicePixelRatio(devicePixelRatio);" with "d->devicePixelRatio = devicePixelRatio;" Jun 10 10:27:18 this is built only after the linker Jun 10 10:27:39 ah ok Jun 10 10:33:28 ok, build finished, let me refresh the patches and re-trigger the build Jun 10 10:35:59 I'm trying a build where I reverted the #ifdef in overrides Jun 10 10:36:10 all you need on top of current pyro should be last 2 commits in master branch Jun 10 10:36:17 ok Jun 10 10:47:53 JaMa: https://bpaste.net/show/ac1c5713e556 to fix build with plugins activated Jun 10 10:48:28 (should be in meta-qt5 I guess) Jun 10 10:48:57 ok, will replace my fix with this one Jun 10 10:49:08 My build succeeded Jun 10 10:50:00 Frankly, now my next move will be to try to move this awful PalmBridgeService code out of qtwebengine, and replace it with a JS extension Jun 10 11:02:23 ok, meta-qt5 and meta-webos-ports branches updated Jun 10 11:10:22 great Jun 10 11:58:41 JaMa: I've also done https://github.com/Tofee/luna-webappmanager/commit/70f81c35fbabb1d4edfecd83c792ec033bb2be1b it might be interesting for Qt 5.11 :) Jun 10 12:01:40 this one depends on qtwebengine, right? that would explain why I didn't get that far :) Jun 10 12:01:57 do you already have meta-webos-ports SRCREV bump ready or should I? Jun 10 12:02:54 ah, no, I didn't rebase or anything, that would mean I'd have to rebuild webengine :p Jun 10 12:03:45 and, also, that commit has to be taken separately, because it's on top of another one which depends on webos-ose Jun 10 12:04:24 (wasn't really intentional, but that's the version of luna-service2 that I had locally when coding this yesterday...) Jun 10 13:28:07 I see 3 more failing, will push SRCREV bumps once the build is finished Jun 10 13:28:20 now building webengine again for rpi Jun 10 13:36:21 lucky that at least morty build finished chromium53 a bit sooner, but still poor builder in lg has >150 load this weekend Jun 10 13:36:24 mjansa 17084 0.0 0.0 4448 648 ? S 12:52 0:00 /bin/sh /jenkins/mjansa/build-webos-ose-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/chromium53/53.0.2785.34-1-r12.10/temp/run.do_compile.16858 Jun 10 13:36:28 mjansa 43011 0.0 0.0 4448 648 ? S 11:47 0:00 /bin/sh /jenkins/mjansa/build-webos-ose-rocko/BUILD/work/raspberrypi3-webos-linux-gnueabi/chromium53/53.0.2785.34-1-r12.10/temp/run.do_compile.42410 Jun 10 13:36:32 mjansa 43731 0.0 0.0 4448 652 ? S 11:42 0:00 /bin/sh /jenkins/mjansa/build-webos-ose-sumo/BUILD/work/raspberrypi3-webos-linux-gnueabi/chromium53/53.0.2785.34-1-r12.10/temp/run.do_compile.43722 Jun 10 13:36:36 mjansa 47642 0.0 0.0 4448 652 ? S 11:48 0:00 /bin/sh /jenkins/mjansa/build-webos-ose-pyro/BUILD/work/raspberrypi3-webos-linux-gnueabi/chromium53/53.0.2785.34-1-r12.10/temp/run.do_compile.47350 Jun 10 13:37:09 busy week-end... Jun 10 13:37:36 after motivational meeting :) Jun 10 13:37:52 on my side I'm running low on space, time to rebuild from scratch I think Jun 10 13:38:14 because of sstate-cache? Jun 10 13:38:22 probably, I didn't check yet Jun 10 13:38:49 I run most builds with rm_work and clean the sstate cache with the script from oe-core (to keep only one version of everything) and it's not so heavy on disk space Jun 10 13:39:00 but I don't use ssd for this, so I have plenty of space Jun 10 13:39:10 at least at home (not so much on various builders) Jun 10 13:39:12 sstate is 24G only, so it's not the culprit here Jun 10 13:40:08 so I'll just delete tmp-glibc I guess, at least it'll be much quicker Jun 10 13:40:32 112GB sstate in my Yocto 2.6 build dir and I've cleaned it just 3 days ago :) Jun 10 13:40:53 but that's the price for living on the edge (got 3 complete rebuilds in last 3 days) Jun 10 13:41:03 ah, yes, I see :) Jun 10 13:41:20 yes, just tmp-glibc and the rebuild should finish in couple minutes Jun 10 13:41:37 do you use rm_work? Jun 10 13:42:05 nope, I otfen need to digg in tmp-glibc to hack things around Jun 10 13:42:14 understood Jun 10 13:42:49 but that's fine, I usually have only 2 builds (x86 and hammerhead) max Jun 10 13:42:51 there was also rm_work_old which was keeping only the latest version Jun 10 13:43:14 ah, that one could be interesting Jun 10 13:43:30 if you don't need e.g. WORKDIR for qtwebengine/5.9* and 5.11* at the same time Jun 10 13:43:30 163GB for tmp-glibc... yes... Jun 10 13:43:53 oh, hope I never will :) Jun 10 13:44:04 rm_work_old might need few fixes for newer oe-core Jun 10 13:44:23 because it removes old version without removing the stamps for it (like current rm_work does) Jun 10 13:44:37 ah ok Jun 10 13:44:39 so you might get strange issues if you happen to switch to the older version after using the new one Jun 10 13:44:55 just removing tmp-glibc from time to time is probably easiest and fastest option Jun 10 13:45:18 well, anyway I'll probably restart from scratch: I need to debug our OSE build to definitely fix those permission issues Jun 10 13:45:47 ok, I'll check the mesa Jun 10 13:46:26 we have too many things in parallel currently, we need to converge at some point in time :) Jun 10 13:46:40 but Qt 5.11 is back on track I think Jun 10 13:47:22 And the future of PalmBridgeService lies here I think : https://github.com/webOS-ports/luna-webappmanager/commit/66c39e39f8304090c42caf420ec5d6f73c05edd8 Jun 10 13:47:50 :) agreed and nice Jun 10 13:48:50 now with Qt 5.11 unblocked thanks to you we can get it in pyro (if it works in runtime :)) Jun 10 13:48:59 great Jun 10 13:49:18 that will remove one item from our todo and give you shared base for experiments with PalmBridgeService Jun 10 13:49:28 exactly Jun 10 13:51:00 I will trigger pyro + 5.11 build tonight, if it works I'll merge the changes to meta-qt5 master soon and then we can upgrade it in normal pyro builds Jun 10 13:51:34 ok yes Jun 10 16:56:08 Finally, Home Sweet Home. Jun 10 17:03:17 elvispre: :) Jun 10 17:59:45 * elvispre notices that the WebOS Internals site support donations links are missing / broken... (http://www.webos-internals.org/wiki/WebOS_Internals:Site_support) Jun 10 19:58:53 elvispre: I guess there was some PayPal plugin/extension to the wiki that's gone after migration, hence the tag Jun 10 20:26:29 @Tofe Okay I compiled Systemd 238 with that patch and I get the same error of the API FileSystem freezing.. just an FYI.. Jun 10 20:27:03 This error starts in Systemd 233 Jun 10 20:27:47 I tried reversing the patches for MountAPIVFS using the github commit search history, but they don't cleanly apply. I guess too many code changes have happened Jun 10 20:28:09 OrokuSaki: That's why we're on 232 still Jun 10 20:28:23 I figured that.. =) Jun 10 20:28:24 systemd guys aren't really caring about socs Jun 10 20:28:46 They just say "update your kernel" which as we know isn't possible or at least not easy at all Jun 10 20:28:53 Right Jun 10 20:28:59 There are quite some patches in Yocto to "fix" some stuff but not all Jun 10 20:29:01 Herrie: speaking about which... for the next yocto release... did they bumpd systemd ? Jun 10 20:29:24 I checked and rechecked the kernel configs.. all my namespaces are set... someone smarter then me might be able to go past 232 Jun 10 20:29:58 Rocko = 234, Sumo = 237 Jun 10 20:30:02 OrokuSaki: it's pretty hard to debug that stuff Jun 10 20:30:13 Nod Jun 10 20:30:16 There might be some kernel patches that could be applied sometimes Jun 10 20:30:20 But not easy usually Jun 10 20:30:24 Tofe did some for ours Jun 10 20:30:31 With pid namespaces etc Jun 10 20:30:38 Tofe ftw =) Jun 10 20:30:48 Let us know when you get this fixed. ;) Jun 10 20:30:56 :p Jun 10 20:31:16 OrokuSaki: You could check Yocto 234 patches: https://github.com/openembedded/openembedded-core/tree/rocko/meta/recipes-core/systemd/systemd Jun 10 20:31:21 Some might be of help (or not) Jun 10 20:31:32 We still had to apply additional patches at our side usually Jun 10 20:31:54 I did, same error Jun 10 20:32:54 For 237 there are even more patches (though most new ones seem to be for musl compatibility): https://github.com/openembedded/openembedded-core/tree/sumo/meta/recipes-core/systemd/systemd Jun 10 20:34:04 That's a lot of patches Jun 10 20:34:53 I use a kernel patch that brings back userspace firmware loading or something but that is it Jun 10 20:35:57 Well, as time goes on, systemd's requirement get more problematic w.r.t. embedded devices' kernels Jun 10 20:37:00 It's unfortunately quite probable that we'll have to delay systemd's upgrade at some point in time Jun 10 20:42:10 OrokuSaki: so, your error seems to come from here: https://github.com/systemd/systemd/blob/master/src/core/mount-setup.c#L163 Jun 10 20:43:00 which means https://github.com/systemd/systemd/blob/master/src/basic/mount-util.c#L268 fails somewhere Jun 10 20:43:26 But that's quite a wild guess. **** ENDING LOGGING AT Mon Jun 11 03:00:02 2018