**** BEGIN LOGGING AT Thu Oct 31 02:59:58 2019 Oct 31 06:01:57 morning Oct 31 07:11:16 Morning Oct 31 07:11:54 JaMa: Zeus qemux86-64 built locally fails to boot something with fstab and mounting boot Oct 31 07:12:02 Will paste some logs later Oct 31 07:13:37 strange, should be identical with the unstable build from jenkins Oct 31 07:14:06 can you compare with the testing qemu build from yesterday? Oct 31 07:18:44 JaMa: Yeah it could be my pmlog stuff but that shouldn't be really Oct 31 07:18:56 Will do in about an hour Oct 31 07:24:18 Morning! Oct 31 08:24:45 JaMa: Testing 150 works for me Oct 31 08:26:06 interesting, using the same ovf for both VMs? Oct 31 08:31:29 I'd say so... I created Zeus from scratch locally yesterday after you started the builds. Only change I did locally was the 3 component recipe updates Oct 31 08:31:38 I'll compare the binaries now to see if I see anything odd Oct 31 08:49:03 JaMa: Somehow my /etc/fstab has an additional line :S https://ibb.co/p19BHbv Oct 31 08:49:09 No clue how that would get there though :S Oct 31 08:56:44 Could just be some weird glitch, since my local file in tmp-glibc doesn't have it either :S Oct 31 08:56:46 Herrie: this typically looks like a bbappend that happens stuff at the end of the file Oct 31 08:58:03 Tofe: Yeah you'd say so. I've cleaned up with tmp-glibc and will try again Oct 31 08:58:17 you can try to git grep fstab in meta-webos-ports Oct 31 09:15:43 Tofe: Nothing there really Oct 31 09:15:54 base-files but that doesn't have the duplicate entry Oct 31 09:28:15 New image is ready, let me try that instead Oct 31 09:28:21 Could be just some glitch Oct 31 09:31:59 Yup now it boots Oct 31 09:32:04 Silly glitch somewhere Oct 31 09:36:43 Just deleted tmp-glibc and rebuild the image from sstate and all seems fine :S Oct 31 09:36:45 Weird Oct 31 09:55:23 Anyway it seems the logging bits work fine, so they could be merged if JaMa is happy with the PR Oct 31 10:53:36 yeah, feel free to merge it Oct 31 10:54:19 strange, I would assume that duplicated entry in fstab shouldn't break it like this, especially for /boot partition which isn't crucial after syslinux loads the kernel Oct 31 10:54:50 Herrie: probably not the case, but did you run configure to refresh conf/bblayers.conf (to drop the backports layer)? Oct 31 10:55:12 well I guess you had to anyway as the layer doesn't exist in meta-webos-ports/zeus so it would fail even sooner than that Oct 31 10:59:12 JaMa: systemd can be pretty annoying with a slightly incorrect fstab Oct 31 11:01:15 Herrie: there was a patch for wic race condition on oe-core ML I guess that might be the reason.. you have too fast machine :) Oct 31 11:01:42 http://lists.openembedded.org/pipermail/openembedded-core/2019-October/288505.html Oct 31 11:03:39 JaMa: Well my build failed somewhere in the middle and I needed to manually cleanup and rebuild some components. Maybe that somehow broke stuff Oct 31 11:05:28 So I now removed the whole tmp-glibc and afterwards it was OK Oct 31 11:06:03 But JaMa: Above might have also been the issue ;) Oct 31 11:06:08 Just I didn't see it before Oct 31 13:28:24 5.13.2 upgrade merged in zeus-next in meta-qt5 and meta-webos-ports jansa/zeus branch updated to match that, build testing it now Oct 31 13:37:04 https://www.qt.io/blog/qt-5.13.2-released Oct 31 14:00:01 will build it in unstable once current round of testing builds is finished Oct 31 14:12:06 JaMa: Thnx Oct 31 14:12:22 5.13 looks interesting, especially the PDF viewing and HTML5 notifications in QtWebEngine Oct 31 14:46:30 Tofe: Was going through the various repos, seems GitHub API has a limit on 100 rows to return on the API call, so I was missing about 25 repos in our migration overview. You have any idea if we'd need this going forward: https://github.com/webosose/webos-wayland-extensions ? Oct 31 16:44:54 Tofe: Having an initial stab at getting wam + Chromium 72 to build on our side ;) Oct 31 16:46:46 Seems I need the webos-wayland-extensions for that ;) Oct 31 16:50:26 LOL QTWebEngine and Chromium compiling at the same time. CPU won't like that LOL Oct 31 16:59:39 OK compilation for Chormium 72 fails due to "| ../../git/src/third_party/webrtc/rtc_base/physicalsocketserver.cc:73:27: error: 'SIOCGSTAMP' was not declared in this scope; did you mean 'SIOCGARP'? Oct 31 16:59:39 " Oct 31 16:59:46 Seems too new kernel by the looks of it Oct 31 17:19:33 OK should be solvable by adding something like: https://github.com/UnitedRPMs/chromium-freeworld/blob/master/chromium-75.0.3770.80-SIOCGSTAMP.patch Oct 31 17:25:28 Testing that now Oct 31 17:31:09 Failing somewhere else now ;) Oct 31 17:31:19 Trying to figure out if it's one off or recurring, so trying again Oct 31 17:41:48 Seems consistent, checking logs Oct 31 17:44:50 https://bpaste.net/show/YZGKM Oct 31 20:38:09 Herrie: webos wayland extensions, if absent, will probably result in a bad window management Oct 31 20:38:23 but maybe nothing too critical, with a bit of luck Oct 31 20:40:27 and also, for me some things maybe shouldn't be part of an extension, like https://github.com/webosose/webos-wayland-extensions/blob/master/protocol/webos-surface-group.xml which looks like simple window management (card groups) Oct 31 20:40:52 Tofe: OK Oct 31 20:41:14 Well I added it for now, didn't pull in additional dependencies for the rest so it's fine Oct 31 20:41:29 Just not sure what to do with above error Oct 31 20:42:02 If needed we can always implement it in luna-next, at least partially; or we could test our cardshell with their compositor, too Oct 31 20:42:14 This in on 10xxx of 16xxx so it's quite a bit down the line already Oct 31 20:42:52 "No such file or directory" ... which file is it talking about Oct 31 20:43:01 could it be python? Oct 31 20:43:24 Tofe: it seems it's missing the .h Oct 31 20:43:32 I didn't find it on the path Oct 31 20:43:45 The bytecode or whatever it was called one Oct 31 20:44:17 ./bytecode_builtins_list_generator ? Oct 31 20:44:27 because maybe it's supposed to generated the .h Oct 31 20:44:31 -d Oct 31 20:46:54 Bytecode-builtins-list.h Oct 31 20:47:06 +s Oct 31 20:48:38 did you try running that command manually ? I think it's supposed to generated the header file Oct 31 21:01:59 Tofe: No I didn't let me try Oct 31 21:02:32 Please let yourself try :) Oct 31 21:14:45 Tofe: Seems I might need this one: https://chromium.googlesource.com/v8/v8/+/48924ffa0faddfa742392a993d6a2e76fe4111e9%5E%21/#F0 Oct 31 21:15:03 As per https://bugs.chromium.org/p/chromium/issues/detail?id=911183 Oct 31 21:17:13 so... it's because our python is a bit newer? Oct 31 21:21:59 Not sure Oct 31 21:22:08 I'm trying this now to see if it fixes stuff Oct 31 21:22:27 Doesn't seem to be really python related, more embedded build related from what I've read Oct 31 21:26:23 Seems to go a bit further now by the looks of it Oct 31 21:27:54 Once I got it building I'll clean it up a bit and push it, so you & JaMa can have a look. I didn't change a whole lot about LG's recipes actually Oct 31 21:28:05 And seems the 2 patches I have now are got for upstreaming as well Oct 31 21:28:18 But I suspect JaMa might have them internally as well already Oct 31 21:29:33 Nope that doesn't fix it :S Oct 31 21:34:01 Tofe: do you have a few mins to discuss some qtwebengine patches? Oct 31 21:34:08 JaMa: I'm trying to build Chromium 72 with Zeus ;) Oct 31 21:34:10 JaMa: yes, I do ! Oct 31 21:34:15 You happen to have some patches already? Oct 31 21:34:22 I have 2 so far, but still failing to build Oct 31 21:34:35 1 for Kernel 5.2 Oct 31 21:34:48 Herrie: I have internally, but it's actually a bit worse Oct 31 21:35:03 Now failing on the bytecodes-builtins-list Oct 31 21:35:27 there are issues with glibc, because webruntime-72 is missing hosts glibc with targets glibc, so it builds against target and then fails when running it against host Oct 31 21:35:41 is it something about DISOWNED? Oct 31 21:35:48 No Oct 31 21:36:07 I did this one for Kernel 5.2: https://github.com/Herrie82/chromium72/commit/17a0d3d274d2579fddb8c7a22d1ed373b041879d Oct 31 21:36:11 Tofe: see targetUrl change in https://github.com/webOS-ports/qtwebengine/commit/1c555bcba56e27a169223f7cb2fbb639795e126c Oct 31 21:36:36 Herrie: that's correct fix, there is even upstream fix for that Oct 31 21:36:45 let me show you the work arounds Oct 31 21:37:24 OK :) Oct 31 21:37:52 I tried this but no luck so far: https://github.com/Herrie82/chromium-v8/commit/189e314e3244d0d0507f83050dcac0333571b515 Oct 31 21:38:08 Tofe: it probably belongs to the first patch with additionalParams, but then it's removed again in: https://github.com/webOS-ports/qtwebengine/commit/4b175d389517789822ab3d97b0857cca61ae5fc5 anyway, so I guess we can just drop it Oct 31 21:39:04 JaMa: yes I vaguely remember targetUrl Oct 31 21:39:13 Tofe: and the original issue with screen info seems to be resolved in upstream now with: https://github.com/webOS-ports/qtwebengine/commit/ab67256fe8d9df5be95919852100f7f914ddbb81 Oct 31 21:40:11 so I plan to just drop whole https://github.com/webOS-ports/qtwebengine/commit/1c555bcba56e27a169223f7cb2fbb639795e126c and resolve targetUrl conflict Oct 31 21:40:32 JaMa: I agree, there's a good change all this is now useless Oct 31 21:40:35 chance* Oct 31 21:41:11 it's always nice to see a patch disappear :) Oct 31 21:42:23 good Oct 31 21:43:22 it's probably from my mistake rebasing this before Oct 31 21:44:08 it's actually removed in https://github.com/webOS-ports/qtwebengine/commit/4b175d389517789822ab3d97b0857cca61ae5fc5 and immediately returned in https://github.com/webOS-ports/qtwebengine/commit/1c555bcba56e27a169223f7cb2fbb639795e126c Oct 31 21:48:22 Wasn't the target URL sk Oct 31 21:48:34 Something we added? Or it came from Qt? Oct 31 21:48:47 Tofe: lets see if it still works with https://github.com/webOS-ports/meta-webos-ports/commit/70362f366a5f9cdb9a5b4f2f6b7d8d0b96f78dec Oct 31 21:49:00 we added it, but I just can't remember why exactly Oct 31 21:49:51 no, targetUrl is from upstream 93f9eed62 Oct 31 21:50:06 I suspect we needed it for for example the c+dav connector that opens the Google Auth screen? Oct 31 21:50:15 https://github.com/webOS-ports/qtwebengine/commit/93f9eed62db271ae4b8896f48df72a956f3ce7be Oct 31 21:50:19 Anyway easy enough to grep and check Oct 31 21:50:39 we've accidentally removed it from one patch and then returned it back in another patch Oct 31 21:50:50 Ah ok Oct 31 21:51:09 Let's just see then Oct 31 21:51:19 Herrie: see https://github.com/shr-project/meta-webosose/commits/zeus Oct 31 21:51:34 https://github.com/shr-project/meta-webosose/commit/7d160d702365c23e992804e6edbf83b7cfa2b908 Oct 31 21:52:08 0001-fix-build-after-y2038-changes-in-glibc.patch is the fix for sockio (the same one from meta-qt5 qtwebengine) Oct 31 21:52:27 taken from upstream webrtc Oct 31 21:53:13 the patch for optimized-compilation-info.h is just a work around, let me find what was the proper fix Oct 31 21:53:38 JaMa: ah, I see, I confused target URL with initial URL we have in qtwebengine Oct 31 21:55:03 A fix to build with jumbo (also sent to chromium68). For building with snappy we are undefining DISALLOW_COPY_AND_ASSIGN. But if jumbo puts snapshot-common.cc with other files taht use it, then the build fails. So that file should be excluded from jumbo build. Oct 31 21:57:06 JaMa: Thnx will play with those tomorrow Oct 31 22:00:33 and there is one more issue left in 72 version (maybe not in the features used by OSE), that's why I've switched to 68 in the end (where I had all the work arounds already) - I was hoping that Blink team will resolve the rest soon, but it's 6 months already.. Oct 31 22:01:16 JaMa: I' Oct 31 22:01:55 I'm planning on trying to get 72 and wam work on LuneOS to see how it works Oct 31 22:02:14 BTW with Qt 5.13 we're on 73 chromium Oct 31 22:02:21 It might be able to replace our qtwebengine patches at some point Oct 31 22:02:56 JaMa: I know, hopefully LG will move to 75 or so too ;) Oct 31 22:03:41 I'm confident the lifecycle management and bugs in LG's stack should be less v.s. our stack ;) Oct 31 22:05:02 but we'll be more depenent on LGE to provide updated webruntime in future, because our delta against upstream qtwebengine is significantly smaller than LGE's webruntime against upstream Oct 31 22:05:49 That's true Oct 31 22:05:56 but not depending on Qt from webruntime/wam is nice :) Oct 31 22:06:16 Yes Qt tends to break more v.s. fix at times Oct 31 22:06:28 well not changing much, because still webruntime depends on too many things so it gets rebuilt everytime someone farts anyway Oct 31 22:06:59 That's true, but might also better integrate with umedia etc Oct 31 22:07:41 yes, having a real good multimedia web stack is a big plus for LG's webruntime Oct 31 22:07:46 I guess trial and error. I was pleasantly surprised with WAM and our apps on a quick test on OSE Oct 31 22:08:07 Tofe: Yeah seems fairly well integrated Oct 31 22:08:19 * JaMa is not sure how well this media stack with umedia will integrate with our BSPs :) Oct 31 22:09:16 something which I'm not yet sure, is how well they manage the cameras Oct 31 22:09:41 all this umedia/audiooutputd/videooutputd is driven mostly by internal products and then it might not be so easy to use e.g. from android devices Oct 31 22:09:58 cameras are currently broken on rpi4 as well as hw media pipeline Oct 31 22:10:28 they break on rpi3 once we upgrade the kernel as well Oct 31 22:10:30 for android, we'll first need to switch to droidmedia, which integrates at the gstreamer level Oct 31 22:11:08 also for camera, gstreamer seems to be a poor solution when it comes to configuring the streams Oct 31 22:11:34 it just doesn't know how to interact with linux' media controllers Oct 31 22:12:17 (and that's why libcamera is targetted for pinephone, currently) **** ENDING LOGGING AT Fri Nov 01 03:00:13 2019