**** BEGIN LOGGING AT Tue Mar 15 02:59:56 2022 **** BEGIN LOGGING AT Tue Mar 15 05:03:12 2022 Mar 15 05:57:09 morning Mar 15 09:23:17 Morning! Mar 15 14:48:13 Morning! Mar 15 15:49:02 Tofe: On accounts: Should I PR that fix? Mar 15 15:49:12 Seems we'll need a few more further down the line for some of the SAM calls Mar 15 15:49:29 I fixed 1 SAM call but then SAM wasn't happy because it seems the wrong caller was being passed via WAM Mar 15 15:50:06 Not sure if I should fix that on JS end by adding "-a com.palm.app.acocunts" or we should solve it more structurally Mar 15 15:50:48 Herrie: I can do that too, but feel free to go ahead Mar 15 15:51:09 we should merge https://github.com/webOS-ports/meta-webos-ports/pull/501 too Mar 15 15:51:12 Tofe: OK Mar 15 15:51:54 Tofe: Done the merge Mar 15 15:52:06 thanks Mar 15 15:55:20 Tofe: When adding Google C+DAV the following call needs updating to com.webos instead of com.palm so it uses the API from SAM instead of Luna-sysmgr Mar 15 15:55:22 https://github.com/enyojs/enyo-1.0/blob/master/framework/source/palm/system/CrossAppUI.js#L19 Mar 15 15:55:58 After I update it, the call succeeds but I get an error message saying hte following: ERROR:CONSOLE(6445)] com.palm.app.accounts- "Could not get app path: Not allowed. Allow only for the info of calling app itself." Mar 15 15:56:12 When I manually do a luna-send with -a "com.palm.app.accounts" it works Mar 15 15:56:19 I'm checking now what it uses as sender Mar 15 15:56:23 I suspect something from WAM Mar 15 15:57:00 notice the "-" after the appId in the error message Mar 15 15:57:21 looks like it wanted to add a number for the app instance, but didn't do it for some reason Mar 15 15:58:20 Tofe: Ah well this seems to be the issue: [ F 135] 252.727 TX call 4 com.palm.app.accounts-12088 (jxZnt4Fh) com.webos.applicationManager (NvCuyIaX) (null) //getAppBasePath «{"appId":"org.webosports.app.cdav"}» Mar 15 15:58:50 Seems it passes org.webosports.app.cdav there Mar 15 15:59:05 ah ok Mar 15 15:59:58 So my manual call was incorrect I guess Mar 15 16:00:10 But still this is an issue in SAM that we should address somehow I guess Mar 15 16:06:16 I'll see if I can somehow pass the caller in the Enyo.PalmService Mar 15 16:10:56 Tofe: I guess for WAM we could also right away add: /usr/palm/services/ as well? Mar 15 16:18:38 Tofe: OK for WAM just for the /usr/palm/public for now: https://github.com/webOS-ports/wam/pull/3 Mar 15 16:34:21 Tofe: OK this at least fixes the API call, but not the caller issue (yet): https://github.com/webOS-ports/enyo-1.0/commit/29d5729a290a62915dc15e0e555daf3e0675e688 Mar 15 18:17:12 Herrie: another thing that is strange to me, is about the enact browser app; it's supposed to be an "app_shell", as described in appinfo.json, but it's not started in its dedicated app_shell process Mar 15 18:17:27 so I'll try to figure out what happens in SAM here Mar 15 18:17:57 my hope is that window.open behaves correctly in that browser, and that I can spot where the difference is Mar 15 18:24:09 Tofe: Ah that might be a lead indeed yes Mar 15 18:41:27 weird, the call to com.palm.applicationManager/launch doesn't end up in SAM ? Mar 15 19:15:41 Tofe: Well you might need to make it com.webos.applicationManager Mar 15 19:15:49 Seems the API doesn't define the com.palm variant anymore Mar 15 19:16:11 https://github.com/webOS-ports/sam/blob/webOS-ports/webOS-OSE/files/sysbus/com.webos.sam.api.json#L6-L8 Mar 15 19:16:28 Same I had with the CrossAppUI in Enyo Mar 15 19:16:48 Because the com.palm.applicationManager is used as name by luna-sysmgr which provides API's which aren't available in OSE's SAM Mar 15 19:16:56 Not ideal, but otherwise we would loose those API's Mar 15 19:17:10 So we need to update the API calls for the ones that are provided by SAM Mar 15 19:17:22 Unless you have another solution Mar 15 19:18:12 no that's fine Mar 15 19:18:28 what about com.webos.service.applicationManager ? Mar 15 19:18:53 it's the same, but it's what is documented iirc Mar 15 19:19:41 Well I guess they added the com.webos.applicationManager for backwards compatibility Mar 15 19:19:53 The com.webos.service.applicationManager might be better in the long run Mar 15 19:24:09 I'll use that one then, better go right away for the new name Mar 15 19:24:42 however, switching the cardshell to SAM broke the launching of all apps :p Mar 15 19:28:08 Tofe: Ah well it could be an easy fix, but who knows Mar 15 19:28:15 Maybe the API call is a bit different in terms of params Mar 15 19:29:36 yes, looks like it Mar 15 19:45:19 ok, it's fixed Mar 15 19:45:24 I'll PR that Mar 15 19:45:34 or just push it on my branch anyway Mar 15 19:46:32 https://github.com/webOS-ports/luna-next-cardshell/commit/33d3d35a69d1d1c06e34e5a696e85e6e7f0d0460 Mar 15 19:48:19 and now this: LSHUB_NO_NAME_PERMS {"APP_ID":"com.webos.chromium.platform.system.44912","ROLE_ID":"/usr/bin/app-shell/app_shell","EXE":"/usr/bin/app-shell/app_shell"} Mar 15 19:50:05 We're probably missing this kind of file: https://github.com/webosose/chromium91/blob/master/files/sysbus/app-shell.role.json but I didn't check yet Mar 15 19:50:39 Well those should be there really Mar 15 19:50:52 ah yes, it's there. Mar 15 19:51:10 but the name com.webos.chromium.platform.system.* isn't in the list of allowed named Mar 15 19:51:12 Can you paste a few more log lines around that error? Mar 15 19:51:12 names* Mar 15 19:52:16 Herrie: sure, https://paste2.org/g1psNvb9 Mar 15 19:53:14 The incorrect appId here could be the consequence of missing parameters in the launch call Mar 15 19:53:38 I'll just authorize that name and we'll see Mar 15 19:54:28 I see no references to "com.webos.chromium.platform.system" or "com.webos.chromium" in OSE's repos at all (or the search is broken) Mar 15 19:55:25 Ah wait: https://github.com/webosose/chromium87/blob/83784a81f0a9689518b45451205bdb594bd1cbab/src/neva/pal_service/webos/luna/luna_names.cc#L49 Mar 15 19:55:32 There's one linked above Mar 15 19:56:52 https://paste2.org/5LOaIHC1 message is now gone, but app_shell still stops early it seems Mar 15 19:56:59 And referenced here: https://github.com/webosose/chromium91/blob/7deca0fa8aa01ec414cf689448b76b4f828a100e/src/neva/pal_service/webos/platform_system_delegate_webos.cc#L33 Mar 15 19:57:38 interesting, that means pal_service actually work when using app_shell :p Mar 15 19:58:23 Tofe: Well this is suspicious: (null), file:///usr/lib/qml/WebOSCompositorBase/controllers/ViewStateController.qml:128: TypeError: Cannot read property 'start' of undefined Mar 15 19:58:36 Also that it tries to start BlueZ might be causing issues Mar 15 19:59:13 I wouldn't worry too much about WebOSCompositorBase qml stuff, we don't rely on it yet for our cardshell Mar 15 19:59:35 sam[458]: [I][NativeContainer][onKillChildProcess] Process(1126) was killed with status(6) <--- this is the crash/killing Mar 15 20:00:46 That seems to come just after BlueZ Mar 15 20:01:14 yes, intruiging indeed Mar 15 20:01:39 Well I guess you could gdb into SAM and see what's happening when it crashes? Mar 15 20:05:21 "app_shell[1926]: segfault at 0 ip 00007f24e3c041bf sp 00007ffd9673cbe0 error 4 in libcbe.so[7f24deb1f000+9fb5000]" Mar 15 20:05:37 so it's crashing somewhere in the chromium code Mar 15 20:05:47 You might have some logs in /var/log as per https://github.com/webosose/sam/blob/af986e600cba012d9ad67a50222174725fb242c3/src/bus/client/NativeContainer.cpp#L197-L200 Mar 15 20:05:54 I saw a log file for our phone app there Mar 15 20:06:15 SAM just starts the process and watches it Mar 15 20:06:44 Tofe: Well in Chromium it could be many things of course Mar 15 20:06:51 oh yes... Mar 15 20:07:05 We might miss another component of OSE but enable it by our params for example Mar 15 20:09:12 let me try some desperate move Mar 15 20:13:03 ok, managed to attach gdb somehow Mar 15 20:14:35 ... here is the crash https://paste2.org/baXY6aJG Mar 15 20:15:05 seems related to display, or wayland, or both Mar 15 20:15:54 mmh XDG_RUNTIME_DIR doesn't seem to be set Mar 15 20:15:57 let me try Mar 15 20:20:17 it wasn't that apparently Mar 15 20:22:26 I guess we're around here https://github.com/webosose/chromium91/blob/7deca0fa8aa01ec414cf689448b76b4f828a100e/src/ozone/ui/desktop_aura/desktop_screen_wayland.cc#L189 Mar 15 20:23:51 maybe here: https://github.com/webosose/chromium91/blob/master/src/ozone/ui/desktop_aura/desktop_screen_wayland.cc#L198 Mar 15 20:24:18 but what I find surprising here is that none of this code should trigger the constructor "display::Display::Display" where we are crashing Mar 15 20:25:05 ah, sorry, yes, it does, when it returns the Display object it will do a copy Mar 15 20:30:08 so, my guess here is that the list of displays is empty. Therefore "front()" returns something invalid. As C++ says about std::vector::front: "Calling this function on an empty container causes undefined behavior" Mar 15 20:32:17 But I thought we had display0 now? Mar 15 20:32:26 Otherwise it wouldn't boot at all? Mar 15 20:33:10 well I don't know the precise reason, we sure have a display :) but maybe app_shell is misconfigured somehow Mar 15 20:41:25 Victory ! Mar 15 20:42:52 the XDG_RUNTIME_DIR was indeed the issue, but my fix didn't work because of some weird code in the start script Mar 15 20:44:36 https://github.com/webosose/chromium91/blob/master/src/webos/install/app_shell/run_app_shell#L56 that line here looks quite suspicious Mar 15 20:48:40 https://imgur.com/oF9FHHa.png Mar 15 21:08:01 well, window.open doesn't seem to work at all in app_shell ... **** ENDING LOGGING AT Wed Mar 16 02:59:56 2022