**** BEGIN LOGGING AT Sat Sep 30 03:00:02 2017 Sep 30 05:16:57 Morning! Sep 30 07:38:18 Morning! Sep 30 07:38:27 Herrie: your image works well; no BT though Sep 30 07:38:33 but the rest is fine Sep 30 07:39:01 However I wonder, what stops us from getting a stable out ? we can improve the kernels situation afterwards Sep 30 07:45:30 Tofe: Your PR to JaMa to fix the rotation ;) Sep 30 07:45:39 Rest is readu Sep 30 07:45:42 ready Sep 30 07:45:51 Does WiFi work on Mako? Sep 30 07:48:24 These kernels won't be in this decaf release anyway Sep 30 07:51:23 yes, wifi works Sep 30 07:51:29 ok :) Sep 30 07:57:42 Also scanning? Sep 30 07:57:55 Because on Hammerhead with Halium kernel it turns on but doesn't scan it seems Sep 30 08:02:08 I"ve been connected to wifi, to yes Sep 30 08:04:22 :D Sep 30 08:04:34 Might be good to check journalctl to see if there's anything out of ordinary in there Sep 30 08:23:55 But good to see their kernel in general works fine for us :D Sep 30 08:30:03 yes, that's good news Sep 30 08:32:50 It gives some stuff like IPv6 as well which we didn't have Sep 30 08:33:00 If you still have your Mako you might want to test webrtc Sep 30 08:33:03 Let me find the link Sep 30 08:33:09 It didn't tell me IPv6 support before Sep 30 08:33:24 https://test.webrtc.org/ Sep 30 08:33:57 It's a pretty nice test in general Sep 30 08:34:03 Just before it wouldn't give me IPv6 Sep 30 08:34:14 And Camera doesn't work in Browser but that's expected right? Sep 30 08:37:03 That's expected yes; I think we'll have to switch to droidmedia instead of hybris/compat to get this working Sep 30 08:40:05 nope Sep 30 08:40:09 no ipv6 Sep 30 08:41:15 however, it might be just this test for webRTC: on ipv6-test.com, it passes alright Sep 30 08:46:43 Ah ok Sep 30 08:56:51 I'm now trying to clean up a bit the /usr/libexec/hal-droid things; we don't need overlays or additional mounting anymore Sep 30 10:47:24 Tofe: OK :) Sep 30 10:57:03 Tofe: THis might be interesting at some point: https://github.com/DeadSquirrel01/Team-Win-Recovery-Project/commit/92fe3259f7281dbb499602721fd371566e13f9d9 Sep 30 11:06:31 Herrie: I don't know; adding "Halium" per se doest make much sense, as the initrd has to be adapted Sep 30 11:06:44 and the latter depends on the distribution that uses Halium Sep 30 11:07:29 I guess they're talking about supporting the rootfs provided by Halium, but that's just a reference rootfs, not something common across distribs Sep 30 11:08:18 Or, they're talking about hybris-boot, used by (at least) sailfish ports Sep 30 11:08:23 but we don't use that Sep 30 11:37:45 Tofe: Ah OK Sep 30 11:37:56 Yeah I think thye're using hybris-boot Sep 30 11:49:28 Herrie: do you really need USER_NS and PID_NS in webos? Sep 30 11:49:49 re commit : 7e52a1d39f599dc08ce72a9ee1b763eb4283bcba and 4009cd1d912659b9450986fdadd5ba2fe2f37788 Sep 30 11:51:12 bshah: These can be used by qtwebengine, systemd and lxc - though I don't remember if they are mandatory Sep 30 11:51:39 chromium.. hm okay Sep 30 11:51:51 yes, chromium does a lot of sandboxing too Sep 30 11:52:13 at least well, user namespaces are useless for lxc, given android container would be running as priviliged anyway Sep 30 11:52:17 and even will all these xxx_NS, I had to disable a couple of them Sep 30 11:52:36 s/will/with/ Sep 30 11:53:00 bshah: If they're problematic for Halium we could keep them as patches at our end Sep 30 11:53:06 But if they don't harm we'd prefer to have them Sep 30 11:53:35 Herrie: well, there is no harm, but was just curious as so far it is working fine without them.. Sep 30 11:53:36 ;) Sep 30 11:54:01 bshah: using a recent systemd on our end doesn't help on that matter Sep 30 11:54:21 We're a bit on the edge, already Sep 30 11:54:25 We're on 232 for systemd Sep 30 11:54:40 And 230+ has a lot stricter requirements in terms of kernel features Sep 30 11:54:55 Like, kernel 3.14+ :p Sep 30 11:55:20 Well 3.7 I think Sep 30 11:55:24 For most Sep 30 11:55:38 It will work on lower kernels but with errors/warnings Sep 30 11:55:51 okay.. currently build is going on.. will notify if works out Sep 30 11:55:55 The Invocation ID stuff was introduced in 3.7 Sep 30 11:57:27 bshah: ok :) Sep 30 11:58:29 (https://github.com/systemd/systemd/blob/v232/README says 3.12) Sep 30 12:00:19 Tofe: Yeah they say that ;) Sep 30 12:01:06 hm argh.. local breakage Sep 30 12:01:08 :@ Sep 30 12:01:21 There are tons of patches in systemd from yocto to avoid some of these I guess Sep 30 12:01:23 (not related to those patches ofcourse) Sep 30 12:03:59 bshah: In general they should be fairly harmless Sep 30 12:04:05 Tofe: Stuff like: https://github.com/openembedded/openembedded-core/blob/pyro/meta/recipes-core/systemd/systemd/0020-back-port-233-don-t-use-the-unified-hierarchy-for-the-systemd.patch Sep 30 12:04:35 Herrie: yup, good that they have that... Sep 30 12:04:51 Herrie: okay, works for me, I will ask @mariogrip for review one more time Sep 30 12:18:08 bshah: OK great! YOu want me to PR Mako right away too? Sep 30 12:18:11 I have that ready too Sep 30 12:18:43 Herrie: I should fork mako kernel in Halium org for that and get the systemd related commits commited Sep 30 12:18:49 (defconfig and all) Sep 30 12:18:57 once done I will let you know Sep 30 12:19:21 bshah: You have the Google one in Halium Sep 30 12:19:36 Ah no Sep 30 12:19:39 That was ubports Sep 30 12:19:45 :) Sep 30 12:19:46 They use this one: https://github.com/ubports/android_kernel_google_msm Sep 30 12:19:59 Basically my fork with patches is here: https://github.com/Herrie82/android_kernel_google_msm Sep 30 12:20:33 bshah: For Plasma mobile you're using ConnMan & oFono or something else? Sep 30 12:20:47 Herrie: ofono + telepathy Sep 30 12:20:58 bshah: Ah ok Sep 30 12:21:04 why? Sep 30 12:21:07 Own oFono or Mer's? Sep 30 12:21:23 umm, whatever is provided by ubuntu xenial Sep 30 12:21:24 On Hammerhead wifi powers on with your kernel but doesn't scan for me Sep 30 12:21:33 bshah: Ah ok Sep 30 12:21:44 On Mako it seems fine according to Tofe Sep 30 12:21:49 Could be something else Sep 30 12:22:02 Herrie: got dmesg? Sep 30 12:22:03 We currently have Yocto ConnMan + Mer oFono + Mer Voicecall Sep 30 12:22:21 Might be worth for us to move to Mer ConnMan sometime too :P Sep 30 12:22:52 https://bpaste.net/show/8812b4240849 Sep 30 12:23:40 Around line 1960 starts to get interesting I guess Sep 30 12:24:51 Sep 29 06:25:49 hammerhead kernel[896]: [ 297.661836] _dhdsdio_download_firmware: dongle nvram file download failed Sep 30 12:24:54 Sep 29 06:25:49 hammerhead kernel[896]: [ 297.661977] dhd_bus_start: dhdsdio_probe_download failed. firmware = /vendor/firmware/fw_bcmdhd.bin nvram = /etc/wifi/bcmdhd.cal Sep 30 12:25:18 you might want to update the def config to update teh path Sep 30 12:26:24 bshah: Hmmz good point Sep 30 12:26:35 But it's your defconfig, but could be we have it in a different location Sep 30 12:26:47 right.. Sep 30 12:27:20 But seems for the rest we're fine with your kernel and everything booted from 1st go Sep 30 12:27:24 Only BT doesn't work Sep 30 12:27:31 But that's expected since you have backported Ubuntu stuff Sep 30 12:27:38 So we'd need to update that at our end Sep 30 12:27:47 Any hints for that would be appreciated ;) Sep 30 12:29:12 it's totally dark magic for me :P Sep 30 12:29:19 OK ;) Sep 30 12:29:23 Herrie: for the firmware, keep in mind we *mount* /system from /usr/libexec/hal-droid/system, and that happens obviously after kernel startup Sep 30 12:29:24 get hold of mariogrip to know more about it Sep 30 12:30:08 OK Sep 30 12:30:34 Tofe: Ah that's why we did the module thing for WiFi as well I guess? Sep 30 12:30:56 bshah: I have some time right now, want to share your cursed .so with me too ? Sep 30 12:31:37 Herrie: well, one of the the reasons yes, but it's not fatal here as the wifi module retries afterwards Sep 30 12:31:52 However the path is wrong, for sure Sep 30 12:32:01 we use /firmware, iirc Sep 30 12:32:20 why use non standard path though? :P Sep 30 12:32:42 bshah: is /firmware not standard ? Sep 30 12:32:43 Tofe: arm.bshah.in/libhybris-git-0.1.0-1-armv7h.pkg.tar.xz this is basically archlinux package with cursed libhybris Sep 30 12:33:02 bshah: ok Sep 30 12:33:27 Tofe: well, non-standard as-in, official google kernel expects it to be in /vendor/firmware and /etc/wifi/ Sep 30 12:34:10 or could be the /firmware partition doesn't contain that kind of firmware Sep 30 12:34:18 I don't remember, I should check Sep 30 12:35:46 /firmware is typically just modem firmware Sep 30 12:38:20 ok Sep 30 12:46:18 bshah: do you have the complete build log for that package? Sep 30 12:46:37 Tofe: umm, not right now but can rebuild and give you Sep 30 12:47:30 bshah: libEGL exports hybris_egl_display_get_mapping, and eglplatform_wayland.so needs it, but eglplatform_wayland.so isn't linked to libEGL; so the explanation must be in the build Sep 30 12:48:19 Tofe: well, eglplatform_wayland.so is not supposed to be linked to libEGL Sep 30 12:48:42 ok, then the symbol isn't exported by the correct lib :) Sep 30 12:49:24 it should be in libhybris-eglplatformcommon.so.1 I guess ? Sep 30 12:49:30 let me compare with our build, actually Sep 30 12:51:17 I have _Z22hybris_egl_get_mappingPv exported in libhybris-eglplatformcommon.so.1.0.0, which means I think it's C++ export Sep 30 12:51:39 ah no wait, it's not the right one Sep 30 12:53:19 brb ~5 mins Sep 30 12:53:24 yup Sep 30 12:54:34 bshah: I have the exact same situation as you do. So my only guess is that the current libhybris situation is fishy, not only your build... Sep 30 12:59:49 Tofe: what do you mean my "same situation"? Sep 30 13:00:31 same exports, same imports, same linking Sep 30 13:00:57 but it works on LuneOS, I guess only because libEGL is loaded sooner Sep 30 13:01:27 anyway, as-is, the binaries are wrong Sep 30 13:01:49 I don't even know how it came to this situation Sep 30 13:02:04 PS: I now have logs of my own, don't bother to fetch yours Sep 30 13:06:06 Tofe: do you use EGL_PLATFORM=wayland? Sep 30 13:07:50 Tofe: if so, can you provide me strace of simple qmlscene helloworld? Sep 30 13:07:50 hwcomposer Sep 30 13:07:56 hm ok Sep 30 13:08:12 Tofe: well, for hwcomposer platform works but not wayland Sep 30 13:08:19 true Sep 30 13:08:48 but for the client it should be wayland, isn't it? Sep 30 13:09:06 yeah it should be client Sep 30 13:09:22 err I mean it should be wayland for client Sep 30 13:09:25 ok so let's go for strace Sep 30 13:13:55 https://bpaste.net/show/c832efd056e7 Sep 30 13:14:35 yup libEGL is loaded much sooner Sep 30 13:15:04 Tofe: I might have missed some messages here: last I got was : 18:38:01 <+Tofe> | ok so let's go for strace Sep 30 13:15:06 anything I missed? Sep 30 13:15:26 just the strace paste :) (15:13:55) Tofe: https://bpaste.net/show/c832efd056e7 Sep 30 13:16:05 Tofe: my strace : http://arm.bshah.in/qmlscene.txt Sep 30 13:17:51 pretty similar Sep 30 13:18:00 yep :/ Sep 30 13:19:09 Tofe: wait, you mean you are also hitting same issue? :O Sep 30 13:20:06 no no, it starts fine Sep 30 13:20:15 ah ok hm Sep 30 13:20:17 it crashes because of strace, that's all Sep 30 13:20:29 right hm Sep 30 13:20:32 but the order of the loading of libraries is pretty much the same Sep 30 13:20:42 wonder if it have anything to do with mm linker Sep 30 13:20:45 hybris's EGL gets loaded before eglplatform Sep 30 13:24:47 you prefix /usr/lib/libhybris-egl in your LD_LIBRARY_PATH, where we directly put hybris' libs in /usr/lib, could it play a role? Sep 30 13:25:15 shouldn't matter really.. because in ubuntu rootfs same setup works completely fine Sep 30 13:28:07 bshah: then the only guess left is the mm linker: we use jb Sep 30 13:28:41 right.. and I can't exactly "try" jb linker.. (android 7 platform, nexus 5x) :'9 Sep 30 13:28:44 :'( Sep 30 13:29:19 Tofe: https://github.com/webOS-ports/meta-webos-ports/commit/4f3854b4912d28313c857fa26d66801dc582468b Sep 30 13:29:23 Seems to work Sep 30 13:29:29 Now cehcking mounting /vendor/ Sep 30 13:29:46 Seems straight forward enough Sep 30 13:29:53 New image should be ready soon I guess to flash Sep 30 13:29:58 Herrie: lgtm Sep 30 13:30:38 Tofe: Well it appears in image, so should be ;) Sep 30 13:31:05 Tofe: I will ping krnlyng for help on this.. I am completely out of idea on this issue now.. Sep 30 13:32:35 yeah, maybe he'll have an idea Sep 30 13:33:45 Why don't we ever have simple issues with libhybris... Sep 30 13:37:22 what's fun in it Sep 30 13:37:23 :d Sep 30 13:37:25 :D Sep 30 14:28:12 Tofe: random google led me to this : http://www.merproject.org/logs/%23sailfishos-porters/%23sailfishos-porters.2014-08-22.log.html#t2014-08-22T15:21:43 but not sure of solution Sep 30 16:50:16 Tofe: For this vendor folder should add to the 50-firmware file for android-system in meta-smartphone/meta-lg right? Sep 30 16:50:43 And add a SRC_URI_append_hammerhead like we have for Mako right? Sep 30 16:51:04 Because that doesn't seem to put it in the image for me :P Sep 30 17:36:20 Herrie: let me see Sep 30 17:38:09 Herrie: actually I didn't realize this file existed :p Sep 30 17:38:40 if you look at our pre-start.sh, you'll see we try to mount /firmware anyway Sep 30 17:40:05 Herrie: we should first identify which "firmware" folder we're talking about Sep 30 17:41:36 Herrie: it's actually /etc/wifi which is the issue here Sep 30 17:42:48 There's just a missing link /etc/wifi -> /system/etc/wifi Sep 30 17:43:31 which should be in android-system-image.inc Sep 30 17:44:09 "ln -sf /system/etc/wifi ${D}${sysconfdir}/wifi" **** ENDING LOGGING AT Sun Oct 01 03:00:01 2017