**** BEGIN LOGGING AT Fri Nov 09 02:59:58 2018 Nov 09 09:32:01 morning all, happy Friday.. Nov 09 13:17:53 Morning Nov 09 13:18:09 novaldex: Do you know how those legacy preware feeds are generated? I think it was on some other builder Nov 09 13:18:18 There is a jenkins job but it's not working properly Nov 09 13:18:25 On our current builder Nov 09 13:19:39 hey Herrie, off the top of my head I can't think, but I know there's been so many changes underneath I doubt things are where they were Nov 09 13:20:01 wouldn't be surprised if they haven't been run in ages, either automatically or manually.. Nov 09 13:20:12 is there a need to update specifically? Nov 09 15:55:16 Herrie: ok; thanks for merging PR btw. Nov 09 15:57:52 novaldex: it was me requesting rebuild for this PR: https://github.com/webos-internals/build/pull/41 . dbus alpha status really causes confusion for people trying new browsers on legacy webOS. Nov 09 15:59:18 hey nizovn, okay i'll see what I can find out for you Nov 09 15:59:26 thanks! Nov 09 19:17:00 I thnk I begin to understand why our mojoservice-based service doesn't work well with OSE Nov 09 19:19:25 On one hand, we have https://github.com/webosose/mojoservicelauncher/blob/e32e7172003f77a0e6a6973405c18145fc225a16/bootstrap-node.js#L64 which leads to https://github.com/webosose/nodejs-module-webos-sysbus/blob/8aca2d80a485a26d5d8770dd8771dec3f2c95f37/src/node_ls2_handle.cpp#L382 Nov 09 19:21:05 But then, when mojoservice creates its Handle, the nodejs module tries to guess what app we are currently on. This is done here: https://github.com/webosose/nodejs-module-webos-sysbus/blob/8aca2d80a485a26d5d8770dd8771dec3f2c95f37/src/node_ls2_handle.cpp#L412 and is based on the backtrace (which is a strange idea, but well) Nov 09 19:22:08 The issue being that the Handle is create by mojoservice itself, during its initialization: the app has *not* been started yet. So there's no "com.palm.service.accounts" in the backtrace, and the check fails to find the appId. Nov 09 19:36:21 Tofe: https://github.com/webosose/nodejs-module-webos-sysbus/issues/2 ? Nov 09 19:38:05 EricBlade: that's related, but even worse for mojoservice: the service path isn't in the backtrace at all Nov 09 19:40:49 but yes, the "findMyAppId" method should be more flexible and only verify that the beginning of the path matches Nov 09 19:42:04 aarg "LSHUB_NO_ROLE_FILE {"APP_ID":"com.palm.service.accounts"} No role file for application id: "com.palm.service.accounts" " Nov 09 19:43:28 i think you also get that message if the role file is not totally correct, also Nov 09 19:44:20 i can't speak too much for mojoservice, but i'm pretty sure there are some services on tv devices that use it, so it.. should? work? i think? unless the whole permissions system is just broke af Nov 09 19:45:07 mojoservice is still using Pub/Priv LS2 handles, so it doesn't go in the same C++ branches Nov 09 19:46:26 I've modified it a bit so that it creates the new kind of Handle, because I suspect the deprecated Pub/Priv doesn't work so well any longer for services -- but not 100% sure Nov 09 19:46:46 i don't think the ACG works at all for services Nov 09 19:47:29 at least it doesn't appear to work for webos-service using services. https://github.com/webosose/nodejs-module-webos-sysbus/pull/1 Nov 09 19:48:10 EricBlade: but... there are already some services using it, like devmode or rosbridge? Nov 09 19:48:53 though the former is more a oneshot service, and the latter I don't really know its status Nov 09 19:49:03 i was questioning if there's really any effect there at all, of using the new registration vs the old registration. Nov 09 19:49:57 EricBlade: mostly coverage :) The old registration is like to be less and less tested, and could break without LG noticing Nov 09 19:50:00 someone confirmed my suspicions that the ose processes are basically a giant mess: https://github.com/webosose/mojoservicelauncher/pull/1#issuecomment-437402124 Nov 09 19:50:42 Tofe: well, in the current case for what's in use on devices right now, node services using webos-service are *all* going down the old registration path Nov 09 19:51:12 because of the error i fixed in that pull request, which i tried to get solved internally, but is also sitting in "no one is reviewing" code land Nov 09 19:52:40 going down the old registration path isn't an urgent issue imho, but I wanted to know what effort it would be to make accounts work with ACG instead of debugging the old path Nov 09 19:53:10 Now I know: quite a lot :) Nov 09 19:53:41 i wouldn't expect there to be, except i don't fully understand what you're saying about mojoservice Nov 09 19:55:19 what i did while i was trying to debug a completely different problem (which I suspect may exist in OSE but no one is interested in figuring it out, and I don't have an OSE device to test it with) was added a cout to basically every function in node_ls2_handle to see what all the data going around was Nov 09 19:55:25 In mojoservice, we have https://github.com/webOS-ports/mojoservice-frameworks/blob/webOS-ports/master/mojoservice/javascript/method_dispatcher.js#L11 which calls the old path Nov 09 19:56:10 so in LS2Handle::findMyAppId I did a cout << scriptName << eol << scriptDirectory << eol; or some such Nov 09 19:56:54 EricBlade: I didn't try that yet; but I suspect there always is only one appId registered at most Nov 09 19:58:35 i would suggest adding some output to at least findMyAppId and SetAppId to see what's going on there Nov 09 19:59:41 because the mojoservice should have somewhere at one end or the other of it's backtrace, inside the accounts service Nov 09 20:01:27 EricBlade: for a service it's pretty straightforward I think: run-js-service adds a map { service_dir:/usr/palm/services/com.palm.service.accounts, appId:com.palm.service.accounts }, and findMyAppId browses the backtrace, which only holds mojoservice stuff (@see https://bpaste.net/show/058855b64b41 ) Nov 09 20:04:59 i think there may be more things included in the internal data than the error output provides, but i could be wrong. Nov 09 20:06:13 Could be, I didn't look so carefully on that side Nov 09 20:06:45 i didn't trace specifically through the path here https://github.com/webosose/mojoservicelauncher/blob/e32e7172003f77a0e6a6973405c18145fc225a16/bootstrap-node.js#L108 Nov 09 20:07:37 but when i did trace through the path right above it (package.json vs sources.json) i was able to see my service directory in findMyAppId Nov 09 20:10:37 what's the directory that 3rd party apps and services are installed to? i forgot, it's only been like 6 years since i've been a 3rd party :| Nov 09 20:12:34 EricBlade: I... don't know Nov 09 20:13:32 But here with accounts service, based on sources.json, I don't have the path in my backtrace Nov 09 20:13:52 which is logical, considering how mojoservice works Nov 09 20:14:43 so, i think if you want to get accounts working, you should check out for sure what's going on in findMyAppId, and if there's a problem there, then that's a pretty significant problem :| Nov 09 20:14:55 also what do you have for your role file for it? Nov 09 20:15:53 I've put in place this: https://bpaste.net/show/3ede7b7fb166 Nov 09 20:16:45 It's my very first ACG role file, so the probability I screwed up is high Nov 09 20:17:27 I think that you want to remove the "role" wrapper, otherwise it looks right based on my notes from the service i'm working on Nov 09 20:17:42 it is possible that my notes are wrong, though, because frankly, no one here understands what's going on either :-D Nov 09 20:18:36 :D Nov 09 20:19:23 I'll look into it, and compare with the existing ACG role files in that folder Nov 09 20:19:33 my notes indicate that when i used { appId, allowedNames, type, permissions } is when the bus started enforcing permissions strictly Nov 09 20:19:56 you're right ! Nov 09 20:20:57 It's a shame I didn't get any schema error; or at least I didn't spot it Nov 09 20:28:01 nope, I must have made other mistakes too Nov 09 20:29:42 mmmh I'm the only ACG service role (i.e. with appId and no exeName) around here... Nov 09 20:30:39 did you reboot after? i have suspicions that lscontrol doesn't really work right or well, but i haven't tested for sure. Nov 09 20:33:03 yep Nov 09 20:36:17 it does look like ls-hubd isn't even trying to load my role file Nov 09 20:37:22 that one i'm not too familiar with. i see tons of the "LSHUB_NO_ROLE_FILE" errors on a device, so i've assumed that the error message is incorrect. Nov 09 20:38:50 on my side it's not bad: just LSHUB_NO_ROLE_FILE for keymanager and another for the accounts service Nov 09 20:39:39 oooh wait, my filename is also incorrect Nov 09 20:39:54 it's "blabla.role.json", not "blabla.json" Nov 09 20:44:41 nope, still nothing :( Nov 09 20:52:15 mmh do I need a manifest file ? Nov 09 20:52:19 here's my structure Nov 09 20:52:19 https://imgur.com/a/IqFEEI9 Nov 09 20:52:50 thanks; I think I'm missing some of those Nov 09 20:59:13 I've added a manifest, let's see... Nov 09 20:59:27 manifest looks like it should have { id, serviceFiles: [], clientPermissionFiles: [], roleFiles: [], version, apiPermissionFiles: [] } Nov 09 21:00:11 ah, oops, I just left id, version and roleFiles. Adding back the other empty arrays will be the next step then Nov 09 21:02:21 yay ! it does look like the service has started Nov 09 21:03:33 yeah the other arrays should all point to the other permissions files Nov 09 21:05:13 ok well, so at least that's a begninng. And a funny thing is that the manifest doesn't seem to be present at all for that service; maybe that's also why the deprecated code didn't work either Nov 09 21:06:09 yep, no manifest at all. Doesn't help at all, I guess. Nov 09 21:06:35 Is it a new thing? Nov 09 21:06:48 i think so? Nov 09 21:08:18 mmh I have a manifest for keymanager -- I'll have to check if that was migrated or not Nov 09 21:09:42 serviceFiles should point to your .service file, clientPermissionFiles to your .perm.json, roleFiles to your .role.json, and apiPermissionFiles to your .api.json Nov 09 21:10:01 ... now, i made up all of those extensions for myself, except for '.service'. they all have to end with .json Nov 09 21:10:08 (except for .service) Nov 09 21:10:33 I see; yes with the manifest, it all fits together Nov 09 21:10:35 i was intending maybe on building a VScode schema checker for those, so they needed unique extensions Nov 09 21:11:01 and they're all arrays not individual strings Nov 09 21:11:48 ok, for app-services recipe we don't reuse the classes from OSE, so the manifest can't be generated automagically like for keymanager Nov 09 21:12:41 i also did the same thing with my files in db/kinds and db/permissions and activities, added my own bit to the extension .. makes it much easier to find in editor, and adds potential for schema validation Nov 09 21:12:58 Yes, that's a good idea Nov 09 21:13:09 so i have (myActivity).activity.json and (myservice).data.db8kind.json Nov 09 21:14:25 Anyway, thank you for your inputs, in the end I think we cracked the case :) Nov 09 21:14:43 woo! so maybe there's not a problem in the mojoservice case Nov 09 21:15:04 i'm glad i was useful here for once! you just happened to go right through the same area i spent a few days debugging :) Nov 09 21:15:16 well it could be that accounts work well, as soon as we generate the required files (mainly manifest) Nov 09 21:16:19 I'll reflash the device to erase my hacks and try to have bitbake generate the manifest for me :) Nov 09 21:16:54 what class does that? i recall seeing something about generation of something or other being deprecated, but i don't remember what Nov 09 21:17:08 I suspect webos_system_bus does it Nov 09 21:17:25 with the help of WEBOS_SYSTEM_BUS_FILES_LOCATION Nov 09 21:17:41 but I still need to check that Nov 09 21:18:35 bbwarn "$pkgname: Installing roles and services files from bitbake is deprecated - use cmake, qmake, etc." Nov 09 21:18:44 yeah that's what i was thinking of Nov 09 21:19:19 oh. :) Nov 09 21:20:34 meta-webos/classes/webos_configure_manifest.bbclass Nov 09 21:20:52 yes, I'm browsing that one right now Nov 09 21:20:59 it does look appealing Nov 09 21:21:07 why don't they want us to use it... Nov 09 21:21:52 i think that might be different from WEBOS_SYSTEM_BUS_FILES_LOCATION Nov 09 21:22:03 possibly Nov 09 21:22:48 so we install the roles and services files ourselves, and the bbclass does the rest Nov 09 21:23:19 it does look like it's inherited by webos_system_bus .. Nov 09 21:23:52 i don't see obviously how configure_manifest works, it's a large chunk of python and i haven't read python in quite a while Nov 09 21:24:26 "addtask configure_manifest after do_install" Nov 09 21:25:02 so it looks in the installed files, checks for role and service files, and creates a manifest pointing to that Nov 09 21:28:22 i'll take your word for that. Nov 09 21:29:02 i see one recipe we have other than systembus that uses it, but it doesn't specify a WEBOS_SYSTEM_BUS_MANIFEST_TYPE which looks to be the first requirement to get it to work, if I'm reading this right Nov 09 21:29:39 the type is "PACKAGE" by default Nov 09 21:30:05 oh. geez. yeah ok Nov 09 21:30:49 so it does look like you can just import that, or import system_bus, and run with that Nov 09 21:31:07 i didn't use system_bus in mine, because of the deprecation warning, so i'm just installing a manifest directly Nov 09 21:31:19 yes needs a few tuning still, like having .role.json extension Nov 09 21:32:09 if lookup_files_by_ext works with the last "." then that should work already it looks like Nov 09 21:32:38 ah yes, but I specified the "SERVICE" type Nov 09 21:32:53 I'm not sure if that really changes anything here Nov 09 21:33:31 oh, ok, configure_manifest_service does .role.json .api.json and .perm.json Nov 09 21:33:32 nice! Nov 09 21:34:34 https://bpaste.net/show/165abb0b2ab8 nice Nov 09 21:34:53 that's with default type, not SERVICE Nov 09 21:35:10 looks pretty much completely fine to me Nov 09 21:35:53 worth a try at least Nov 09 21:36:38 (could it be this whole accounts issue is just a one-liner fix with "inherit webos_configure_manifest" ?... ) Nov 09 21:37:00 let me reflash all that stuff. Nov 09 21:41:42 i thought you were trying to update to use acg Nov 09 21:42:07 but, yeah, that's great that it looks like it grabs everything Nov 09 21:43:10 EricBlade: Ideally I'd like to do it in two steps: have a system rebased on OSE that works, and then migrate all the things to ACG Nov 09 21:45:42 makes sense. Nov 09 21:49:59 ok, it's much better Nov 09 21:50:11 I'm just lacking some API permissions Nov 09 21:50:30 LS_REQUIRES_SECURITY {"SERVICE":"com.palm.service.accounts","CATEGORY":"/","METHOD":"stayRunning"} Service security groups don't allow method call Nov 09 21:51:49 but accounts is running, so for me that's quite good already Nov 09 21:53:13 Let's stop here for today :) **** ENDING LOGGING AT Sat Nov 10 02:59:59 2018