**** BEGIN LOGGING AT Wed Oct 18 03:00:01 2017 Oct 18 06:19:22 Morning Oct 18 06:34:24 Morning! Oct 18 06:35:12 Herrie: if connman doesn't do bluetooth, then it answers one of my questions: why didn't we use it before :) Oct 18 06:36:22 In the end, it means we can't do all the connectivity with connman-qt5, we'll need other bindings like what we have in the extension or in the cardshell Oct 18 06:49:05 Morning! Oct 18 06:51:15 FYI - I briefly tested latest qemux86 build yesterday. It worked as good as previous release bits. Is there anything that was changed - with I could test in more detail? Oct 18 06:52:45 MartinHov: the main changes were about connectivity and Halium, so if qemux86 works as well as before, it's normal :p Oct 18 06:54:36 Tofe: thanks Oct 18 07:22:20 Morning Oct 18 07:22:33 MartinHov: Well we updated to Qt 5.9.2 final release that had some minor fixes here and there Oct 18 07:22:46 Not sure much would be noticable in qemux86, but for sure didn't hurt Oct 18 07:23:19 Tofe: I'll have a look into ConnMan & BlueZ. The advantage of QML would still be you can do direct DBus calls (which is what we do currently in LNC) Oct 18 07:23:28 Which you cannot in JS without some C++ plugin ;) Oct 18 07:31:56 Tofe: This one might be nice to play with if we can get it to work easily: https://github.com/andrew-bibb/cmst Oct 18 07:32:45 If it works, might be easy to quickly test stuff and see things quickly. Also supports VPN etc **** BEGIN LOGGING AT Wed Oct 18 07:36:32 2017 Oct 18 08:00:59 Tofe: Came across this link which has some useful basic info on BT: https://wiki.tizen.org/Bluetooth Oct 18 08:01:57 Tofe: Mer/SFOS have: https://git.merproject.org/mer-core/libbluez-qt/tree/master Oct 18 08:18:39 libbluez-qt looks fine, I just would like to know if it supports bluez4 or blue5 Oct 18 08:20:57 bluez4, looking at the DBus API they implement. Oct 18 08:21:39 however there's https://github.com/KDE/bluez-qt :) Oct 18 08:21:53 Tofe: Ah OK that explains Oct 18 08:21:57 I came across bluez-qt too Oct 18 08:22:26 In https://github.com/CODeRUS/better-sailfishos-qmltypes/blob/Sdk1701/Sailfish/Bluetooth/BluetoothDevicePicker.qml Oct 18 08:22:50 In general in https://github.com/CODeRUS/better-sailfishos-qmltypes there might be a few things we could piggyback on :) Oct 18 08:23:39 or could we just use QtBluetooth ? I just saw that Oct 18 08:25:30 Might even be easier :D Oct 18 08:27:52 and it does both bluez4 and bluez5, might come in handy Oct 18 08:28:05 ok, let's give it a try Oct 18 08:28:13 are we building it, today? Oct 18 08:29:34 Tofe: QtBlueTooth? Oct 18 08:29:40 Or bluez-qt? Oct 18 08:30:30 qtbluetooth Oct 18 08:31:51 seems it should be in qtconnectivity, if bluez is active Oct 18 08:34:42 doesn't seem so, if I didn't miss anything Oct 18 08:39:53 Tofe: I guess we should simply include it in our packagegroup or list it as a dependency somewhere to get it included Oct 18 08:42:09 probably yes Oct 18 08:42:30 Tofe: I guess we also want to include this for qemu right? So we can stub things there? Oct 18 08:43:50 Though currently we don't provide BlueZ in qemu targets it seems Oct 18 08:43:54 We might want to change that Oct 18 08:43:56 Need to test that Oct 18 08:45:27 there is no buildtime dependency on bluez from qtbluetooth, so no problem including it Oct 18 08:51:42 Testing a local build with qtconnectivity Oct 18 09:00:43 QtBluetooth is still an experimental API though Oct 18 09:00:59 but that should be fine. Oct 18 09:02:09 Tofe: I doubt that they'll drop it seeing it's BT ;) Oct 18 09:02:48 the only risk is a sudden change of API I think Oct 18 09:16:55 Tofe: Yeah but it shouldn't be too drastic & difficult anyway Oct 18 10:07:03 Tofe: /usr/lib/qt5/qml now has a QtBlueTooth folder with files. I guess that's what we're after? Oct 18 10:13:06 It wasn't there in the version with qtconnectivity Oct 18 10:17:18 without qtconnectivity I mean Oct 18 10:33:53 Tofe: QtConnectivity also gives QtNFC :) Oct 18 10:45:57 Tofe: https://github.com/webOS-ports/meta-webos-ports/pull/257 Oct 18 10:47:39 Herrie|Laptop: yes, that's what we wanted Oct 18 10:48:19 Herrie|Laptop: PR looks good; I can't merge it anyway, so feel free Oct 18 10:49:24 Tofe: OK Oct 18 10:49:56 Tofe: What you think about this one? https://github.com/webOS-ports/meta-webos-ports/pull/256 Oct 18 10:56:23 look good too Oct 18 10:57:13 It builds, I just haven't tested any phone calls yet Oct 18 10:57:30 But I didn't see many shocking changes Oct 18 10:57:54 Herrie|Laptop: maybe it would easier sometimes if I can also merge things in meta-webos-ports Oct 18 11:01:03 Tofe: Yup Oct 18 11:01:13 We need to ask JaMa to set that up I guess Oct 18 11:02:52 I could do on the repo, but JaMa could add you to the group Oct 18 11:02:57 Which allows you to do more things :)] Oct 18 11:05:08 Tofe: I guess you're OK with the 2 others then too? Oct 18 11:05:16 The luna-next-cardshell & luneos-components? Oct 18 11:05:21 But those you should be able to merge ;) Oct 18 11:05:38 Herrie|Laptop: ah, yes, I looked at it yesterday and it was fine too Oct 18 11:05:52 You'll merge them? Oct 18 11:05:52 I can merge it yes, but the recipes have to be first :) Oct 18 11:06:02 Those are done ;) Oct 18 11:06:04 yes, I'll do it Oct 18 11:06:16 Will then bump SRCREVs and kick off a new testing build Oct 18 11:07:06 done! Oct 18 11:44:09 Build running Oct 18 14:19:35 Herrie|Laptop: one good thing with QtBluetooth is that it should be possible to test it on desktop too, at least on Linux Oct 18 14:19:46 Tofe :) Oct 18 14:20:22 Tofe: preparing a little fix for mako, just wondering 1 thing... Oct 18 14:22:34 (yup, I can see QtBluetooth QML plugin on my QtCreator install at work, under Windows :) ) Oct 18 14:22:54 For Hammerhead we have https://github.com/shr-distribution/meta-smartphone/blob/pyro/meta-lg/conf/machine/hammerhead.conf#L36 Oct 18 14:23:19 For mako we have https://github.com/shr-distribution/meta-smartphone/blob/pyro/meta-lg/conf/machine/mako.conf#L36 Oct 18 14:24:24 If I look at the defconfig for Hammerhead I see we only have the CONFIG_BCMDHD=m and the CONFIG_WLAN=y Oct 18 14:25:16 And that seems to work. Then if I look at our old Mako defconfig I see we have CONFIG_WLAN=m and CONFIG_PRIMA_WLAN=m Oct 18 14:25:40 Am I right in assuming we could suffice with just CONFIG_PRIMA_WLAN=m in our new defconfig and update the module name in mako.conf? Oct 18 14:26:00 It builds fine, just not sure about the logics because it doesn't look consistent to me now ;) Oct 18 14:26:37 I'm... not sure :) The important thing, in the end, is to get the kernel module for wifi. So if that works well, then yes, you're right Oct 18 14:27:05 Tofe: Well it builds Oct 18 14:27:09 Just I have no way to test it Oct 18 14:27:24 you can simply look in deploy/ipk/mako for the kernel module Oct 18 14:29:34 I can propose something in PR, get a build building and you, DougReeder or someone else can test it on Mako Oct 18 14:33:48 ok Oct 18 14:34:18 (kernel-module-wlan is the ipk you want to have in your deploy directory) Oct 18 14:35:01 Tofe: Because of https://github.com/shr-distribution/meta-smartphone/blob/pyro/meta-lg/conf/machine/mako.conf#L36 or another reason? Oct 18 14:40:01 Herrie|Laptop: yes, exactly Oct 18 14:40:40 Though if your build succeeded, it's highly probable that it's fine Oct 18 14:40:44 Tofe: Well if I change that to kernel-module-prima-wlan Oct 18 14:40:49 It works fine :P Oct 18 14:41:20 Just our previous defconfig had both values set to m, while halium hammerhead only has the wifi module set to m and the wlan to y Oct 18 14:41:21 o_O Oct 18 14:41:35 I'm a bit lost :) Oct 18 14:41:38 I Oct 18 14:41:43 I'll propose a PR :P Oct 18 14:45:22 https://github.com/Herrie82/meta-smartphone/commit/368644f68acd2c8bb2e693fc6a2228ae17cf168c Oct 18 14:45:35 This is to make it more consistent with our Hammerhead approach Oct 18 21:04:20 Tofe: Seems that even though we put the PRIMA_WLAN in defconfig it somehow ends up as WLAN module Oct 18 21:04:31 So I don't need to change mako.conf by the looks of it Oct 18 21:04:52 So PR-ed this: https://github.com/shr-distribution/meta-smartphone/pull/40 Oct 18 21:05:06 Then also our little .sh doesn't need updating :) Oct 19 01:12:16 i should know the answers to this by now, but i'm dumb. if there's a LineageOS target for a device, does that mean it's something we could port to? **** ENDING LOGGING AT Thu Oct 19 03:00:01 2017