**** BEGIN LOGGING AT Fri Apr 06 03:00:01 2018
Apr 06 05:58:30 <Herrie> Morning
Apr 06 07:31:34 <Herrie|Laptop> Morning!
Apr 06 07:51:52 <Tofe> Morning!
Apr 06 08:07:46 <Herrie|Laptop> Tofe: You saw my comments from yesterday evening
Apr 06 08:08:02 <Herrie|Laptop> I guess I need to have a look into the systemd services now because db8 doesn't get started somehow
Apr 06 08:08:14 <Herrie|Laptop> Could be I forgot something minor in the webos-initscripts somewhere
Apr 06 08:18:58 <Herrie|Laptop> Tofe: Still a bit unsure how the files ended up in the /usr/share/ls2/roles/prv and pub folders but well
Apr 06 08:19:34 <Herrie|Laptop> Simply deleting them in the do_install_append with rm -rf ${D}${webos_sysbus_prvrolesdir}/com.webos.* and rm -rf ${D}${webos_sysbus_pubrolesdir}/com.webos.* does the trick for now at least
Apr 06 08:23:47 <Tofe> Well I still have the prv/pub folder on my side, with the same blocking consequences
Apr 06 08:24:17 <Tofe> And we do need these, to have a working access right
Apr 06 08:24:33 <Tofe> (well, we need the rules, either in old or new format)
Apr 06 08:25:08 <Tofe> It must be that the bbclass generating them is still the old one somehow for luna-sysservice
Apr 06 08:28:41 <Herrie|Laptop> Tofe: Well our bbclass is same as webOS OSE for this....
Apr 06 08:28:46 <Herrie|Laptop> So it's weird...
Apr 06 08:28:59 <Herrie|Laptop> But if you delete the old pub/prv it seems to work
Apr 06 08:29:09 <Herrie|Laptop> It seems that when both exist it causes problems
Apr 06 08:29:20 <Herrie|Laptop> Because both old and new existed for luna-sysservice
Apr 06 08:31:07 <Tofe> ok
Apr 06 08:32:41 <Herrie|Laptop> We use https://github.com/webOS-ports/meta-webos-ports/blob/herrie/webOS-OSE/meta-luneui/classes/webos_system_bus.bbclass which is the same as the webOS OSE one
Apr 06 08:33:01 <Herrie|Laptop> Only other inherit we have there is the webos_cmake where there might be a difference
Apr 06 08:33:03 <Herrie|Laptop> I didn't check that
Apr 06 08:33:34 <Herrie|Laptop> Just the webOS OSE code is a bit tricky with startup sequence because it uses the webos-initscripts which has different targets for systemd
Apr 06 08:33:56 <Herrie|Laptop> I.e.: https://github.com/webosose/webos-initscripts/tree/master/files/systemd/targets
Apr 06 08:35:10 <Herrie|Laptop> I guess I might just need to update https://github.com/webosose/webos-initscripts/blob/7447fc3c1b6bf31b327f87cfdd226f37cd9eb959/src/initctl/InitCtl.cpp#L26 and L30 as well for example
Apr 06 08:38:23 <Herrie|Laptop> Then there's also bootd (https://github.com/webosose/bootd) which emits signals etc it seems but which I didn't touch at all yet
Apr 06 08:40:54 <Herrie|Laptop> I can see it reaches default-webos.target i.e.: Apr 05 22:13:23 qemux86 systemd[1]: Reached target "default-webos.target".
Apr 06 08:41:00 <Herrie|Laptop> But it doesn't seem to reach the others
Apr 06 08:46:07 <Herrie|Laptop> Be back in a bit ;)
Apr 06 11:11:14 <Tofe> Herrie: one main blocking problem seems to be the manifest file, which is generated wrong for luna-sysservice (contains both old and new roles)
Apr 06 11:16:38 <Tofe> It's not enough though
Apr 06 11:21:01 <Herrie|Laptop> Tofe: Well yeah not sure how that happens, because the OSE one doesn't have it :S
Apr 06 12:23:26 <Tofe> ah, my UI started
Apr 06 13:08:12 <Herrie|Laptop> Tofe: Good, what did you do?
Apr 06 13:08:58 <Tofe> I cleaned up the manifest a little bit
Apr 06 13:09:19 <Tofe> on device
Apr 06 13:09:33 <Tofe> and waited... a long time... so that some ls2 calls expired
Apr 06 13:09:39 <Tofe> and then the UI came
Apr 06 13:09:52 <Tofe> but the LS2 doesn't seem to be very functional
Apr 06 13:11:04 <Tofe> Herrie: https://paste2.org/kzJhmLKM
Apr 06 13:17:17 <Herrie|Laptop> Tofe: AH OK
Apr 06 13:17:25 <Herrie|Laptop> Yeah with me it also took a while to get the UI
Apr 06 13:25:47 <Herrie|Laptop> Main issue now seems to be that it doesn't start DB8, configurator, activitymanager etc
Apr 06 13:25:56 <Herrie|Laptop> It's probably something I missed in the db8 migration
Apr 06 13:26:05 <Herrie|Laptop> Or with the systemd targets
Apr 06 13:26:18 <Herrie|Laptop> db8 changes in terms of services etc were quite some
Apr 06 13:28:48 <Herrie|Laptop> I.e. no db8-prestart.sh anymore and no db8@.service etc
Apr 06 13:32:57 <Herrie|Laptop> I guess need to run some systemd-analyze etc to see what's going on
Apr 06 13:40:19 <JaMa> Herrie|Laptop: should I merge https://github.com/shr-distribution/meta-smartphone/pull/67 ?
Apr 06 13:40:48 <Herrie|Laptop> JaMa: Yes please :)
Apr 06 13:41:12 <JaMa> Tofe: do we really need to do this in postinst? https://github.com/shr-distribution/meta-smartphone/commit/febdac3e8c21558bafec223948749ed3e17394dd
Apr 06 13:42:19 <JaMa> Tofe: my understanding is that you want to reflash the partition, but don't we need it already on the very first boot? i.e. isn't postinst executed a bit too late for normal 1st boot?
Apr 06 13:56:22 <JaMa> I've merged some small updates from pyro and retriggered the builds
Apr 06 13:56:33 <JaMa> now re-testing Sumo release with new bbclasses
Apr 06 14:19:19 <Tofe> JaMa: this would be needed on a kernel update on an existing system
Apr 06 14:19:39 <Tofe> but you're right, for initial flashing it's not needed
Apr 06 14:43:45 <Herrie|Laptop> Tofe: Seems I don't have db8.service on my device
Apr 06 14:44:15 <Herrie|Laptop> Which is due to https://github.com/webosose/webos-initscripts/blob/master/CMakeLists.txt#L128 I guess
Apr 06 14:44:54 <Tofe> oh. What new value would that be?
Apr 06 14:45:42 <Herrie|Laptop> Tofe: Well there's some explanation in: https://github.com/webosose/cmake-modules-webos/blob/832ec580a8628af9cb6eacea3e5f1db38001158d/REFERENCE.md
Apr 06 14:45:59 <Herrie|Laptop> I guess we could comment it out in the CMakeLists.txt or set the value ;)
Apr 06 14:46:22 <Herrie|Laptop> But that explains why I don't have DB8 after switching to new one ;)
Apr 06 14:46:30 <Herrie|Laptop> And other bits like configurator not working I guess
Apr 06 14:47:36 <Tofe> doesn't seem like it's defined at all
Apr 06 14:48:48 <Herrie|Laptop> Tofe: Yup
Apr 06 14:48:54 <Herrie|Laptop> JaMa: ^Any insights?
Apr 06 14:49:22 <Tofe> we have DISTRO_NAME="LuneOS"
Apr 06 14:51:36 <Tofe> For this recipe we could add WEBOS_TARGET_DISTRO="webos" to the CMake defines
Apr 06 14:52:01 <Herrie|Laptop> Tofe: Yeah I guess so, I'm testing now with quickly commenting it out, to see what that does
Apr 06 14:52:06 <Tofe> ok
Apr 06 14:52:31 <Herrie|Laptop> Ah that doesn't work :P
Apr 06 14:52:51 <Tofe> :/
Apr 06 14:53:43 <Herrie|Laptop> Because it checks a "none" directorty :P
Apr 06 14:53:53 <Herrie|Laptop> I guess simply adding the WEBOS_TARGET_DISTRO makes more sense :P
Apr 06 14:54:23 <Herrie|Laptop> Just to luneos.conf right?
Apr 06 14:55:27 <Herrie|Laptop> Seems it's used in more places anywya: https://github.com/search?p=1&q=org%3Awebosose+%22WEBOS_TARGET_DISTRO%22&type=Code&utf8=%E2%9C%93
Apr 06 14:55:28 <Tofe> no, I was thinking adding it in the recipe, to have a minimal impact
Apr 06 14:55:37 <Herrie|Laptop> Tofe: Well see above search ;)
Apr 06 14:55:40 <Herrie|Laptop> We might need it in other places
Apr 06 14:55:46 <Herrie|Laptop> Since we don't define it anyway it shouldn't hurt
Apr 06 14:55:53 <Herrie|Laptop> The other recipes aren't used by us yet
Apr 06 14:56:00 <Herrie|Laptop> But some will be quite sure in future
Apr 06 14:56:50 <Tofe> ok, let's try it then
Apr 06 15:04:10 <Herrie|Laptop> OK that didn't work
Apr 06 15:05:07 <Tofe> Neither did it here :p
Apr 06 15:05:21 <Tofe> " 5953 tasks of which 5953 didn't need to be rerun"
Apr 06 15:07:16 <Tofe> It only sees what's in the recipes, not what's used by CMake makefiles
Apr 06 15:10:16 <Tofe> mmh forcing a rebuild didn't work...
Apr 06 15:10:26 <Tofe> maybe it really has to be a define for CMake
Apr 06 15:10:51 <Tofe> I'll have to go, be back later
Apr 06 15:13:12 <JaMa> Herrie: WEBOS_TARGET_DISTRO is set to DISTRO when webos_distro_dep is inherited, see webos_cmake.bbclass
Apr 06 15:14:39 <JaMa> changing it to "luneos" (not "LuneOS" in the component repo or setting WEBOS_TARGET_DISTRO explicitly to "webos" in the recipe is ok
Apr 06 15:15:15 <JaMa> even better would be to not use webos-initscripts at all
Apr 06 15:15:28 <JaMa> and just use service files in the components (add them where missing)
Apr 06 15:53:14 <Herrie> JaMa: Well there are other things in webos-initscripts that we seem to need
Apr 06 15:53:28 <Herrie> So it's not as easy as simply picking & choosing service files it seems
Apr 06 16:06:33 <Herrie> Unless you have compeling reason not to use it ;)
Apr 06 16:14:46 <Herrie> Tofe: Adding EXTRA_OECMAKE += "-DWEBOS_TARGET_DISTRO:STRING='webos'" to the webos-initscripts recipe seems to at least bring the db8.service into IPK :)
Apr 06 16:25:35 <Herrie> Tofe: OK log looks slightly better
Apr 06 16:25:40 <Herrie> At least db8 stuff starting now
Apr 06 16:25:47 <Herrie> Still other issues due to new LS permissions.
Apr 06 16:25:59 <Herrie> https://bpaste.net/show/ee28a6516c62
Apr 06 16:52:07 <Herrie> JaMa: Any ideas about the hows and whys of https://github.com/webosose/meta-webosose/blob/master/meta-webos/lib/verify_ls2_acg.py
Apr 06 17:44:36 <JaMa> Herrie: what's wrong with lib/verify_ls2_acg.py? this part actually makes some sense unlike the other warnings you get from new acg
Apr 06 17:45:33 <JaMa> Herrie: db8.service still belongs to db8 recipe IMHO like all other service files webos-initscripts have enough issues in webOS OSE that it shoud die in fire already
Apr 06 17:46:16 <JaMa> yes, webOS OSE depends on it, but LuneOS is already better by not using it
Apr 06 17:53:11 <Herrie|TP> JaMa: What does acg stand for?
Apr 06 17:53:27 <Herrie|TP> At some points documentation is clear at others non-existing
Apr 06 17:54:20 <Herrie|TP> I don't doubt the usefulness of the script, seems to make sense, just not sure why it's there and what it does, since there seems to be no documentation.
Apr 06 17:54:55 <Herrie|TP> I don't have a RPi3 so I don't know what the issues with OSE are, so feel free to enlighten us.
Apr 06 17:57:23 <Herrie|TP> And with initscripts. I'm happy to move the .service etc files and scripts elsewhere. Just hacking initscripts looked like an easier way ;-)
Apr 06 17:58:22 <Herrie|TP> We don't know the design decisions or rational behind some of these components, so it's just guesswork for now :-P
Apr 06 17:58:46 <JaMa> Herrie|TP: access control group or something like that
Apr 06 17:59:18 <Herrie|TP> JaMa: OK I had something like that in mind just couldn't find it anywhere
Apr 06 17:59:41 <Herrie|TP> The script looks thorough and I'm OK to add it (have it locally already)
Apr 06 18:00:37 <JaMa> it's just verification for ls2 manifests used to secure ls2 bus
Apr 06 18:01:47 <JaMa> Herrie|TP: the issue with webos-initscripts is that it just bundles bunch of unrelated .service files for services for which you might not even have the component in the image
Apr 06 18:03:07 <Herrie|TP> JaMa: OK, yeah I noticed that it put the systemd files at a central place. In LuneOS I moved them all to components a while ago because that made more sense to me personally
Apr 06 18:03:46 <JaMa> using just systemd-machine-units for BSP specific bring-up scripts and then the service files delivered with components makes sure that whatever image you build you should get working systemd services for stuff installed there
Apr 06 18:04:33 <JaMa> yes webos-initscripts is just remnant from upstart days (sort of like upstart-machine-units which was misused for systemd migration)
Apr 06 18:05:49 <Herrie|TP> JaMa: OK so you say we're better off dropping initscripts?
Apr 06 18:05:56 <Herrie|TP> Can look into that
Apr 06 18:05:57 <JaMa> that's why there is that stupid WEBOS_TARGET_DISTRO inside, because webos-initscripts is used for different DISTROs which contain different services (and then other *-inistscripts recipes provide different (or new) service files on top of webos-initscripts)
Apr 06 18:06:08 <JaMa> yes, we should drop it
Apr 06 18:06:12 <Herrie|TP> OK
Apr 06 18:06:23 <JaMa> in LuneOS we've already dropped them, right?
Apr 06 18:06:28 <Herrie|TP> Not sure how things look in future OSE of course...
Apr 06 18:07:02 <Herrie|TP> JaMa: Well morphis out all systemd in a central repo, I moved them to where they belong :-P
Apr 06 18:07:41 <Herrie|TP> I.e. with the component because the behavior was not very consistent either
Apr 06 18:36:30 * elvispre does not know what he's supposed to do about "Can NOT get PRAUTO from remote PR service", so he always just deletes *everything* and builds the whole system from scratch.
Apr 06 18:51:32 <elvispre> ...and then switches to a local PRSERVICE instead
Apr 06 18:58:00 <Herrie> elvispre: well remote one dies sometimes
Apr 06 19:13:56 <elvispre> Herrie: It's a bit of a show-stopper when it does. The build (without it) is running at least, but is generating many QA Issues about package versions. So I'll have to throw this build away as well when the remove server comes back.
Apr 06 19:15:35 * elvispre should probably be more patient
Apr 06 19:43:04 <Herrie> elvispre: Remote PR service doesn't go down for me often
Apr 06 20:11:10 <JaMa> elvispre: if you delete just tmp-glibc then it should rebuild just from sstate-cache without compiling many things
Apr 06 20:11:31 <JaMa> this time PR service went down even for jenkins builds (which isn't very common)
Apr 06 20:11:40 <JaMa> I might need to look at it later
Apr 06 20:11:45 <JaMa> time to upgrade it anyway
Apr 06 20:45:35 <JaMa> heh someone is mining on our jenkins master?
Apr 06 20:59:42 <JaMa> and the jenkins master is out of disk space again due to excessive logging from jenkins (which is probably the way how the miner got access to the jenkins master)
Apr 06 21:00:29 <JaMa> I'm not going to fix it this time in case someone wants to do the forensics
Apr 06 21:00:59 <JaMa> use local PR service until it's fixed and don't trust jenkins
Apr 06 22:03:49 <elvispre> JaMa: Thanks. Please don't mind my grumbling :)
**** ENDING LOGGING AT Sat Apr 07 03:00:00 2018