**** BEGIN LOGGING AT Tue Jun 09 02:59:57 2020 Jun 09 05:42:20 Morning! Jun 09 05:43:46 Tofe: Was thinking while laying in bed: would it be possible to monitor the calls on a working device such as Hammerhead or Mako and on non-working device such as Tissot and see if there's anything obvious? Jun 09 05:44:01 They have different soc etc so might not make much sense etc Jun 09 06:50:17 Tofe: BTW seems Halium guys are making solid progress with 9.0 Jun 09 06:51:19 Seems that there's a GSI (Generic System Image) as well Jun 09 06:51:25 Might be interesting to toy with at some point Jun 09 06:57:37 Morning! Jun 09 06:58:11 Herrie: yes, I wanted also to try that Halium 9.0 approach Jun 09 06:58:41 Though building a GSI for LuneOS could prove a bit... challenging Jun 09 06:59:38 For us the split is very clear: GSI is what isn't MACHINE-dependent Jun 09 07:00:29 As for looking at a working device's log, I tried to compare, but things have changed between Halium 5.1 and 7.1... Jun 09 07:02:20 Tofe: Yeah that's true... I could build the Hammerhead 7.1 though or Mako 7.1 Jun 09 07:02:24 That shouldn't be rocket science Jun 09 07:02:33 I had Hammerhead 7.1 at some point Jun 09 07:02:39 Might still have it laying around somewhere Jun 09 07:03:26 But did we have calls working ? :) Jun 09 07:03:41 Tofe: I'm not sure on 7.1 in general Jun 09 07:03:49 But we know Hammerhead well Jun 09 07:03:58 And we have calls with that on 5.1 Jun 09 07:04:01 At least should have Jun 09 07:04:21 I can build a 5.1 image quickly if needed for Hammherhead or Mako, just let me know and put together a 7.1 as well Jun 09 07:04:29 Then it's easier to compare probably Jun 09 07:06:44 I mean I have https://github.com/Halium/halium-devices/blob/halium-7.1/manifests/lge_hammerhead.xml Jun 09 07:06:50 Hammerhead 5.1 we should have that somewhere on our server Jun 09 07:06:58 Tofe: yes Jun 09 07:07:05 So building 7.1 should be easy Jun 09 07:07:18 Just seems i forgot to backup my Halium build script while reinstalling my OS :S Jun 09 07:08:05 ah, one moment Jun 09 07:09:59 Seems our Halium builds failed again.. fatal: remote them2 not defined in /home/jenkins/workspace/halium-luneos-7.1-build/halium-luneos-7.1/.repo/manifest.xml Jun 09 07:10:11 I guess we need to update the repos in our Android repo with the ones from Halium Jun 09 07:10:42 Look in NAS/LuneOS/FromTofe/ Jun 09 07:11:00 I use the switch script followed by the build one Jun 09 07:11:17 I,e. we need to run: https://github.com/webOS-ports/android/blob/luneos-halium-7.1/update-halium-subtree.sh Jun 09 07:11:56 ah ok, yes Jun 09 07:11:58 Can you do that one? I don't have any git stuff setup on my Linux machine, only on Windows ;0 Jun 09 07:11:59 ;) Jun 09 07:12:03 sure Jun 09 07:12:08 I added them2 remote to Halium not too long ago Jun 09 07:13:23 To point to TheMuppets GitLab account which hosts the files that were causing the repos to be DCMA'd on GitHub ;) Jun 09 07:15:55 pushed Jun 09 07:16:19 Seems I kept some work: https://github.com/Herrie82/meta-smartphone/commit/22c5f70bbf958cfd3e4b1d52b4d5ddb1fc961e9f Jun 09 07:16:25 Should be easy enough to build ;) Jun 09 07:16:48 hopefully :) Jun 09 07:18:13 Let me try to build it in a bit Jun 09 07:24:27 OK building Jun 09 07:25:03 I don't exactly recall the status on Hammerhead 7.1 (would need to check our chat logs), but recall it was pretty similar to 5.1 actually in terms of things working Jun 09 07:29:07 Kernels fails to build, but seems I didn't have latest SRCREV in recipe, retrying Jun 09 07:35:06 Nope also not... Don't remember what I did there exactly Jun 09 07:43:17 it could be newer gcc, too Jun 09 07:45:53 Nope Jun 09 07:46:16 I took the 14.1/7.1 kernel from LOS, applied a bunch of patches that we had just it wouldn't build Jun 09 07:46:20 Let me try the 8.1 kernel Jun 09 07:46:29 They should be interchangable mostly anyway Jun 09 07:46:57 There's not a whole lot of development on the Hammerhead kernel anymore :P Jun 09 08:13:01 Tofe: OK got a kernel building it seems... Just it somehow didn't like memnotify.. .maybe I didn't patch it there... Jun 09 08:13:14 Just removed the RDEPENDS in packagegroup for now Jun 09 08:16:25 yes, we don't care about that right now Jun 09 08:19:22 Seems I'm missing a few other things... Let me rework that repo a bit Jun 09 08:19:39 It builds with https://github.com/Herrie82/android_kernel_lge_hammerhead/commit/d2d83be6541b2500f36753589c75ea35d6f871f5 it seems Jun 09 08:22:39 Just fails on a module because CONFIG_MODULES is not set in defconfig Jun 09 08:38:02 ah, yes, makes sense Jun 09 08:44:46 With CONFIG_MODULES=y it fails with the bcmdhd module... Jun 09 08:44:55 ERROR: "lge_get_boot_mode" [drivers/video/backlight/lm3630_bl.ko] undefined! Jun 09 08:44:56 ERROR: "in6addr_linklocal_allnodes" [drivers/net/wireless/bcmdhd/bcmdhd.ko] undefined! Jun 09 08:44:56 ERROR: "check_wakeup_reason" [drivers/net/wireless/bcmdhd/bcmdhd.ko] undefined! Jun 09 08:46:02 I could simply remove the module for now I guess Jun 09 08:51:59 yes, don't bother with memnotify Jun 09 08:53:51 Well bcmdhd = wifi Jun 09 08:53:58 Though for testing calls not critical Jun 09 08:54:43 Ah that also doesn't work... Jun 09 08:56:12 Ah seems issue might be CONFIG_PARTIALRESUME=y in defconfig Jun 09 08:56:28 We didn't have that in 5.1 and seems that triggers the issues Jun 09 09:00:46 https://github.com/Herrie82/android_kernel_lge_hammerhead/blob/b1714f68194957f370aabbfbfe62a3285d79da86/drivers/net/wireless/bcmdhd/bcmsdh_sdmmc_linux.c#L243 Jun 09 09:00:52 At least for 2 of the 3 isuses reported Jun 09 09:05:06 which one stays ? Jun 09 09:08:28 Well that one I tackled too already Jun 09 09:08:38 New errors now :S Jun 09 09:09:56 home/herrie/LuneOS/zeus/webos-ports/tmp-glibc/work-shared/hammerhead/kernel-source/drivers/net/wireless/bcmdhd/bcmsdh_sdmmc_linux.c:244:11: error: implicit declaration of function 'check_wakeup_reason'; did you mean 'check_wakeup_irqs'? [ Jun 09 09:11:38 Ah it's probably this: https://github.com/Herrie82/android_kernel_lge_hammerhead/commit/42fe48d30c41874e679b6552798de94797c5f402 Jun 09 09:11:57 drivers/net/wireless/bcmdhd/Makefile: DHDCFLAGS += -DDHD_WAKE_STATUS -DDHD_WAKE_RX_STATUS Jun 09 09:19:54 That one is gone now Jun 09 09:20:06 This one is remaining: https://github.com/Herrie82/android_kernel_lge_hammerhead/blob/halium-7.1/drivers/video/backlight/lm3630_bl.c#L616 Jun 09 09:24:32 Let me just remove those 3 lines Jun 09 09:24:42 Seems that the defconfig change somehow doesn't help Jun 09 09:26:25 OK now it builds properly at least Jun 09 09:27:18 Just my Hammerhead was funny last time.. i guess I should factory reset it to Google's 5.1 image Jun 09 09:41:46 Where did I even put it ;) Jun 09 09:41:50 Will have a look Jun 09 09:42:17 Maybe at my desk somewhere.... Jun 09 09:42:24 Usually keep it in my bagpack :S Jun 09 09:42:54 Tofe: There's luneos-dev-package-hammerhead-halium-7.1-0-0.zip on the FTP Jun 09 10:03:50 Herrie: you mean, 7.1 LineageOS ;) Jun 09 10:04:34 Tofe: Well I think 5.1 would also work Jun 09 10:04:45 I doubt firmwares were changed in between Jun 09 10:04:49 probably; it's also possible Google changed it a bit in Android 6.0 Jun 09 10:05:00 but I agree it's unlikely Jun 09 10:07:05 ok, flashing, let's see Jun 09 10:08:23 I kinda remember I had 7.1 booting Jun 09 10:41:36 Tofe: Updated luneos-component PR based on your comments. Also did this one just now: https://github.com/webOS-ports/luna-init/pull/18 Jun 09 10:44:07 no adb, no bootloop... mmh Jun 09 10:47:31 Herrie: why do we have 2 places where the default location appear ? Jun 09 10:50:48 1 for your LNC mock Jun 09 10:51:02 So when you run it in QtCreator Jun 09 10:51:07 So you don't need Luna-init Jun 09 10:52:02 ah yes Jun 09 10:52:03 ok Jun 09 10:52:40 Tofe: Sorry seems I missed another one in luna-init: https://github.com/webOS-ports/luna-init/pull/19 Jun 09 10:52:49 Merely cosmetics but well Jun 09 10:53:11 no problem, merged Jun 09 10:53:46 damn, no last_kmsg, no pstore Jun 09 10:56:27 And another cleanup one... Seems I PR-ed to master, had our ACG in tofe/acg, let's merge back into master: https://github.com/webOS-ports/luneos-components/pull/98 Jun 09 11:07:41 Tofe: hmm not helpful on Hammerhead then Jun 09 11:10:03 unfortunately no, but it was a good idea Jun 09 11:10:19 I'll try to compare again with android 7.1 on tissot Jun 09 11:23:43 Hmmz Halium mido still failing... Will look into that Jun 09 12:51:41 Tofe: I'm seeing: 2020-06-09T12:36:45.231543Z [308.900131054] user.warning ls-hubd [] ls-hubd LSHUB_NO_SERVICE {} _LSHubSendQueryNameReplyMessage: Failed Connecting to Service err_code: -3, service_name: "com.webos.service.telephony", unique_name: "(null)", static, fd -1 Jun 09 12:51:41 2020-06-09T12:41:33.000839Z [596.669424371] user.err ls-hubd [] ls-hubd LSHUB_NOT_LSTED {"SERVICE_NAME":"com.android.properties","EXE":"/usr/sbin/luna-qml-launcher","APP_ID":"org.webosports.app.settings.deviceinfo","PID":1180} Service not listed in service files (cmdline: /usr/sbin/luna-qml-launcher /usr/palm/applications/org.webosports.app.settings.deviceinfo/appinfo.json) Jun 09 12:54:55 it's surprising Jun 09 12:55:23 Did I put the correct SRCREV when I bumped the settings app ? Jun 09 12:58:54 Seems OK Jun 09 13:03:32 Tofe: Ah could be becuase I don't have the android property service in my qemux86 image? Jun 09 13:08:00 Yes, could be ! maybe we could try a smoother approach in our QML code... but so far it just works, so, well. Jun 09 15:41:16 Tofe: With silly stuff like this I'm not surprised some things don't work ;) https://github.com/webOS-ports/certmgrd/commit/e637b787569441ca6a3fbef57f5d291a14a031fe Jun 09 15:46:36 Easy enough to fix though ;) Jun 09 15:46:40 oh. :) Jun 09 15:50:41 OK cert stuff now works it seems ;) Jun 09 15:51:26 There we go: https://github.com/webOS-ports/certmgrd/pull/2 Jun 09 15:51:50 Squashed the commits as well and pushing it back to OSE branch so we can kill the ACG ones after merge Jun 09 15:52:25 So I can hide my spelling mistakes LOL :P Jun 09 16:04:55 Seems there are a few more fixes coming up for Settings ;) Jun 09 16:06:47 https://github.com/webOS-ports/audio-service/pull/9/files Jun 09 16:20:00 Tofe: I noticed that with a number of services that try to register an activity, this activity seems to never complete Jun 09 16:20:12 I.e. Tweaks, FileManager, but probably also CDAV Jun 09 16:21:43 What I noticed is that the call seems to go to com.webos.service.activitymanager, but reply is expected from com.palm.activitymanager and that doesn't match somehow Jun 09 16:21:55 Could this be the LsRegisterPubPriv stuff somehow? Jun 09 16:22:00 For example: https://paste.ubuntu.com/p/rmHgdxXYKy/ Jun 09 16:22:06 That's for Filemanager service Jun 09 16:23:33 And for Tweaks here at the bottom: https://paste.ubuntu.com/p/stJW7QVyy8/ Jun 09 16:26:21 When I do these calls via luna-send there's no reply Jun 09 16:26:46 But ls-monitor gives this output so a bit puzzled Jun 09 16:26:57 And this happens for a few of these services Jun 09 16:46:04 What they have in common is that it are all NodeJS services by the looks of it Jun 09 16:47:26 Herrie: ideally, all PubPriv should go Jun 09 16:47:36 So seems they register OK, ACG seems OK just no reply from them because they seem to involve activitymanager Jun 09 16:47:56 At least that's my assessment so far Jun 09 16:48:00 ok Jun 09 16:48:25 Might be wrong but that's what I'm getting Jun 09 16:48:34 Not sure how to debug/fix though Jun 09 16:48:38 From what I've seen so far, what definitely doesn't work is an app/service that has new ACG permissions with client-perm etc and that still does PubPriv registration somewhere Jun 09 16:48:57 Ah ok Jun 09 16:50:10 So it's probably nodejs-modules-sysbus that needs that reverted OSE commit reapplied Jun 09 16:50:49 let me have a look at our activitymanager a bit Jun 09 16:51:08 which commit ? Jun 09 16:52:40 https://github.com/webOS-ports/nodejs-module-webos-sysbus/blob/webOS-ports/webOS-OSE/src/node_ls2_handle.cpp#L107 <-- not good :) Jun 09 16:53:15 let me change this quickly Jun 09 16:56:29 mmmh after some thoughts, I'm not fully sure I should change that Jun 09 16:56:34 what about legacy stuff Jun 09 16:57:10 Yes that's the point.... Jun 09 16:57:14 Also not sure Jun 09 17:08:05 Tofe: I wonder how nodejs-module-webos-sysbus determines if it should use the LSRegister or the PubPriv one. That's not clear to me Jun 09 17:19:10 Might be good to add some logging there in the CPP to see which register version it uses and the args that are being passed Jun 09 17:19:23 This way we could trace the source of those maybe Jun 09 17:26:57 Tofe: There's also am-monitor now Jun 09 17:27:01 That might help somehow Jun 09 18:21:58 sorry was afk Jun 09 18:22:44 Herrie: sysbus module always does PubPriv when the js caller uses the Handle(name, boolean) signature Jun 09 18:24:07 if the caller uses the new signature "Handle(name)", then the C++ code will use LSRegisterApplicationService, which is appropriate for apps running inside a "container" Jun 09 18:24:56 But... is there a sysbus at all in OSE ?... Jun 09 18:28:05 Tofe: well seems so Jun 09 18:28:13 They have some nodejs services Jun 09 18:28:24 I think their devmode is nodejs Jun 09 18:30:55 Herrie: I've made my choice: https://github.com/webOS-ports/nodejs-module-webos-sysbus/pull/10 Jun 09 18:31:31 (my branch is based on your acg branch) Jun 09 18:32:11 It is nodejs-module-webos-sysbus that does the LSRegister call, so it must not be a PubPriv call. Jun 09 18:33:02 But it also means that if a legacy app uses the old signature, nodejs-module-webos-sysbus will try to register that name, so it should be in the allowedNames in nodejs-module-webos-sysbus's role file Jun 09 18:33:26 well it'll be a legacy service, not an app, but maybe there are some, out there Jun 09 18:34:43 https://github.com/webosose/nodejs-module-webos-sysbus/commit/44b863203d98ed9488c7fc72a7aa7da6971fb56a they went even further Jun 09 18:35:07 should we rebase, maybe ?... Jun 09 18:36:06 Tofe: Well we did that with ls2 migration but it caused havoc Jun 09 18:36:16 But now with ACG it might actually be OK Jun 09 18:36:33 Only way to know is to test I guess Jun 09 18:36:38 yes Jun 09 18:37:37 ah we can't rebase, can we Jun 09 18:37:44 different history Jun 09 18:37:53 Does your PR solve the issue, did you test? Jun 09 18:38:03 no testing yet :p Jun 09 18:38:19 Tofe: well not directly... With some git fu I can but well Jun 09 18:38:36 Adding the remote and cherry picking commits Jun 09 18:38:51 I though we had it already somewhere and reverted this commit Jun 09 18:39:25 if it was before we migrated the whole service to ACG, it could have caused many regressions Jun 09 18:40:35 mmmh actually it'll be easier to just test my version, and then test without any LSRegister at all Jun 09 18:41:11 Yes it was before and broke lots of things Jun 09 18:41:30 The benefit of using LSRegisterApplicationService is that it'll look into the service's permissions instead of nodejs-module-webos-sysbus ones Jun 09 18:42:03 that's why they have a very simple role file, compared to us Jun 09 18:42:20 https://github.com/webOS-ports/nodejs-module-webos-sysbus/commit/dbf8f080001071d3fe81c2212c5a159b1dcaa600 Jun 09 18:42:39 That's where we reverted it Jun 09 18:42:53 one year ago I don't think we had migrated many services Jun 09 18:43:15 Nothing yet Jun 09 18:43:19 if we use this commit, it means all the nodejs services have to have their own permissions Jun 09 18:43:35 I started ACG only in December Jun 09 18:43:47 ok, so... let's retry ! :) Jun 09 18:43:54 This was part of initial OSE migration with mainly LS2 itself Jun 09 18:44:29 And everything that needed upgrading as a result (was still about 15-20 components) Jun 09 18:44:57 If we use my version, we can do a progression migration of our services; maybe it's better Jun 09 18:45:48 Services not migrated will use Handle("name", true/false) and for those we'll need to add the name in the allowedNamed of nodejs-module-webos-sysbus Jun 09 18:46:37 Well all should have been migrated really Jun 09 18:46:40 Then if we migrate them, and their permissions are installed and so on, they can start using Handle("name") Jun 09 18:46:49 all the mojo stuff ?... Jun 09 18:46:53 There's nothing using pub/priv anymore in image Jun 09 18:47:05 From what I can tell or very little Jun 09 18:47:23 I mean in JS it doesn't appear with PubPriv, it appears with "new Handle("name", true)" Jun 09 18:47:52 and I think I found some occurrences of that in our old js services Jun 09 18:48:12 let me search once more in the rootfs Jun 09 18:49:19 ./frameworks/mojoservice/version/1.0/javascript/method_dispatcher.js: this._handle = new palmbus.Handle(serviceName, publicBus); Jun 09 18:49:22 stuff like that Jun 09 18:50:30 or: ./frameworks/foundations/version/1.0/javascript/comms/palmcall.js: this._handle = new webOS.Handle("", false); Jun 09 18:50:32 and so on Jun 09 18:50:55 what is annoying here is that it's very indirectly used Jun 09 18:51:20 mojoservice doesn't have ACG files, it's just a library Jun 09 18:51:38 same for foundations Jun 09 18:53:19 but, in theory, all the services impacted are already in our "allowedNames" for nodejs Jun 09 18:53:50 and we probably already migrated them Jun 09 18:55:23 oh, well, let's just try. Jun 09 18:56:02 Well we can always patch the frameworks if needed Jun 09 18:56:30 the final step will be to remove the "true" or "false" argument yes Jun 09 18:56:49 but patching nodejs sysbus is more direct :) Jun 09 18:57:05 Herrie: what should I try, that failed ? Jun 09 18:57:14 I'm currently just testing my PR Jun 09 18:57:19 Open Tweaks Jun 09 18:57:49 See if the scan succeeds Jun 09 18:58:05 nope, scanning end in an error Jun 09 18:58:39 Jun 08 21:53:13 tissot ls-hubd[1009]: Error: Attempted to register for a service name that already exists: org.webosports.service.tweaks.prefs Jun 09 18:58:42 With me it keeps spinning forever Jun 09 18:58:54 In TWeaks app Jun 09 18:59:25 well after I click "OK" in the error dialog it still spins, but I think the app is dead Jun 09 19:00:00 The error I pointed to is an LS2 error: two LSRegister with the same name, basically Jun 09 19:00:54 which is the consequence of two things: 1) "ports.service.tweaks.prefs[3987]: [] [pmlog] legacy-log Private Bus Access: undefined" which lead to 2) "ports.service.tweaks.prefs[3987]: [] [pmlog] legacy-log sending on public bus" Jun 09 19:01:53 now let's retry with LG's version... Jun 09 19:04:41 When I do a luna-send I don't get a reply Jun 09 19:04:49 At least before your changes Jun 09 19:05:03 which luna-send ? Jun 09 19:06:17 ah, oops, I forgot to restart the services Jun 09 19:06:24 Luna-send -n 1 luna://org.webosports.service.tweaks.prefs/scan '{}' Jun 09 19:06:42 thanks, I'll try too Jun 09 19:07:05 Ls-monitor -i works though Jun 09 19:07:08 And replies Jun 09 19:08:59 ls-hubd[1033]: Error: The service is not registered Jun 09 19:12:33 https://paste.ubuntu.com/p/wzwTwxmCK2/ Jun 09 19:13:38 here it doesn't even return an answer... Jun 09 19:15:09 so, my PR breaks it even further, great :) Jun 09 19:22:05 Herrie: I think we'll have to migrate mojoservice at the same time; it has a strong tendency to create both a public and a private Handle, and that's not possible anymore Jun 09 19:23:53 but I'm less comfortable with hacking js stuff... what creates the minimized version ? bitbake build ? something else ? Jun 09 19:29:05 Don't think bitbake does that Jun 09 19:31:34 Tofe: You have the occurrances of these calls? Jun 09 19:31:39 So I can look as well? Jun 09 20:18:25 Herrie: well the issue is mainly in this file https://github.com/webOS-ports/mojoservice-frameworks/blob/webOS-ports/webOS-OSE/mojoservice/javascript/controller_service.js#L33 Jun 09 20:19:03 we see, for examples in _bindCommands function, that there can be two dispatchers, one public and one private Jun 09 20:19:17 that's wrong with ACG: there should one handle, one dispatcher only Jun 09 20:23:39 Yes indeed Jun 09 20:23:55 Still weird the issues with activitymanager Jun 09 20:24:16 That activities seem to be created but no reply is being sent Jun 09 20:24:27 At least that's what I seem to see **** ENDING LOGGING AT Wed Jun 10 02:59:57 2020