**** BEGIN LOGGING AT Wed Dec 28 02:59:56 2022 Dec 28 07:25:50 Tofe: Good we have similar status at least now Dec 28 10:34:10 Morning! Dec 28 10:34:20 Herrie: https://github.com/webOS-ports/org.webosports.app.phone/pull/56 looks like we forgot some commits along the way Dec 28 10:44:36 Tofe: Well easy enough then Dec 28 10:44:44 Yeah well we can forgot one here or there Dec 28 10:46:30 hopefully that was easy to spot, I still had the tofe/qt6 version on my qtcreator session Dec 28 10:51:50 WAM crashing seems to be related to an app crash (like for calendar) not being handled properly Dec 28 10:54:50 calendar is a bit special: it's a "nowindow" app which starts in background, meaning it's using our beta code for window.open. Also, it tries to update the launcher icon, which doesn't seem to work so well Dec 28 10:55:41 I don't know yet why it crashes, but I'm not utterly surprised that the crash handling is not working properly yet for this app Dec 28 12:01:58 Tofe: Launcher icon goes via activity Dec 28 12:02:07 Not surprised that somehow is broken, but I think it was broken before Dec 28 12:02:24 We could disable the call to the activity to see if that "solves" something? Dec 28 12:53:19 We fixed the $0a Dec 28 12:53:28 $activity before Dec 28 12:53:43 Might be somewhat related Dec 28 13:32:32 I.e.: This commit: https://github.com/webOS-ports/core-apps/commit/9a8b3039cc797c4690d2201aa54299cda4099f74 Dec 28 13:34:41 well we do see this warning in the logs Dec 28 13:36:28 and it's actually crashing right after the warning Dec 28 13:39:55 It could be some of the database handling somehow Dec 28 13:40:09 Adding some logging a few lines later might help Dec 28 13:43:43 Tofe: https://github.com/webOS-ports/core-apps/blob/9a8b3039cc797c4690d2201aa54299cda4099f74/com.palm.app.calendar/libs/Mojo.Core.Service.js#L166 maybe? Dec 28 13:43:47 The public/private one? Dec 28 13:45:44 not sure; but we shouldn't be going into the " if (typeof PalmServiceBridge === "undefined") { ", normally the PalmServiceBridge is there Dec 28 13:46:30 The last log before crash is: [] [pmlog] WAM LOAD {"APP_ID":"com.palm.app.calendar","INSTANCE_ID":"","PID":0} [...100%]file://com.palm.app.calendar-webos/usr/palm/applications/com.palm.app.calendar/app/calendar.html Dec 28 13:46:58 so that might mean that the loading is finished, and does something to finalize the page, and that would crash maybe Dec 28 13:49:41 ^ I don't see anything correlating this hypothesis in the wam code Dec 28 13:51:57 It could be my window.open forward patch is not 100% correct somehow? Dec 28 13:52:05 Or that part works Dec 28 13:52:13 I'm not great at forward porting patches at times Dec 28 13:52:19 And some of these were quite long ;) Dec 28 13:53:40 :) I can check a bit Dec 28 14:00:08 Did we have it working before with Chromium 91 or not, don't recall to be honest Dec 28 14:00:10 I thought we did Dec 28 14:07:48 the app was starting, but the calendar number never appeared Dec 28 14:07:56 (on the launcher icon I mean) Dec 28 14:11:19 Tofe: Well it does initially, but the update doesn't work Dec 28 14:11:23 But that's the activity Dec 28 14:11:28 It's not that critical in general Dec 28 14:11:35 But nice to have it fixed at some point Dec 28 14:11:53 And it becomes blank later. I briefly see the right number sometimes when booting cardshell Dec 28 18:26:50 Herrie: also, somewhere along the way, we got a conflict for the ethernet usb0 configuration Dec 28 18:27:12 looks like connman is somehow messing up our hardcoded ethernet link Dec 28 18:29:26 or it could be a udev rule, not sure yet Dec 28 18:30:19 Tofe: Well that could be... Though I thought I fixed that... It was a missing patch somewhere let me see Dec 28 18:30:49 Or it might be something else Dec 28 18:30:57 That's in qemu or PP? Dec 28 18:31:33 PP; and if I use the jack cable and set it up by hand ("ip address add 172.16.42.2/16 dev usb0" ) then it's back to working Dec 28 18:32:50 It's probably the connman config I changes Dec 28 18:32:52 Changed Dec 28 18:33:00 we had some stuff "blacklisted" Dec 28 18:34:38 NetworkInterfaceBlacklist = p2p,usb,rndis,rmnet,ifb Dec 28 18:34:44 Removed that one from https://github.com/webOS-ports/meta-webos-ports/commit/65b1b3d91e8f6c834e1208196175a2d2612e740d Dec 28 18:34:52 I couldn't trace the origins, so likely that's the cause Dec 28 18:35:01 I mean where this config came from originally Dec 28 18:35:59 I can try to add it back to test Dec 28 18:36:14 Very likely to be related to that Dec 28 18:36:26 Just OSE provides P2P, I wasn't sure what others did/didn't do so removed it Dec 28 18:36:37 rndis is something we might want as well? Dec 28 18:36:47 It's telnet no? SSH into device like halium/sfos uses? Dec 28 18:36:55 we can just blacklist usb Dec 28 18:37:02 or, we could also preconfigure it Dec 28 18:38:02 ok, that worked Dec 28 18:38:10 let me test with just usb Dec 28 18:38:20 Tofe: I couldn't trace the original why we added it in first place Dec 28 18:38:42 And didn't see if OSE so removed Dec 28 18:38:50 So good you asked Dec 28 18:38:59 Could easily recall it Dec 28 18:39:00 frankly, I think I'd prefer preconfiguring it somehow, with a connman setting Dec 28 18:39:57 it's fine with just usb blacklisted Dec 28 18:40:19 now let me try the setting to let connman handle this Dec 28 18:59:53 We might want to check sfos settings? Though their connman is very franken Dec 28 18:59:59 https://github.com/webOS-ports/meta-webos-ports/pull/558 for the moment, I couldn't find any better way Dec 28 19:00:27 our MAC usb address is a bit random, so it's hard to hardcode its IP Dec 28 19:00:43 and connman's service name is based on the mac address Dec 28 19:23:29 We added something to systemd recipe for "predictable interface names" on qemu Dec 28 19:23:52 Might be a lead for the random address somehow too? Dec 28 19:25:52 There is some stuff for cec handling but that's hdmi specific and not USB I think? Dec 28 20:03:05 predictable interface is more about the actual iface name like eth0 wlan0, not randomized MAC and OSE is using old naming mostly because silly webos-connman-adapter uses wpa-cli instead of proper API from wpa-supplicant Dec 28 20:07:20 JaMa: ooh well,, I guess it has it's "uses" somehow Dec 28 20:07:28 Most things Palm/HP did for webOS did make sense Dec 28 20:09:33 Some were hacky though Dec 28 20:31:26 https://stackoverflow.com/questions/23250080/writing-an-external-program-to-interface-with-wpa-supplicant-in-c hardcoded 'wlan0' added in https://github.com/webosose/webos-connman-adapter/commit/8c4bb9631f007c37c39951eb6263b6410df486f1#diff-6cf7ed001b06460f7f5b5efc787f5ba281391e68d5cc6a18018ef37ec72a497cR92 even when https://github.com/webosose/webos-connman-adapter/blob/master/CMakeLists.txt#L30 Dec 28 20:31:33 allows to at least define "build-time" WIFI_IFACE_NAME and WIRED_IFACE_NAME, still quite limited for other possible defices which might have multiple interfaces or even 6 years old change from udev https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ Dec 28 20:33:43 my laptop also has enp2s0 and wlo1, so won't be able to use generic (as TUNE_PKGARCH shared across multiple devices) webos-connman-adapter (even if I really wanted to) Dec 28 20:36:03 and on my desktop I had /etc/udev/rules.d/80-net-name-slot.rules from 2013 until recently when I finally got rid of it, because with new MB it was quite often swapping eth0 and eth1 names Dec 28 20:48:11 https://bpa.st/D5CUK this seems to work Dec 28 20:59:05 https://github.com/webOS-ports/meta-webos-ports/pull/559 I can propose this, what do you think ? Dec 28 21:02:52 If JaMa is happy, I am too, not too familiar with connman's internal workings Dec 28 21:03:12 hold on a bit, I still need to test with a proper reflash Dec 28 21:06:01 ok Dec 28 21:06:13 I haven't tried it, but LGTM in general Dec 28 21:15:01 ok that's what I feared: /var/lib/connman/settings has to be patched to enable the "Gadget" technology Dec 28 22:02:25 I did another PR that seems to fix the issue, but the fix isn't so nice imho Dec 28 22:02:52 but this can wait, it doesn't bring any fancy improvement afaik Dec 28 22:03:09 ^ this PR, I mean. **** ENDING LOGGING AT Thu Dec 29 02:59:57 2022