**** BEGIN LOGGING AT Mon May 25 02:59:57 2020 May 25 08:04:09 Morning! May 25 09:04:14 Morning! May 25 09:16:26 Tofe: Wrapping up some last changes and I'll start PR-ing a whole bunch of things probably later today May 25 09:18:14 ok, great, we see the end of this first wave :) May 25 09:29:58 I think we're in pretty good shape, we'll do some more testing with these minor fixes :) May 25 10:08:11 https://pastebin.com/SGAyQ2zj May 25 10:08:20 Tofe: This is the one I was referring to for local files: May 25 09:58:55 qemux86-64 LunaAppManager[476]: XMLHttpRequest: Using GET on a local file is dangerous and will be disabled by default in a future Qt version.Set QML_XHR_ALLOW_FILE_READ to 1 if you wish to continue using this feature. May 25 10:08:32 linux-xiaomi-land-3.18.31+gitrAUTOINC+aad1958e0b-r0 do_compile: Execution of '/home/hextreme/Arc/mi-env/webos-ports/tmp-glibc/work/land-webos-linux/linux-xiaomi-land/3.18.31+gitrAUTOINC+aad1958e0b-r0/temp/run.do_compile.423527' failed with exit code 1: May 25 10:08:51 error msg is in above pastebin link May 25 10:09:29 * BT40 says hello to everyone May 25 10:14:22 BT40: Hi it seems that this is an error with the kernel somehow.... May 25 10:14:59 Let me check our other Xiaomi kernels May 25 10:27:55 YOu might want to revert this change: https://github.com/kskarthik/android_kernel_xiaomi_msm8937/commit/f70f32699205f5ee7210bbf676820d976e51a531 May 25 10:29:06 Simply edit the file in /tmp-glibc/work/land-webos-linux/linux-xiaomi-land May 25 10:29:21 There you be a longer folder name in there, then a git folder May 25 10:29:33 Update the Makefile in that folder May 25 10:29:59 Then do a "MACHINE=land bb -f linux-xiaomi-land -c compile" May 25 10:30:07 This way you'll just check the compilation of the kernel May 25 10:31:04 in that commit, one ligh is highlighted read and there is minus sign in front of it. Do i need ro peplace that line with having plus sign? May 25 10:31:14 *ligh=line May 25 10:31:21 read=red May 25 10:41:40 My files content are similar to green highlighed one when viewed in split mode May 25 10:43:00 My file -Werror keyword. This is highlighted in github as green May 25 10:43:23 Other one red highlighted just miss this one keyword only May 25 10:43:38 so i am confused, please guide which one to implement May 25 10:45:04 also this line is found in error: error: ignoring attribute 'noreturn' because it conflicts with attribute 'const' [-Werror=attributes] May 25 10:45:26 should i remove werror word? May 25 11:04:56 again failed: Here is the log (I removed werror word this time in make file) May 25 11:05:04 https://pastebin.com/bdFDMTt6 May 25 11:11:54 BT40: I'm not sure, it seems also an issue in the WLAN bits May 25 11:12:02 source/drivers/staging/prima/CORE/VOSS/src/wlan_nv_template_builtin.c:590:10: error: initializer element is not computable at load time May 25 11:12:02 590 | (((char *)&(nvDefaults.tables.hwCalValues.calData.psSlpTimeOvrHdxLNA5G) + May 25 11:12:02 | ^ May 25 11:13:47 Seems you might need this fix in your kernel: https://github.com/Tofee/android_kernel_xiaomi_msm8953/commit/c6be5e8f275d42a6de93607868a6c384bfec1e35 May 25 11:15:02 This is what we have in Tissot kernel for newer GCC versions May 25 11:16:06 BT40 if you push your changes to meta-webos-ports and meta-smartphone as well May 25 11:16:16 I can have a quick look on my builder May 25 11:24:18 Tofe: Hmmz my lists in FirstUse remain empty and no clues in logs :S May 25 11:30:01 Let me do a new build with all the minor fixes included May 25 11:42:08 seems build is successful. can you guys please confirm? Here is output of command May 25 11:43:00 https://pastebin.com/F19iijRQ May 25 11:54:24 BT40: yes, your build of the kernel seems alright; however this is only the compile step, if you want the whole package it'll be done with "bb linux-xiaomi-land", without any "-c compile" option May 25 11:56:23 i have started command bb luneos-dev-package May 25 11:56:34 will it automatically do rest? May 25 11:57:00 or manually do bb linux-xiaomi-land May 25 11:58:24 also is there any fix so that next time i do not face this issue, i mean instead of fixing tmp-glibc, i should fix before running main command of bb linux-xiaomi-land May 25 12:23:57 BT40: Yes it will do the rest May 25 12:24:43 Just push your changes to github and update the srcrev in linux-xiaomi-land with the reference of your pushed commit May 25 12:45:56 Tofe: I do see some of these: 2020-05-25T12:44:43.022631Z [10.604872424] user.err luna-next [] LS_INVALID_HANDLE {"COND":"sh != NULL","FUNC":"_LSCallFromApplicationCommon","FILE":"callmap.c","LINE":1818} sh != NULL: failed May 25 12:46:01 Which might be the cause somehow? May 25 13:08:56 Tofe: Image is on the usual location in case you want to have a look May 25 13:11:35 Tofe: Ah I see this in journal: May 25 12:49:40 qemux86-64 LunaAppManager[409]: Preferences::getPreferencesCallback(): toString -> [{"serviceName":"com.palm.systemservice","returnValue":false,"errorCode":-1,"errorText":"com.palm.systemservice is not running."}] May 25 13:11:37 That explains May 25 13:11:47 Let me debug that May 25 13:24:22 Tofe: hmmz it seems it somehow only registers com.webos.service.systemservice and not com.palm.systemservice even though I specified that name as well... May 25 13:24:37 ls-monitor -i com.palm.systemservice gives me no reply May 25 13:32:41 Hmmz this seems a bit random... Some of the services which have multiple dbus names are fine, some not.... May 25 13:32:48 Let me see if I can see some pattern May 25 13:36:22 I can of course change the calls into com.webos.service.systemservice, but both should normally work just.. May 25 13:47:36 Tofe: You know of any way to see which dbus names are registered? Seems somehow the dbus registration doesn't always work when multiple names are provided May 25 14:01:55 ok, back, just had to walk 2h to change the battery of my watch, which has been dead for 2 months now :) May 25 14:03:50 Tofe: hehe, I usually do those myself ;) May 25 14:03:54 LS_INVALID_HANDLE {"COND":"sh != NULL" basically means that the LSRegister failed for a reason or another May 25 14:03:54 But can be tricky sometimes May 25 14:04:44 The weird thing is it seems a bit random... THere are multiple services we register with multiple names, but for some it works fine and for some not May 25 14:04:50 I just cannot seem to figure out why May 25 14:04:53 location-service is fine May 25 14:05:06 luna-sysservice & luna-webappmanager not for example May 25 14:05:16 They work for their org.webosports variants but not the com,palm ones :S May 25 14:05:31 for luna-next, I already debugged it when debugging the wallpaper: it's the call to "setPreferences" which happens before the LunaService has been initialized May 25 14:05:36 I didn't see anything really obvious in the sysbus files May 25 14:05:55 I should add a check before actually doing the call May 25 14:06:09 Tofe: OK so that could simply be a systemd startup order issue as well May 25 14:06:56 I mean things mostly start in OK order nowadays but could be we need some tweaking here and there still May 25 14:07:11 I know I did quite some work a long time ago to clean that up May 25 14:07:22 But of course could be it needs some minor tweaking May 25 14:07:33 No it's just a QML issue, the signals "onxxxxChanged" are called very soon, even before the service is intiialized: https://github.com/webOS-ports/luna-next-cardshell/blob/master/qml/LunaSysAPI/Preferences.qml#L42 May 25 14:08:03 Ah OK, so it's QML specific May 25 14:08:09 for that one, yes May 25 14:08:30 I'll reword it a bit to have it behave properly May 25 14:09:04 rework* May 25 14:09:09 OK great May 25 14:09:24 Check if available, if not retry in 1s ? May 25 14:10:22 just ignore the call; we don't want to set the preferences before they have been read May 25 14:10:51 Makes evne more sense :D May 25 16:59:45 Tofe: PR looks good May 25 17:00:12 You have any thoughts as to why some services don't want to register under multiple names? May 25 18:12:22 Tofe: OK for FirstUse found the cause probably: I guess if they hardcode the servicename like this, it won't work with com.palm variant? https://github.com/webOS-ports/luna-sysservice/blob/webOS-ports/webOS-OSE/Src/Main.cpp#L229 May 25 18:12:44 No... if I understood correctly, LS2 is fine (registered with several names), but DBus doesn't activate the service ? May 25 18:14:14 Tofe: Well it's weird.. Some work OK some not when they have multiple names in .service file name tag May 25 18:14:16 Herrie: if the service is only registered with this name, then yes, the com.palm won't be accepted... I think May 25 18:15:29 But it looks like I'm wrong, if I read you correctly May 25 18:16:17 It probably has something to do with compat.api.json and compat.perm.json SOMEHOW but that's again not very documented it seems May 25 18:16:47 I mean if I do this it works: https://github.com/webOS-ports/org.webosports.app.firstuse/commit/1e1615221c77c5a33b397d09960bd20603f4144e May 25 18:17:07 But I don't recall if I had a changed FirstUse in my previous builds and I deleted those :S May 25 18:17:32 I have a tissot with a previous build ;) ;) May 25 18:17:43 Ah ok May 25 18:17:55 So you can check the FIrstUse QML files for what's being called there May 25 18:18:01 yep, one moment May 25 18:18:51 CountryPage.qml for example May 25 18:18:57 service.call("luna://com.palm.systemservice/getPreferences", JSON.stringify({ May 25 18:19:10 so it *was* working fine without the change May 25 18:19:40 What did you change since then ? everything ? :p May 25 18:20:18 I mean I have the whole rootfs, we can compare usr/share/luna-service2 directory if you want May 25 18:22:25 Tofe: Yeah that might be good May 25 18:22:29 I changed a LOT May 25 18:23:05 I uploaded a tgz of the whole dir on your ftp May 25 18:23:09 Great May 25 18:28:47 ah, did you maybe update your luneos-component with the new QML LunaService ? The one that doesn't do LSRegisterPubPriv anymore May 25 18:29:36 It could be that there is a subtil "com.palm" change of behavior with the old PubPriv API May 25 18:33:14 from LS2 source code: // If we're looking for a service substitute (com.palm -> com.webos.service), avoid checking inbound/outbound lists, because they're likely to be broken. API will be restricted with ACG only. May 25 18:34:58 Herrie: I think I found an interesting piece of code in LS2 May 25 18:35:06 let me find a link from GH May 25 18:35:39 https://github.com/webosose/luna-service2/blob/master/src/ls-hubd/hub.cpp#L134 May 25 18:36:18 ah, wait, we already patch that method to include our patterns too :) May 25 18:37:56 It looks like our patch does only half the job (new client -> old services, but not old client -> new services) May 25 18:44:42 Tofe: Yes I did May 25 18:44:59 Update LuneOS components May 25 18:45:58 Then it might just be that May 25 18:46:36 New client (LSRegister, no pub/priv) --> no api migration on the fly May 25 18:49:51 Ah OK that might explain then.... May 25 18:56:41 Any ideas how to work around that? Not clear from ls2 code to me May 25 18:58:50 for firstuse, your fix is the right one May 25 19:08:55 Tofe: OK so this should only affect bits using LuneOS Components right? So mainly our QML applications? May 25 19:10:07 If I understood correctly the lsregisterpubpriv did the legacy lookup bits and lsregister not? May 25 19:11:05 Would a possible (interim) solution be to add a LSRegisterLuneOS in LS2 that registers like LSRegister but also does the API migration? May 25 19:11:57 Because I foresee that when we fix the pub/priv registration in other areas we'd might get headaches otherwise May 25 20:33:51 Tofe: I think we need it.... May 25 20:34:05 https://bpa.st/I5KA May 25 20:34:37 That's with the LSRegister change instead of pub/priv May 25 20:40:08 I have about 40-45 files (JS and QML) referencing com.palm.systemservice ... May 25 20:41:48 Not even talking about other calls ;) May 25 21:06:34 Sorry, was diner timer May 25 21:06:49 yes, to your questions about qml apps May 25 21:07:54 for API migration in QML, we can probably fairly simply put some migration code in the QML LS2 adapter May 25 21:10:15 https://github.com/webOS-ports/luneos-components/blob/master/modules/LuneOS/Service/plugin/lunaserviceadapter.cpp#L523 here, we could process "uri" and migrate it if needed May 25 21:58:00 I think we should implement this backwards compatibility bit for now because a lot of things broke May 25 21:58:24 Where's the right place I leave up to you May 25 21:59:01 I guess easier if it's something that doesn't get changed by upstream **** ENDING LOGGING AT Tue May 26 02:59:57 2020