**** BEGIN LOGGING AT Sun Jan 24 02:59:57 2021 Jan 24 09:34:06 Morning! Jan 24 09:40:40 Morning! Jan 24 09:52:27 Herrie: I get spammed with this issue: https://github.com/Halium/projectmanagement/issues/14 --> I guess I'll have to make changes in the kernel, or hopefully just a defconfig change Jan 24 10:03:17 My last commit on tissot kernel should fix it; I also remove the "-perf" defconfig, which is just a disturbing duplicate of the one Android uses Jan 24 10:12:11 mmh didn't fix it... maybe some groups are missing on device Jan 24 10:12:44 no, they're here Jan 24 10:14:20 ah, we kept CONFIG_ANDROID_PARANOID_NETWORK=y Jan 24 10:23:55 damn, I still get the errors Jan 24 10:26:13 Tofe: I remember you needed to apply some patches to get it working Jan 24 10:26:16 To the kernel Jan 24 10:26:32 yes, that's what I did (see linked halium issue) Jan 24 10:26:39 but maybe I did it wrong Jan 24 10:28:23 Tofe: I did this for Mido (see commits from 23rd of Jan 2018: https://github.com/Herrie82/android_kernel_xiaomi_msm8953/commits/pgz-14.1-eb8) Jan 24 10:28:25 And that worked Jan 24 10:29:05 I recall having the same issue with Mido on 3.18 kernel Jan 24 10:30:12 you kept PARANOID_NETWORK ? Jan 24 10:30:53 My patch is simpler, but does the same thing: https://github.com/Tofee/tissot/commit/7c38f205af9293626cbaac6d426a89ca00bd376d Jan 24 10:31:34 I kept it, it seems Jan 24 10:31:37 And that worked really Jan 24 10:31:51 There probably was a reason why bshah did it this way Jan 24 10:31:57 Maybe something during Android build side Jan 24 10:33:29 Seems option is checked elsewhere as well: https://paste.ubuntu.com/p/dWGgJRfVHG/ Jan 24 10:33:49 af_inet for example Jan 24 10:34:16 I have the same behavior, PARANOID or not Jan 24 10:34:32 and I checked, I have "getpcaps $(pidof pm-service)" returns no cap at all Jan 24 10:37:52 Groups are there: https://github.com/shr-distribution/meta-smartphone/blob/gatesgarth/meta-android/recipes-core/android-system/android-system_1.0.bb#L101-L102 Jan 24 10:37:55 I added them for 7.1 Jan 24 10:38:31 yes, I checked /etc/group, all is here, with the correct IDs Jan 24 10:43:28 meh, pm-service is launched in group "system" only.... Jan 24 10:45:01 I'll adapt the patch and grant the cap also for group "system" Jan 24 10:47:35 ah, AID_SYSTEM doesn't exist... ok, let's do it the other way around and add pm-service to net_raw group Jan 24 10:50:04 but I wonder why that would worl on mido, then Jan 24 10:52:51 on rosy it's also not in net_raw group, so I must be missing something here Jan 24 10:57:39 much better now. But that raises some questions. Jan 24 12:45:37 Tofe: well it could just be poor Tissot device tree? Jan 24 13:22:21 Herrie: there must be something else, pm-service isn't in the net_raw group in mido nor rosy devices Jan 24 13:22:38 Hmmz weird then Jan 24 13:23:06 Anyway we can document it in Halium docs for future targets Jan 24 13:23:09 it's not really an issue to add it, though Jan 24 13:23:12 Never hurts Jan 24 13:23:24 bshah said in the halium issue he would include it Jan 24 13:24:09 now I have several missing sepolicy entries to fix, for the vndk services we introduced Jan 24 13:24:26 it probably can be copied from the treble migrated device tree Jan 24 13:24:38 I thought we could ignore selinux? Jan 24 13:24:46 Since we have stub service for it? Jan 24 13:25:18 well, the issue here is that some services are not marked as executables, only 644 Jan 24 13:25:52 and selinux fixes that (I think) somewhere in the process Jan 24 13:26:04 Ah ok Jan 24 13:26:17 Tofe: Seems he added this only for 3.10, seems needs to be 3.18 added there too: https://docs.halium.org/en/latest/porting/debug-build/wifi.html?highlight=PARANOID#kernel-3-10-ping-socket-permission-denied Jan 24 13:26:24 Not sure how it would behave on 4.4/4.9 kernels Jan 24 13:26:31 I guess we'll find that out sometime Jan 24 13:26:42 P.s. Seems Halium 10 also has some progress Jan 24 13:34:21 https://github.com/Tofee/android_device_xiaomi_msm8953-common/commit/1e05b812539af7e62c5b4e78afa05d71aeadfb89 something like this Jan 24 17:13:32 Tofe: Ooh nice Jan 24 19:15:43 Herrie: so, in the end, it's a much simpler problem: the files aren't marked as executables in the vendor repos Jan 24 19:26:50 Tofe: I kinda recall seeing some logics in halium-devices setup script to address that? Jan 24 19:26:55 Maybe we need to expand that? Jan 24 19:27:30 ah, I didn't know we already had pieces of that Jan 24 19:28:33 right I'm trying to tackly one of the last issues: gatekeepr service keeps crashing Jan 24 19:28:52 because it can't open "/dev/qseecom" device Jan 24 19:29:02 (which, indeed, doesn't exist...) Jan 24 19:30:33 Question is if we need gatekeepr and qseecom Jan 24 19:31:53 not sure either Jan 24 19:57:14 looks like the issue is that qseecom kernel driver fails to initialize in the first place Jan 24 19:57:14 on rosy, it inits correctly, but slightly differently too Jan 24 20:02:55 I may have a lead with kernel's cmdline Jan 24 20:03:02 a missing androidboot.keymaster=1 Jan 24 20:05:48 it worked :) Jan 24 20:06:19 now it's mainly the camera stuff that doesn't boot so well Jan 24 20:06:49 but gatekeep seems to behave I think Jan 24 20:06:54 and qseecom too Jan 24 20:28:58 then there's still still /vendor/firmware_mnt missing mount, which probably is making things difficult for the camera service Jan 24 20:29:07 s/still/this/ Jan 24 20:29:43 but I'll look into it another time, I'm a bit tired :) Jan 24 22:04:34 Tofe: Well seems like very solid progress anyway so that's great! **** ENDING LOGGING AT Mon Jan 25 02:59:57 2021