**** BEGIN LOGGING AT Fri Nov 08 02:59:57 2019 Nov 08 07:18:22 Morning Nov 08 07:28:06 Morning! Nov 08 08:15:39 Tofe: Got my first build with WAM and Chromium 68 for qemux86 ready, will test it shortly ;) Nov 08 08:18:40 Herrie|2: it's still very likely that there will be a hidden dependency on their wayland extensions Nov 08 08:19:07 but I'm curious as to how far it'll work Nov 08 08:19:41 Tofe: Well I added what was required for build Nov 08 08:23:00 Nothing launches it seems ;) Nov 08 08:23:04 Which was expected I guess Nov 08 08:23:06 Will check some logs Nov 08 08:25:26 Herrie|2: a wayland extension is a runtime dependency, in the sense that it's optional at both sides Nov 08 08:25:44 "Nov 08 08:22:42 qemux86 LunaAppManager[438]: WebAppManager is not connected so can't launch app org.webosports.app.memos" Nov 08 08:25:49 Will look into that one Nov 08 08:26:15 I changed luna-webappmanager to wam for the webapps but I guess I might need to update it elsewhere too Nov 08 08:34:58 Ah I guess stuff like this in luna-appmanager: https://github.com/webOS-ports/luna-appmanager/blob/aea3f868785cf595b66b2e350d6f6fe7d3f38576/Src/remote/WebAppMgrProxy.cpp#L86 Nov 08 08:35:24 yes, exactly what I was looking at Nov 08 08:42:49 Simply replacing it by com.palm.webappmanager should work mostly I'd say: https://github.com/webosose/wam/blob/master/files/sysbus/com.palm.webappmanager.api.json Nov 08 08:44:38 it's worth a try. And we can try both in our appmanager, for the moment, to simplify the switch Nov 08 08:45:32 There are a few API's that don't exist (anymore): relaunch, launchUrl, registerForAppEvents, clearMemoryCaches Nov 08 08:45:40 But those shouldn't be critical to start with at least Nov 08 08:45:49 relaunch we'll need for sure at soem point Nov 08 08:46:08 Tofe: Well I can just make a new branch to test for now Nov 08 08:46:21 Where I simply switch them Nov 08 08:46:34 ok, yes Nov 08 08:46:54 Just for quick testing to see where we end up Nov 08 08:53:59 Seems relaunch is still there, just not exposed in API file: https://github.com/webosose/wam/blob/43f946af06483848bcb2795bb8dbfa02d64c02f4/src/core/WebAppBase.cpp#L235 Nov 08 08:58:53 Most others not, but not sure if we use them and how critical they are Nov 08 08:59:49 I'll grep around the legacy webOS doctors to see where they're used Nov 08 09:04:17 registerForAppEvents only seems to be in our luna-webappmanager and luna-appmanager. It wasn't in OWO or legacy. Nov 08 09:05:36 registerForAppEvents: https://github.com/search?q=org%3AwebOS-ports+registerForAppEvents&type=Code Nov 08 09:07:57 launchUrl was in OWO it seems (https://github.com/search?q=org%3Aopenwebos+launchUrl&type=Code), but mostly removed from OSE (just some comments left in https://github.com/webosose/wam/blob/99aace816fa9bc659ae7ea5f8f4b27722b7a9c43/src/webos/PalmServiceBase.h#L129), should be easy enough to add back. Nov 08 09:13:20 Hmmz seems that doesn't do the trick yet :S Nov 08 09:13:30 launchUrl might be used from JustType ? Nov 08 09:13:32 Maybe I'm missing some systemd service file or something Nov 08 09:13:43 Will have a look in OSE image how they launch WAM Nov 08 09:25:34 Tofe: Ah I guess this is the culprit: https://github.com/webosose/wam/blob/master/files/launch/systemd/webapp-mgr.service#L22 Nov 08 09:31:31 ah yes, of course :) Nov 08 09:35:33 JaMa: o/ Nov 08 09:47:31 JaMa: Morning! Nov 08 09:54:23 Seems somehow my /usr/bin/WebAppManager binary didn't get build and deployed Nov 08 09:54:43 morning Nov 08 09:55:17 that's strange, did do_install fail or did you notice only in the image after installing it? Nov 08 09:55:44 JaMa: My image builds successfully so that's weird Nov 08 10:01:11 JaMa: Seems it's not compiling anything for some reason... I guess I might have removed an inherit too much somewhere Nov 08 10:03:17 It's seems the inherit webos_qmake5 Nov 08 10:05:06 Seems we didn't need it before for other components, so I didn't add it Nov 08 10:14:14 ah so it fails only with the OSE recipe for wam ? Nov 08 10:15:48 JaMa: Yeah, well I stripped all the unneeded inherits that you said we didn't need before ;) Nov 08 10:16:09 But seems I tried a bit to hard and also removed the inherit webos_qmake5 ;) Nov 08 10:25:30 Ah seems that it requires MACHINE_NAME which requires webos_machine_dep again :S Nov 08 10:26:11 WAM gives me " Project ERROR: MACHINE_NAME should not be empty." Nov 08 10:26:14 we shouldn't use MACHINE_NAME in LuneOS in wam nor in webruntime Nov 08 10:26:31 yes, it should be fixed in wam itself Nov 08 10:26:48 otherwise everything depending on them will be MACHINE_ARCH again Nov 08 10:27:00 Which seems to come from https://github.com/shr-project/meta-webosose/blob/master/meta-webos/classes/webos_qmake5.bbclass#L57 Nov 08 10:27:18 JaMa: Ah OK Nov 08 10:27:33 Let me see how to fix that in WAM, anyway needed to fork it for changing the systemd file Nov 08 10:46:09 JaMa: when you'll have a few minutes I've made a little PR for meta-smartphone that fixes rosy on zeus branch Nov 08 10:54:15 JaMa: I'm getting https://paste.ubuntu.com/p/KQ9SH2hCxY/ which is weird, because this is due to json.h from luna-prefs which should have been addressed by https://github.com/webOS-ports/luna-prefs/commit/620394a1c4bd5b0c0ec0a7ee15aa5e8aa8c6d957 Nov 08 10:54:18 So not sure what's up there Nov 08 10:58:29 Herrie|2: my guess it that wam doesn't use pkg-config to find luna-prefs Nov 08 10:58:44 Tofe: will merge it today Nov 08 11:00:31 JaMa: Ah that might be true Nov 08 11:02:24 Yup seems our LuneOS wam has "inherit pkgconfig" but OSE one not ;) Nov 08 11:04:20 JaMa: Alternatively adding JSON-C to depends should solve this, no? Nov 08 11:06:38 Herrie|2: to DEPENDS? no, you need the build to add correct -I flag from json-c (/usr/include/json-c) Nov 08 11:16:10 JaMa: This seems to solve it: https://github.com/webOS-ports/wam/commit/bb66a1c8763ca3665499027f27de19adfe0f51b9 Is that the correct way to do it? Nov 08 12:28:24 OK seems I got WebAppMgr to build now finally.. Needed a few hacks it seems Nov 08 12:49:52 Herrie|2: it should be luna-prefs not json-c, both should work but if json-c is needed only by luna-prefs .. Nov 08 12:51:54 JaMa: luna-prefs has it in it's pkgconfig, but wam doesn't seem to take that into account Nov 08 12:52:29 And it picks up luna-prefs itself anyway already since it's in DEPENDS and it has no problem finding luna-prefs it seems, just the json-c include that luna-prefs needs Nov 08 12:52:52 But I'm no expert in anything C(++), so it's mainly trial & error at my side and usually not knowing what I'm doing ;) Nov 08 12:54:09 lunaprefs probably doesn't need explicit -I flags to find lunaprefs.h (that's why DEPENDS is enough for it), my guess is that your build didn't include neither device.pri nor emulator.pri (where luna-prefs is added to PKGCONFIG) Nov 08 12:54:31 JaMa: Seems so, because I also had issues with PmLogLib Nov 08 12:54:35 Which is in device.pri Nov 08 12:54:38 wam/1.0.1-25-r31/git$ git grep luna-prefs Nov 08 12:54:39 device.pri:PKGCONFIG += luna-prefs PmLogLib Nov 08 12:55:01 and device.pri is loaded from common.pri only for some MACHINEs Nov 08 12:55:30 when PLATFORM is set to PLATFORM_WEBOS Nov 08 12:55:59 I did a grep for PLATFORM_WEBOS in meta-webosose and didn't find anything Nov 08 12:56:24 Only reference in OSE GitHub is to https://github.com/search?q=org%3Awebosose+PLATFORM_WEBOS&type=Code Nov 08 12:56:29 Which is this line of code Nov 08 12:56:59 am.bb:EXTRA_QMAKEVARS_PRE += "PLATFORM=${@'PLATFORM_' + '${DISTRO}'.upper().replace('-', '_')}" Nov 08 12:57:44 Ah OK, I see that one now too :S Nov 08 12:58:02 so you need to pass PLATFORM_WEBOS instead of PLATFORM_LUNEOS Nov 08 12:58:18 I told you that LGE is a mess :) Nov 08 12:58:32 JaMa: Or just always include it ;) Nov 08 12:59:06 I cannot think of use cases where we wouldn't need it anyway? Nov 08 12:59:22 there used to be also emulator.pri included for qemu* machines, but now it probably doesn't make much sense Nov 08 12:59:54 and we don't want to make it MACHINE_ARCH anyway, so including it always might be easiest way forward (and resolve possible issues later) Nov 08 13:00:17 Yeah, because we might rely on DISTRO_LUNEOS elsewhere for things.... Nov 08 13:00:18 Herrie|2: your first PR for chromium ! ;) Nov 08 13:00:35 Tofe: huh? Nov 08 13:00:45 I don't have any Chromium PR's pending I think :P Nov 08 13:01:24 did I misunderstand what you're working on ? "and device.pri is loaded from common.pri only for some MACHINEs when PLATFORM is set to PLATFORM_WEBOS" Nov 08 13:01:42 Herrie|2: well not yet Nov 08 13:01:58 Tofe: Well it's WAM, not Chromium ;) Nov 08 13:02:15 ah, yes, well, details... ;) Nov 08 13:02:41 JaMa: Seems emulator.pri is gone, at least in OSE Nov 08 13:03:24 Indeed used to be there in OWO: https://github.com/openwebos/webappmanager/blob/master/emulator.pri Nov 08 13:04:49 This is what used to be in OWO: https://github.com/openwebos/webappmanager/blob/master/webappmgr.pro#L157 Nov 08 13:04:55 We don't need any of that anymore it seems ;) Nov 08 13:18:58 yes, emulator.pri is still in internal wam where I was looking at first :) Nov 08 13:26:15 Ah ok Nov 08 13:36:01 JaMa: Weird that they didn't push it out for OSE then since there's an emulator there as well ;) Nov 08 13:36:27 OK getting a bit closer with WAM, needed to add the base-passwd bits Nov 08 13:36:33 Now it's just hard crashing LOL Nov 08 13:47:16 Assert failed with reference to: https://github.com/webOS-ports/wam/blob/herrie/LuneOS/src/Main.cpp#L100 Nov 08 13:47:40 progress! Nov 08 13:47:52 Yeah, issue now seems to be permissions: Nov 8 13:33:48 qemux86 user.err ls-hubd: [] [pmlog] ls-hubd LSHUB_NO_ROLE_FILE {"EXE":"/usr/bin/WebAppMgr"} No role file for executable: "/usr/bin/WebAppMgr" (cmdline: /usr/bin/WebAppMgr --accelerated-plugin-rendering-blacklist=device;drmAgent;sound;service --applica Nov 08 13:48:04 Which should be easy enough to check & fix Nov 08 13:56:54 JaMa: The WAM .bb has a syntax error, my editor doesn't like it ;) Nov 08 13:57:57 https://ibb.co/Jrs9xgX Nov 08 13:58:13 Somewhere in the sed the escaping seems to go AWOL Nov 08 13:59:30 I'd blame the editor, here Nov 08 13:59:44 \" doesn't seem to be understood Nov 08 14:00:23 Tofe: Well there's \" and \' which I think causes it Nov 08 14:01:18 it's a tricky line, yes; but the line looks correct Nov 08 14:07:19 Well maybe it's my Kate editor after all ;) Nov 08 14:15:30 Not sure why the wam.bb doesn't install the role files... Will first trial & error by manually pushing them to emulator to see if I get any further Nov 08 14:29:27 Tofe: I guess this is what we were expecting? https://paste.ubuntu.com/p/VdqMspp4QG/ Nov 08 14:30:54 export XDG_RUNTIME_DIR=/tmp/luna-session Nov 08 14:31:13 that'll help :) Nov 08 14:32:27 Not a whole lot though: https://paste.ubuntu.com/p/PGnkpT7KbG/ Nov 08 14:32:48 danm Nov 08 14:33:23 let me have a quick look at that display.cc... Nov 08 14:35:04 we're here it seems Nov 08 14:35:05 https://github.com/webosose/chromium68/blob/8be02722c9d38cb42b85a9f94979f93924c1d753/src/ozone/wayland/display.cc#L240 Nov 08 14:37:06 Tofe: Yeah, well the .sh that starts WAM is pretty large... I'm running through it to make sure all paths etc exist as well: https://github.com/webOS-ports/wam/blob/herrie/LuneOS/files/launch/systemd/webapp-mgr.sh.in Nov 08 14:38:59 Herrie|2: can you try "export WAYLAND_DEBUG=client" ? it'll be verbose, but it should crash soon enough Nov 08 14:39:54 Seems the same: https://paste.ubuntu.com/p/zkMMFHsMpJ/ Nov 08 14:40:29 it's a bit weird, were is the output gone ? :) Nov 08 14:43:31 ooh maybe they statically linked chromium with their own wayland lib... Nov 08 14:44:50 even so, it seems it is the same implementation Nov 08 14:45:06 ok, well, luna-next is alive and kicking? Nov 08 14:45:41 is /tmp/luna-session the correct folder ? I might have made a type Nov 08 14:45:43 typo Nov 08 14:46:47 yes, seems correct. Ok, now I begin to fail to see what's wrong here Nov 08 14:47:34 Tofe: Yeah I get cardshell & all Nov 08 14:47:50 Firstuse now as well after I fixed the LS2 permission bits Nov 08 14:47:59 Still have some things in log that should be addressed though Nov 08 14:48:09 you do have a /tmp/luna-session/wayland-0 socket file ? Nov 08 14:50:41 Yeah but it's 0 bytes Nov 08 14:50:57 that's fine, it's a socket Nov 08 14:51:58 I mean I have these in my logs: https://paste.ubuntu.com/p/GWpPCHdzc4/ Nov 08 14:53:23 nothing from wam, it seems Nov 08 14:53:57 Herrie|2: how are you feeling about inserting traces inside wam ? :p Nov 08 14:55:26 Tofe: Happy to try if you give me guidance ;) Nov 08 14:55:49 let's insert " LOG(ERROR) << "DEBUUUUG"; " here: https://github.com/webosose/chromium68/blob/master/src/ozone/wayland/display.cc lines 318, 327, 332 Nov 08 14:56:42 then it's about doing bb -f -c compile webapp-mgr && bb webapp-mgr Nov 08 14:56:57 you can directly modify the tmp-work content Nov 08 14:57:16 the rebuild should be quick Nov 08 15:03:00 OK added the line numbers after DEBUUUG as well, so we know where it fails Nov 08 15:03:03 Building now Nov 08 15:03:42 I think the lines are output anyway Nov 08 15:04:43 Seems quick enough... Why this is quicker v.s. rebuildign qtwebengine? Nov 08 15:04:51 It's also Chromium in the end? Nov 08 15:08:00 it's quicker mainly because you modified tmp-work directly, so it kept the cache of the previous build Nov 08 15:08:31 just bb is unaware that you modified it, that's why you do "bb -f" to force the recompilation Nov 08 15:09:14 it also means that if bitbabke needs to rebuild it because of a recipe change or something, you'll loose these tmp-work changes Nov 08 15:09:25 qtwebengine was also fast to rebuild that way Nov 08 15:09:32 well... "fast"... Nov 08 15:09:48 you can also use devtool to automate most of these steps Nov 08 15:10:25 including creating the workspace from the sources and then dumping the local changes as .patch files to the recipe and scping the built binaries to target Nov 08 15:10:49 I never really learned to use devtool ^^ Nov 08 15:12:48 I don't use it much as well (too much used to do . temp/run.do_compile after removing all exit statements from it) Nov 08 15:13:55 OK new image is ready, transferring and testing Nov 08 15:34:31 Fighting a bit with LS2 files again Nov 08 15:34:45 Seems to get corrupted when transferring Nov 08 15:40:48 Hmmz somehow nothing shows in log Nov 08 15:41:23 it's same as before? Nov 08 15:41:32 or nothing nothing? Nov 08 15:42:30 Same as before Nov 08 15:42:34 same as before would mean wl_display_connect has failed; could it be a right issue on the socket or something ? I don't know Nov 08 15:42:44 It could be I modified the wrong file somehow Nov 08 15:42:54 I modified it inside webruntime folder for chromium68 Nov 08 15:42:57 WHich should be OK Nov 08 15:46:15 to be sure you can add one more at line Nov 08 15:46:16 314 Nov 08 15:46:59 PS: you probably just need to copy the binary from packages-split, if it helps Nov 08 15:49:06 That will help I guess Nov 08 15:49:08 Let me try that Nov 08 15:50:20 Tofe: But I should have the Chromium binary as well right? Nov 08 15:50:28 Since I'm changing that, not just hte WebAppManager one? Nov 08 15:51:54 ah, oh, yes Nov 08 15:52:19 yes, it's the chromium recipe you have to rebuild, of course :) Nov 08 15:52:21 sorry Nov 08 15:52:33 brb Nov 08 15:55:41 Tofe: new rosy build in progress Nov 08 15:56:03 JaMa: Thnx Nov 08 15:59:56 Tofe: https://paste.ubuntu.com/p/bVj9vrZXhQ/ Nov 08 16:00:00 314 shows ;) Nov 08 16:00:25 I added another "LOG(ERROR) << __PRETTY_FUNCTION__ << "Herrie 314";" variant just in case Nov 08 16:50:21 Tofe: ERROR: busybox-static-1.31.0-r0 do_deploy: Execution of '/home/jenkins/workspace/luneos-testing/webos-ports/tmp-glibc/work/aarch64-halium-webos-linux/busybox-static/1.31.0-r0/temp/run.do_deploy.22014' failed with exit code 1: Nov 08 16:50:25 cp: cannot create regular file '/home/jenkins/workspace/luneos-testing/webos-ports/tmp-glibc/deploy/images/rosy/busybox-static': No such file or directory Nov 08 16:50:28 WARNING: exit code 1 from a shell command. Nov 08 16:50:36 will fix, seems to have the same issue as luneos-package.inc and emulator-appliance Nov 08 16:52:04 JaMa: Tofe gave me a fix for that yesterday Nov 08 16:52:16 http://jenkins.nas-admin.org/job/LuneOS/view/testing/job/luneos-testing_rosy/lastBuild/console Nov 08 16:52:28 "Nov 07 10:23:42 Herrie: can you add "mkdir -p ${DEPLOY_DIR_IMAGE}" at the beginning of do_deploy of busybox-static ?" Nov 08 16:52:54 does it look like https://github.com/webOS-ports/meta-webos-ports/commit/6fec67195dd53f77aeb0537212ec8314742ca021 ? Nov 08 16:53:07 ok, then it's not correct fix Nov 08 16:53:37 JaMa: Yours might be more correct Nov 08 16:53:43 Tofe's also worked though Nov 08 16:55:17 Tofe's won't work if you rebuild from sstate Nov 08 17:08:42 JaMa: Trust you on that :) Nov 08 17:08:53 I only tested Rost locally once Nov 08 17:12:33 s/Rost/Rosy Nov 08 18:20:03 ok back Nov 08 18:21:22 Herrie|2, JaMa: ah, sorry, I never quite know how to handle the deploy data Nov 08 18:22:18 Herrie|2: ok, so at least for chromium it's the right binary file :) so it's definitely wl_display_connect Nov 08 18:22:33 if you have some time, we can go further with the traces Nov 08 19:03:51 Tofe: out now, but you can post some instructions and will check later Nov 08 19:04:06 I will make a branch with my code I guess as well Nov 08 19:04:30 Herrie|2: ok :) well now I'm back on mainline hammerhead stuff -- still trying to make sound work a little bit... Nov 08 19:45:33 Tofe: Out for dinner, but should have time later Nov 08 19:47:20 ok! have a nice dinner! Nov 08 20:06:28 And back :) Nov 08 20:55:08 http://jenkins.nas-admin.org/job/LuneOS/view/testing/job/luneos-testing_workspace-compare-signatures/167/console Nov 08 20:55:11 Hash for dependent task busybox/busybox-static_1.31.0.bb:do_package changed from ea9941d25b9a17e0a1a33f5126aec849b15884d72a34ec2c4465e01719d435f1 to 25c6b65a258b2e6e791e028aa62fc3670bc69f9c09a8144629b4714f0421cc38 Nov 08 20:55:15 will fix that as well **** BEGIN LOGGING AT Fri Nov 08 21:47:38 2019 Nov 08 21:59:21 Tofe: Well I was there already earlier ;) Nov 08 21:59:34 About 2 hrs in total ;) Nov 08 22:01:13 :) that looks normal Nov 08 22:01:29 for chromium, I think the issue is somewhere there: https://github.com/webosose/chromium68/blob/a45520cafe8a91488a92df4e0731747da928d2c7/src/third_party/wayland/src/src/wayland-client.c#L855 Nov 08 22:03:07 but I don't know why it wouldn't work for chromium where it works well for our other programs Nov 08 22:18:49 Tofe: ah OK that gives me some pointers for debugging. I've seen some things in AGL code I believe that might give some clues Nov 08 22:19:33 AGL = Automotive Grade Linux which uses WAM on Yocto but non webOS based system Nov 08 22:19:52 Could be we just need to pass some flags here and there Nov 08 22:22:55 Might be I need to figure out what our WAYLAND_DISPLAY is and simply pass it in Nov 08 22:55:13 Herrie|2: WAYLAND_DISPLAY is why I asked about "wayland-0" earlier Nov 08 22:55:25 so we *should* be ok there, I guess **** ENDING LOGGING AT Sat Nov 09 02:59:57 2019