**** BEGIN LOGGING AT Mon May 13 02:59:56 2019 May 13 07:51:13 Tofe: That's a good and clear start :) May 13 08:03:14 Morning May 13 08:03:15 Herrie: good :) May 13 08:11:32 Tofe: Is my understanding correct that if we want a service to be available with it's old name, let's say com.palm.telephony and it's new name com.webos.service.telephony we'd need to specify both names in the dbus service file? May 13 08:11:42 And then in the ACL bits duplicate everything basically? May 13 08:11:55 This way we could luna-send with old and new service name? May 13 08:18:12 Something like that; but I'm still not convinced that specifying multiple names in the DBus service actually works May 13 08:19:04 Well there's clear example in dbus documentation that do the same May 13 08:19:19 So I guess it does work May 13 08:19:22 but we do get warnings May 13 08:19:31 Yeah well that's maybe due to something else May 13 08:20:57 It's used everywhere in OSE, so I do hope it works :) May 13 08:21:20 Yes ;) May 13 08:35:48 For me the goal of this document is to clarify how ACG works in practice, to be able to map an error message to a probable fix May 13 08:36:45 And for example, in the second error message I extracted from our qemux86 image, I currently still don't know where to look for :) May 13 08:37:52 Yes that's very helpful because we have quite some services to migrate at some point May 13 08:40:44 I think I should also explain what each file is for May 13 08:42:05 Also, there are the "container" things, which I didn't include in the picture, because I don't necessarily understand them well yet May 13 08:42:53 Basically it's for handling generic launchers, like nodejs or qml-launcher, where the executable can take several identities depending on what is started May 13 08:52:37 Tofe: There's a little bit of documentation at http://webosose.org/develop/js-services/built-in-js-service/develop-configure-js-service/ May 13 08:52:43 But it's not very extensive either May 13 08:58:23 It's a start, I'll include the description of what the files are for in my document May 13 09:03:33 I'll ping the LG guys, maybe they have some internal migration doc they could share May 13 09:05:35 I'll ask about this error on their forum, too, to know a bit what it's talking about May 13 09:11:19 Doing a clean build locally to start fresh May 13 09:51:27 good timing, the glibc fix merged upstream invalidates 99% of sstate anyway May 13 09:51:46 :) May 13 11:12:20 JaMa: Getting this one on my build: https://bpaste.net/show/87542b88999f May 13 11:20:18 After a bb -c clean the same May 13 11:21:23 I've also seen this one on my machine, several times May 13 11:21:26 still unexplained May 13 11:24:33 When I do -c cleanall it seems to be fine May 13 11:26:03 "qtquickcontrols" is QtQuick 1, isn't it ? May 13 11:26:46 so one way of getting rid of the error is just to exclude it from our build: we don't need it. May 13 11:28:06 you need -c cleansstate May 13 11:28:30 clean is not enough and cleanall is too much (removes downloads) May 13 11:28:46 this error can happen from any qmake built component May 13 11:29:11 see https://bugzilla.yoctoproject.org/show_bug.cgi?id=1711 May 13 11:29:21 err https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434 May 13 11:29:56 and specifically for qt https://github.com/meta-qt5/meta-qt5/issues/187 May 13 11:45:54 JaMa: OK. Well I guess you'll fix it sometime in meta-qt5 May 13 11:46:14 Cleanall with my internet connection is not a problem ;) May 13 11:47:19 yes, I plan to debug it soon now when Yocto upgrade is at least partially merged @lg May 13 13:22:33 Tofe:On my local build with latest fixes, email app still behaves the same May 13 13:22:47 I guess I'm missing some LS2 permission fix you talked about locally? May 13 13:23:36 You said you did something to allow the permissions.. I.e. "May 11 19:58:56 I solved some by authorizing configurator for all output ls2 communication" May 13 13:47:01 Herrie: that should be fixed by your fix on the configurator role.d May 13 13:47:45 You have mail templates, right? May 13 13:48:37 i.e. you have mojomail-imap May 13 14:15:19 Tofe: How do I check if I have the templates? May 13 14:16:20 Seems that some of the other issues might have been solved by a DB8 bump in upstream May 13 14:16:22 Testing that now May 13 14:21:49 "opkg files mojomail-imap" then check locally that they are there (they should!) May 13 14:22:38 I don't remember which file exactly is used here by mail app May 13 14:23:03 Also I tested only on tissot May 13 14:25:49 Tells me it's not installed hmmz May 13 14:30:45 Hmmz it's in my packagegroup May 13 14:30:47 Weird stuff May 13 14:30:58 I'll just delete this VBox image completely and retry May 13 14:35:13 at least we found the issue pretty quickly this time :) May 13 14:37:13 Yes LOL May 13 14:38:49 Works now at least May 13 14:41:20 Great! May 13 14:42:07 Though I couldn't create an account with Settings :/ Did it work before? May 13 14:43:57 (an email account) May 13 14:44:43 I cannot add an account now May 13 14:44:55 When I click add account, I get an empty screen May 13 14:44:59 same for me May 13 14:45:17 I didn't analyze it; might be related to our activities issues May 13 14:45:24 Yes it seems so May 13 14:45:30 And service naming/ACG May 13 14:45:35 ok May 13 14:45:52 I.e. https://bpaste.net/show/6015bba86475 May 13 14:46:45 I wonder what "Service security groups" are ? just the api-permission groups ? May 13 14:47:33 I guess so May 13 14:47:47 It's weird because we have both filecache and configurator from OSE it seems May 13 14:48:26 but it doesn't where the call comes from May 13 14:48:41 +say May 13 14:48:53 could be accounts app May 13 14:48:57 which isn't in OSE May 13 14:49:28 ah no it's "filecache", didn't see it, sorry May 13 14:49:47 Well the DefineType call could come from some activity somehow May 13 14:49:54 Let me grep around the image a bit to see May 13 14:50:29 VKB is behaving as it should now at least May 13 14:53:42 Herrie: configurator and filecache are in OSE both, but still, we had to add authorizations in the output permissions of configurator to avoid errors... May 13 14:54:54 Tofe: It might be good to download the OSE image and to make sure we're not missing anything in /usr/share/luna-service2 folder May 13 14:55:01 Could be we somehow miss some files there May 13 14:56:11 Let me do that May 13 14:58:15 good idea May 13 15:03:46 Could be just 1 or a few missing files somehow May 13 15:20:25 Nothing really obvious it seems May 13 15:29:23 Found this one so far: https://github.com/webosose/activitymanager/commit/dd631ba54d8970545ccb284ee35bbcd11afb2441 May 13 15:45:23 well that'll fix the sleepd issue maybe May 13 16:22:06 Only other difference I spot is the order in the manifest.json files May 13 16:22:13 But that shouldn't matter really May 13 16:22:42 OSE has "apiPermissionFiles" first, we have it after the appID May 13 16:22:46 Which I think is more logical May 13 16:22:57 Normally such order is not important in JSON files May 13 16:23:05 But I didn't check the LS2 source code to confirm May 13 16:44:32 Tofe: PR-ed some minor updates that shouldn't hurt at least May 13 16:44:41 Might help up narrow down some of the issues May 13 16:47:29 P.s. the scroll in Accounts App doesnt work in VBox... I.e. I cannot scroll down to Skype account for example May 13 16:47:37 Haven't tested it on an actual device yet though May 13 16:47:45 Might be good if you could check it quickly on Tissot May 13 17:01:59 Herrie: scroll for account doesn't work in tissot either May 13 17:02:05 I think it's an old issue May 13 17:02:15 Herrie: PRs are ready for merge? May 13 17:04:39 Herrie: order doesn't matter, no May 13 17:15:16 Tofe: Yeah they're build & run tested on VBox May 13 17:15:27 Scroll worked at some point May 13 17:16:30 ok merge, thx May 13 17:16:49 For scroll, I remember we discussed it once, here May 13 17:21:45 mmh that might be something else May 13 17:33:44 huh... did we break adb on tissot?... May 13 17:35:05 Damn, seems so May 13 17:48:04 Might be some of the mainline changes or initscript ones May 13 17:48:25 yeah, I fear so May 13 17:48:31 Seeing the upstream changes to various OSE components, thinking about how to integrate these easily... May 13 17:48:33 I'm investigating May 13 17:48:55 Seeing that we forked OWO and not OSE, makes it more complicated. May 13 17:49:42 We could use upstream directly with some patches but for systemd we then would need to either add the file to recipe or bring back the initscripts May 13 17:49:48 Not a big fan of either May 13 17:50:30 Or we could somehow point the fork to OSE but I think that's technically not possible, or we need to reach out to GH support May 13 17:50:57 Alternatively we could rename current repos and re-fork from OSE. May 13 17:51:02 Any thoughts on this May 13 17:52:30 ah "tissot systemd[1]: Condition check resulted in Android Debug Bridge being skipped" May 13 17:54:24 I guess that we are stumbling on one of GH's current limitation May 13 17:55:22 re-forking from OSE would be the way, then add our old branches, and delete the old OWO fork... quite some fastidious work May 13 17:55:38 It probably can't even be scripted May 13 18:00:36 wth? "ConditionPathExists=/var/usb-debugging-enabled" was the culprit, somehow May 13 18:01:09 oooh /var is bind-mounted... May 13 18:04:33 looks like my firstboot copy of /var didn't go to its end, somehow. May 13 18:07:16 I've added an addition error log in ls-hubd that should help us May 13 18:08:00 now, just after some cryptic "ls-hubd LSHUB_NO_NAME_PERMS {} Can not find match for 'org.webosinternals.tweaks.prefs' in pattern queue '["org.webosports.settingsservice", "org.webosports.service.settingsservice", "org.webosports.service.attached" May 13 18:08:30 we'll get this: ls-hubd LSHUB_NO_OUT_PERMS {"DEST_APP_ID":"org.webosinternals.tweaks.prefs","SRC_APP_ID":"com.palm.db","EXE":"/usr/sbin/mojodb-luna","PID":1347} "com.palm.db" does not have sufficient outbound permissions to communi (<-- line was truncated in /var/log/messages) May 13 18:10:55 and we now get https://paste2.org/42ceUU8X May 13 18:11:02 much more useful :) May 13 18:11:10 I think I'll PR that to OSE May 13 18:15:43 Yes May 13 18:16:00 But they don't seem to merge much PRs at all May 13 18:16:07 Something we should raise with them May 13 18:16:25 Maybe they did internally but no sign of this on GitHub May 13 18:16:45 This is what ka6sox was afraid for already last year May 13 18:17:06 There doesn't seem to be a strategy/process in place still after 1 yr+ May 13 18:17:16 Yes, a multi-layered thing, with no useful public visibility May 13 18:17:29 Yes May 13 18:17:39 Something should improve there May 13 18:17:49 Yup. May 13 18:18:04 Maybe things will go quicker now they're on Thud internally, but I doubt it. May 13 18:18:31 In the meantime: https://github.com/webOS-ports/luna-service2/pull/7 May 13 18:18:32 :) May 13 18:19:05 It's more a process issue than a yocto version issue, I fear :) May 13 18:24:51 Yeah I fear so too May 13 18:25:45 I understand that the OSE people are willing to simplify, but they're not the only ones to decide at LG... May 13 18:26:29 And being actually "open" probably isn't a top-level goal at exec level May 13 18:27:25 Anyway. May 13 18:51:28 Yup well but can raise it anyway ;) May 13 19:04:59 Tofe: Herrie: reforking the repos would break all older builds (if someone needs to recreate older release for whatever reason) so I'm not big fan May 13 19:05:22 JaMa: I'm open for suggestions ;) May 13 19:05:54 AFAIK we cannot point to another upstream ? May 13 19:05:55 is it only to be able to create PR from our fork to webosose? May 13 19:06:16 Well also to pull in commits from upstream May 13 19:06:36 to pull locally you can jsut add another remote May 13 19:06:50 We now have some fixes in OSE which I manually pull as patches, apply and push to our repo May 13 19:06:51 even without any common commits, the webosose history is so short that it doesn't matter much May 13 19:07:02 Which is not ideal of course May 13 19:07:25 pull as patches? May 13 19:07:38 with 2nd remote you can cherry-pick or pull them directly May 13 19:08:17 or rebasing our changes on top of webosose master in separate branch is also fine with me May 13 19:08:31 Well today I went to the commits, added .patch, downloaded, git am-ed the patches and pushed it to our repos May 13 19:08:51 It were about a hand full so not a big issue but going forward not an optimal approach May 13 19:08:53 that's much more complicated that it needs to if you just add the git remote May 13 19:09:38 But we cannot have the separate branch point to a different remote on GH right? Only locally May 13 19:09:41 gtg, wife wants to watch GoT May 13 19:09:54 Unless GH can do some magic behind the screens? May 13 19:09:56 yes you can on GH May 13 19:10:11 you just won't be able to create PR from that May 13 19:10:39 Let me raise it with GH support themselves, maybe they have some idea May 13 19:24:32 Ok submitted **** ENDING LOGGING AT Tue May 14 02:59:57 2019