**** BEGIN LOGGING AT Mon Jun 15 02:59:58 2020 Jun 15 05:41:47 Morning! Jun 15 06:21:46 Morning! Jun 15 08:55:17 Tofe: Also added the appinstalld2 and cryptfs kernel bits to this Mido build. Saw something surprising in the logs though: Jun 06 01:53:02 mido ecryptfsd[1076]: main: Current kernel does not have support for /dev/ecryptfs; please use 2.6.26 or newer Jun 15 08:55:37 Seems might need to enable an additional flag, probably CONFIG_ECRYPT_FS Jun 15 08:56:01 Will check in the Yocto kernel to see what they have there Jun 15 08:57:25 Just I nuked my tmp-glibc yesterday so will rebuild the kernel now ;) Jun 15 08:58:58 Seems this one has the full list ;) Jun 15 08:58:59 https://answers.launchpad.net/ecryptfs/+question/46285 Jun 15 09:46:22 Tofe: BTW seems we need to update this one as well: https://github.com/webOS-ports/luna-qml-launcher/blob/herrie/ls2-fix/src/lunaqmlapplication.cpp#L158 Jun 15 09:46:45 And this one: https://github.com/webOS-ports/location-service/blob/6c92938f65cd1c9d24aa20f6ced571881132e84f/src/location_service.c#L448 Jun 15 09:47:13 For location-service: in OSE they do it this way: https://github.com/webosose/com.webos.service.location/blob/8c9df6e7b93a5e064adc9439ca59a1f0b0731776/src/lunaIpc/LocationService.cpp#L228 Jun 15 10:02:27 Tofe: For location-service I propose this (untested still): https://github.com/webOS-ports/location-service/commit/5bf904755f18d5cdb02bc4dd6cc4e5cd7dbd98e5 Jun 15 10:03:33 JaMa: It seems that my sstate mirror availability checks takes long (as in 20 or so minutes). Any idea what might cause this? Jun 15 10:05:15 Herrie: you change in location-service seems fine Jun 15 10:06:37 I'll propose something for luna-qml-launcher, I have to understand if it's needed at all first Jun 15 10:06:45 (I mean, the pushRole thing) Jun 15 10:09:13 I think it's now completely useless with the new approach (ACG + container, permissions on contained app side) Jun 15 11:30:12 Tofe: Yeah and there's also librolegen for which I'm not really sure how/what it's used for Jun 15 15:35:57 Herrie: are you using the fileserver (milla) as SSTATE_MIRROR? Jun 15 15:44:51 JaMa: Yes seems to, default config just disabled it Jun 15 15:45:46 JaMa: You happen to have some more insight into ecryptfs? Jun 15 15:46:07 Seems I enabled everything I had to enable, but getting: Jun 05 23:53:06 mido ecryptfsd[1168]: main: Current kernel does not have support for /dev/ecryptfs; please use 2.6.26 or newer Jun 15 15:46:45 Seems I might need to add CONFIG_ECRYPT_FS_MESSAGING according to the description for this flag, but it's not in OSE it seems and things seem to work OK there. Jun 15 15:49:32 Herrie: where is the check being done? Jun 15 15:49:57 Tofe: Seems in ecryptfsd when it's starting up Jun 15 15:50:11 It seems to check for /dev/ecryptfs which is not available indeed Jun 15 15:50:42 ok Jun 15 15:50:53 Just not sure how to get it available Jun 15 15:51:00 it could be OSE creates it themselves ? Jun 15 15:51:12 Nope Jun 15 15:51:17 ah wait, no, they probably use udev too Jun 15 15:51:22 Well I also don't see it in OSE, but it also doens't appear in log there Jun 15 15:51:35 So could be thye don't start it somehow Jun 15 15:51:42 Then I wonder why it's included in the image :S Jun 15 15:52:12 modprobe ecryptfs ?... Jun 15 15:52:31 Doesn't show me any output Jun 15 16:03:54 Seems that when I enable the CONFIG_ECRYPT_FS_MESSAGING in VBox it has the mount, but other funny errors in log when I try to run /usr/bin/ecryptfsd Jun 15 16:04:20 https://paste.ubuntu.com/p/fvsPz9fVGk/ Jun 15 16:05:09 Problem is that "CONFIG_ECRYPT_FS_MESSAGING" doesn't exist in 3.4, though backporting seems fairly easy if necessary: https://github.com/shr-distribution/linux/commit/290502bee239062499297916bb7d21d205e99d62 Jun 15 16:19:53 ah, yes, that would be needed here Jun 15 16:50:58 Herrie: on your fast builder it's better to just disable SSTATE_MIRROR, you can probably build things faster than milla sending them to you (and you will also have some local modifications preventing bigger sstate reuse) so overall it doesn't help you at all Jun 15 16:52:16 Herrie: not very familiar but IIRC I was creating some ecryptfs-utils recipe or something similar long time ago, let me check Jun 15 16:52:35 ./meta-webos/recipes-support/ecryptfs-utils/ecryptfs-utils_111.bb Jun 15 16:53:14 this is the systemd service which complains, right? Jun 15 16:53:19 ExecStart=/usr/bin/ecryptfsd -f Jun 15 16:54:21 appinstalld also does something with it to mount ecryptfs Jun 15 17:11:14 JaMa: I'm trying to get appinstalld2 in LuneOS build Jun 15 17:11:31 Have all required bits it seems but something doesn't work as expected Jun 15 17:12:22 In OSE vbox image I don't seem to have /dev/ecryptfs Jun 15 17:13:30 I would expect it's used for /media/cryptofs at some point somehow Jun 15 17:13:47 But I don't see mounts anywhere etc Jun 15 17:30:06 Herrie: it looks like http://build.webos-ports.org/ is completely down now Jun 15 17:30:22 ka6sox: novaldex: ^^ another DDOS or something? Jun 15 17:32:24 Herrie: I don't understand; I just reflashed tissot, and now I have service.accounts[3975]: [] [pmlog] LS_REQ_NAME {"FILE":"base.c","LINE":940} Attempted to register for a service name that already exists: com.palm.service.accounts Jun 15 17:32:49 The firstuse app therefore doesn't switch to normal mode at the end Jun 15 17:34:12 Tofe: Hmmmz that would be something in app-services but that's weird Jun 15 17:34:23 Mido worked OK here Jun 15 17:35:18 I must have forgotten something obvious Jun 15 17:36:51 Tofe: Well my build is always tainted with WIP stuff usually but it should be pretty OK Jun 15 17:36:59 maybe mine is, too Jun 15 17:37:20 I was fiddling around with nodejs sysbus, maybe I forgot to clean it up Jun 15 17:37:41 I did a few SRCREV pushes etc but nothing that would break this I would say Jun 15 17:43:23 ok, all good, my fault. Jun 15 17:45:30 Good you found it quickly Jun 15 17:45:43 yeah :) Jun 15 17:45:51 I also had a syntax error in my android-property-service fix Jun 15 17:46:05 So pushed a fix for that yesterday I think Jun 15 17:48:46 https://github.com/webOS-ports/android-property-service/commit/b0de11089f81fb6a43a414d42474ad6f29dd38ca Jun 15 17:59:14 I recently rebase my meta-webos-ports against latest zeus, so I should be fine Jun 15 17:59:25 anyway I'm working on gst-droid Jun 15 17:59:51 It feels like it's nearly working, but the Halium image is still missing some things Jun 15 18:00:01 but the logs are quite obscure Jun 15 18:04:38 Yeah if you have sources etc you should be close Jun 15 18:06:40 Can you paste your full logcat? Jun 15 18:06:59 And journalctl as well? Jun 15 18:07:06 Maybe I spot something obvious Jun 15 18:16:16 journal doesn't contain anything, no service is involved so far Jun 15 18:16:21 but I can paste it, sure Jun 15 18:18:39 I'm usually testing "gst-launch-1.0 -v -m droidcamsrc ! waylandsink" which should show a wayland window with the camera output Jun 15 18:18:51 https://paste2.org/906heF7D Jun 15 18:19:35 https://paste2.org/c4g6UWUL logcat, start from the bottom :) Jun 15 18:20:20 and the journal https://paste2.org/chdDC3mz Jun 15 18:21:29 some of the obvious errors is 05-26 10:03:56.450 117 2583 E mm-camera: 1085: mct_pipeline_decide_hw_wakeup: Couldn't find meta stream Jun 15 18:23:50 I "think" the various OMX codec errors aren't fatal Jun 15 18:31:27 Would be good to kill this netlinklistener Jun 15 18:31:39 I thought I PR-ed that sometime Jun 15 18:31:44 Will have a look Jun 15 18:37:31 In logcat: cannot connect from device user 0 Jun 15 18:37:51 For camera service Jun 15 18:39:20 Could be we'd need to add some permissions on Android side or add some users again Jun 15 18:40:53 yes, that's a possibility Jun 15 18:41:59 Could be we need to add some users to base-passwd Jun 15 18:42:11 Pretty sure ours is limited somehow Jun 15 18:42:21 I thought I added some Jun 15 18:43:45 Maybe it was somewhere else Jun 15 19:13:20 Ah found it: https://github.com/shr-distribution/meta-smartphone/commit/b9ad840cd095f17b5dc35eba63cd183c43b8d5d5 Jun 15 19:13:25 Seems we should be pretty OK there Jun 15 19:30:43 Tofe: It seems pretty close since it detects max resolution, fps etc from sensor Jun 15 19:31:07 This looks slightly suspicious to me: 05-26 09:58:29.206 1956 2228 E QCamera : int32_t qcamera::QCameraPerfLock::lock_acq(): 363: failed to acquire lock Jun 15 19:32:50 Herrie: yes, I don't know if that one is important or not Jun 15 19:33:36 https://android.googlesource.com/platform/hardware/qcom/camera/+/507f6aa50d56858dc79e90a810ebff197dabbd95/QCamera2/util/QCameraPerf.cpp#213 Jun 15 19:35:39 The return code is never tested apparently, so it shouldn't matter if it fails Jun 15 19:36:58 it seems even possible to disable it with setprop persist.camera.perflock.enable 0 Jun 15 19:43:05 OK Jun 15 19:43:19 Tofe: This one is to switch back to master branch: https://github.com/webOS-ports/luna-next/pull/146 Jun 15 19:43:25 Will have a stab at WAM again Jun 15 20:29:05 Tofe: Small fix for a cleaner logcat: https://github.com/Halium/android_system_core/blob/halium-7.1/libsysutils/src/NetlinkListener.cpp Jun 15 20:29:23 That will be it for today ;) Another fresh start tomorrow ;) Jun 15 20:29:25 gn8 Jun 15 20:34:44 night! **** ENDING LOGGING AT Mon Jun 15 20:36:34 2020 **** BEGIN LOGGING AT Mon Jun 15 20:39:11 2020 **** ENDING LOGGING AT Tue Jun 16 03:06:37 2020