**** BEGIN LOGGING AT Mon Feb 14 02:59:56 2022 Feb 14 07:58:13 Morning! Feb 14 08:01:11 Wow, surpringly good news: changing qtwayland doesn't rebuild qtwebengine. Good ! Feb 14 08:08:05 Morning! Feb 14 08:08:52 Tofe: I merged your PR and build qemux86-64 at my side Feb 14 08:46:21 Herrie: note that LSM isn't included yet in the default images Feb 14 09:05:30 Morning! Feb 14 09:05:38 Tofe: I merged your PR and build qemux86-64 at my side Feb 14 09:05:59 Will test it probably later today Feb 14 10:31:32 Tofe: That is good news, but with WAM do we still build qtwebengine at all? Feb 14 10:32:19 I think we might not be building it anymore because we switched to WAM, but didn't check it in detail to see where the dependencies get pulled in Feb 14 10:39:10 Herrie: we should make sure we don't build it, yes Feb 14 10:39:26 maybe we could even put it in the blacklist ? Feb 14 10:40:43 Yeah we'd need to check indeed Feb 14 10:40:54 But that can be done later after switch Feb 14 12:49:05 in the cardshell recipe I've changed the RDEPENDS to have LSM instead of luna-next, we'll see how this goes Feb 14 12:49:18 (the change isn't pushed or anything yet) Feb 14 15:38:20 Tofe: OK because in my build it seems I don't have LSM either deployed Feb 14 15:38:27 So figured more bits where needed Feb 14 15:40:06 Well I'm not even sure how we tell LSM to take our cardshell :) Feb 14 15:58:42 Well it seems they just hardcoded the QML? https://github.com/webosose/luna-surfacemanager/tree/master/base/qml/WebOSCompositorBase Feb 14 15:58:57 I mean the QML files are in the luna-surfacemanager Feb 14 15:59:29 So where we have luna-next and luna-next-cardshell, seems they have it in 1 ? Feb 14 15:59:35 could be yes; the "cardshell" notion would have to be refined, in this case Feb 14 15:59:57 well it depends, maybe they still have a dynamic loading of the "dressup" Feb 14 16:00:03 but then again, maybe not... Feb 14 16:00:48 Well seems that for "auto" they use a different luna-surface-manager: https://github.com/webosose/auto-luna-surface-manager/tree/master/qml/WebOSCompositor Feb 14 16:01:04 I guess you could load it up in QtCreator and see what it does ;) Feb 14 16:02:13 https://github.com/webosose/auto-luna-surface-manager/blob/master/src/plugins/compositor/webosauto/webosautocompositor.cpp seems like they have a "core" compositor you can inherit and specialize Feb 14 16:02:39 today we inherit qtwayland's compositor type, so migrating to LSM would probably mean inheriting the one from LSM Feb 14 16:03:20 it's good you pointed out the "auto" LSM code, it's a good example of what we could do ourselfves Feb 14 16:03:53 still not sure if auto-LSM replaces LSM or not Feb 14 16:06:18 https://github.com/webosose/meta-webosose/blob/2c2d79cbed64499b6ce4106ad31b73a30c6810f5/meta-webos/conf/distro/include/webos-preferred-providers.inc#L103 so there would be a "-base" recipe too ? mmh Feb 14 16:09:03 https://github.com/webosose/meta-webosose/blob/master/meta-webos/recipes-webos/luna-surfacemanager/luna-surfacemanager.bb#L82 ok, it's provided by LSM, good :) Feb 14 16:10:52 Tofe: Yeah I saw a webOSCompositorBase somewhere in LSM Feb 14 16:11:09 https://www.webosose.org/docs/guides/core-topics/architecture/architecture-overview/ Feb 14 16:11:17 https://github.com/webosose/luna-surfacemanager/tree/master/base/qml/WebOSCompositor ah they explain the HOWTO here Feb 14 16:11:28 And found this: https://events19.linuxfoundation.org/wp-content/uploads/2018/07/ALS2019-webOS-LSM-for-Automotive_v2.pdf Feb 14 16:13:30 nice Feb 14 16:13:53 but I think I have what I need to adapt our cardshell, or at least to investigate what should be changed Feb 14 16:14:38 The presentation gives some more background on things Feb 14 16:17:12 Page 12 and further it seems Feb 14 16:17:34 The idea is that it's flexible and extensible, so that "sounds" good Feb 14 16:19:10 This seems to be the "home app" they're using? written in EnactJS: https://github.com/webosose/com.webos.app.home Feb 14 16:20:13 Service for notifications: https://github.com/webosose/notificationmgr and the app: https://github.com/webosose/com.webos.app.notification Feb 14 16:20:15 for IVI it's quite a special case, as you often want only one full screen app Feb 14 16:29:39 Tofe: Yeah but according to the slides, LSM should be flexible to deal with different cases Feb 14 16:29:47 Question is of course how flexible it is Feb 14 16:49:54 codepoet: Your issue on Tenderloin is really weird Feb 14 16:56:43 anything else i can do to troubleshoot? Feb 14 16:57:03 You would almost expect there's some issue with the binary somehow that does the extraction Feb 14 16:57:07 It might be an idea to do a md5 or sha256 hash of the IPK on both Tenderloin and Hammerhead and compare them? Feb 14 16:57:14 See if they are bit for bit identical Feb 14 16:57:31 I had this issue last week too with the IPK you provided Feb 14 16:57:37 i mean, they started out as identical. if they're not, its getting mangled in transmission Feb 14 16:57:46 However when I palm-packaged it myself it was working OK Feb 14 16:57:58 it was the same IPK from my dev box Feb 14 16:58:02 Ah OK Feb 14 16:58:14 Well I would do a md5 or sha256 sum to see if they are OK Feb 14 16:58:21 ok, i'll try Feb 14 16:58:47 If those hashes are identical it's another issue Feb 14 16:58:57 Otherwise somehow the IPK gets mangled Feb 14 16:59:11 i tried both adb push and scp Feb 14 16:59:14 It could be some specific CPU tuning that might cause issues Feb 14 16:59:30 But that would be really weird Feb 14 16:59:45 Since we use very generic CPU tunes for ArmV7 and Aarch64 Feb 14 17:00:31 It seems Tenderloin in general is not that stable, not really sure what's up with that Feb 14 17:00:48 Would be nice if the mainline kernel would come along sometime, so we could get rid of the frankenstein Android bits Feb 14 17:03:36 Herrie: hashes are identical after push Feb 14 17:03:46 Really weird then :S Feb 14 17:05:08 just re-tried the install command on both devices after confirming the hash. same result. hammerhead OK, tenderloin no luck Feb 14 17:06:27 i'll see if i can build the emulator and try that, just for a sanity check Feb 14 17:07:21 codepoet: Well the emulator image is online already Feb 14 17:07:28 But you can build it of course yourself Feb 14 17:07:38 Will take a while though due to x64 architecture, so lots of rebuilds Feb 14 17:08:02 is there a way to copy the appinstalld2 file from hammerhead to tenderloin? to make sure they're really running the same code? Feb 14 17:10:33 You could pull the binary from hammerhead and push to tenderloin Feb 14 17:11:23 where does it live? Feb 14 17:12:03 In /usr/sbin/appinstalld Feb 14 17:12:08 Should be a simple binary mainly Feb 14 17:12:08 thanks. Feb 14 17:12:12 Rest is config stuff Feb 14 17:12:34 whats the MACHINE type for building the Emulator 64 bit? the wiki has a blank page Feb 14 17:13:16 MACHINE=qemux86-64 bitbake -k luneos-dev-emulator-appliance Feb 14 17:13:21 thanks. Feb 14 17:14:01 hammerhead /usr/sbin contains only `appinstalld` not `appinstalld2` -- expected? Feb 14 17:15:27 Yes Feb 14 17:15:45 k Feb 14 17:19:55 appinstalld copied from hammerhead to tenderloin, running install command on tenderloin now just hangs... Feb 14 17:20:24 tried restarting it, then running ls-monitor -i com.webos.appInstallService -- that hangs too Feb 14 18:36:05 We missed the line where PACKAGECONFIG:webos = "compositor cursor-theme" won't actually activate these features on luneos Feb 14 18:36:10 for LSM Feb 14 19:12:24 codepoet: Weird really Feb 14 19:13:41 I don't have a tenderloin with me to test **** ENDING LOGGING AT Tue Feb 15 02:59:57 2022