**** BEGIN LOGGING AT Tue Jul 16 03:02:17 2019
Jul 16 08:03:22 <Herrie> Morning!
Jul 16 08:03:27 <Herrie> JaMa: Thnx for fix!
Jul 16 08:03:55 <Herrie> Tofe: Seeing we now excluded oFono, VoiceCall, libqofono etc. I suspect next suspect might be ConnMan somehow
Jul 16 08:04:36 <Herrie> Mer has their own version as well which might do certain things differently
Jul 16 08:13:13 <Tofe> Herrie: Ah maybe
Jul 16 08:20:11 <Herrie> Tofe: Hope you're having a nice trip :)
Jul 16 08:42:19 <Herrie> I can try with their ConnMan to see what it does
Jul 16 11:32:09 <Herrie> bshah: ping
Jul 16 12:04:22 <bshah> pong
Jul 16 12:06:01 <bshah> Herrie: ^
Jul 16 12:48:41 <Herrie> bshah: Seems we somehow managed to break telephony at our end ;)
Jul 16 12:48:55 <bshah> "yay"? :P
Jul 16 12:49:03 <Herrie> I.e. SMS incoming & outgoing works, calls don't go out and incoming ones go directly to voicemail
Jul 16 12:49:44 <Herrie> We're trying to pin down what actually is causing this in ofono, libqofono, connman, libconnman-qt and voicecall
Jul 16 12:49:53 <Herrie> All were upgraded at some point and something broke it :P
Jul 16 12:50:11 <Herrie> Just we're using everything Mer except ConnMan which comes from Yocto.
Jul 16 12:50:35 <Herrie> It did work at some point in the past, which I was able to verify based on our release image for Hammerhead (5.1 based)
Jul 16 12:51:24 <Herrie> So now trying to get Mer's ConnMan to build in our image
Jul 16 12:51:59 <Herrie> To see if things magically start working again, while at same time we bumped already libqofono, ofono itself, libconnman-qt and voicecall without any luck
Jul 16 13:40:10 <Herrie> bshah: FYI ^
Jul 16 13:40:27 <bshah> *nod*
Jul 16 13:50:23 <Herrie> bshah: We know it worked on a past release, I suspect one of the many updates just broke stuff
Jul 16 13:50:39 <Herrie> bshah: SFOS guys made quite some changes to both oFono & ConnMan
Jul 16 15:14:47 <Herrie> JaMa: Ping
Jul 16 15:20:03 <Herrie> I'm trying to get Mer's ConnMan to build, but in order to do so I need to introduce some other recipes such as libgofono and libgofonoext. I get the following error. I see different "solutions" when I Google, not sure what's the proper one? QA Issue: No GNU_HASH in the ELF binary /home/herriemerim/LuneOS/warrior/webos-ports/tmp-glibc/work/cortexa8t2hf-neon-halium-webos-linux-gnueabi/lib
Jul 16 15:20:03 <Herrie> gofono/2.0.6-1+gitAUTOINC+972fe461c9-r0/packages-split/libgofono/usr/lib/libgofono.so.2.0.6, didn't pass LDFLAGS? [ldflags]
Jul 16 15:23:14 <Herrie> I see some suggestions to add INSANE_SKIP_${PN} = "ldflags"
Jul 16 15:34:10 <Herrie> But I'm not sure if that's the right approach. Makefiles are at: https://git.merproject.org/mer-core/libgofono/blob/master/Makefile and https://git.merproject.org/mer-core/libgofonoext/blob/master/Makefile
Jul 16 16:01:10 <JaMa> Herrie: INSANE_SKIP isn't solution it just hides the issue, just make sure that Makefiles respect LDFLAGS set in environment by OE build (you can pass them through CC or CXX variable or similar, see e.g. oe-core recipes appending LDFLAGS in EXTRA_OEMAKE
Jul 16 16:20:01 <Herrie> JaMa: OK, thanks for pointers. SO where Tofe added ifndef CC for libglibutil (https://github.com/webOS-ports/meta-webos-ports/blob/warrior/meta-luneos/recipes-support/libglibutil/libglibutil/0001-Makefile-use-CC-from-bitbake.patch#L18) he could have just as well added: https://github.com/openembedded/openembedded-core/blob/warrior/meta/recipes-connectivity/irda-utils/irda-utils_0.9.18.bb#L25
Jul 16 16:20:01 <Herrie> instead?
**** ENDING LOGGING AT Wed Jul 17 02:59:57 2019