**** BEGIN LOGGING AT Thu Oct 26 03:00:02 2017 Oct 26 05:12:42 @EricBlade Nice!! Oct 26 05:13:04 EricBlade ^ (I guess I have forgotten how to IRC?) Oct 26 06:06:45 EricBlade: oh, a circular touch menu :p Oct 26 07:44:48 Morning! Oct 26 07:44:59 Morning! Oct 26 07:48:12 Tofe: The new BT code looks a lot cleaner :D Oct 26 07:49:34 Herrie|Laptop: yes it's easier to read Oct 26 07:49:55 discovery still doesn't work, I don't know why; might be an android issue, or not Oct 26 07:50:27 Tofe: Hard to say :S Oct 26 07:50:47 (alors the criteria to start/stop discovery isn't so good currently, based on opening of the drawer...) Oct 26 08:00:33 s/alors/also/ Oct 26 08:00:50 Tofe: Well it did that on legacy I think too Oct 26 08:07:33 ok Oct 26 08:08:59 Tofe: This is device menu JS on 2.2.4: https://bpaste.net/show/5783b6ebc3a8 Oct 26 08:09:45 See from line 260 ;) Oct 26 08:18:31 This is still good old Mojo ;) Oct 26 08:21:08 In 3.x it was in the luna-sysmgr so I guess what's in WOCE is most accurate for that: https://github.com/woce/LunaSysMgr/blob/a8f94c9171da2af9cdf25a820af6f2a2d68123fc/Src/lunaui/status-bar/SystemMenu.cpp#L551 Oct 26 08:24:36 Herrie|Laptop: ok, I see Oct 26 08:26:19 Tofe: But of course we can change the behavior if we don't like it :P Oct 26 08:30:06 no that's fine, it's pretty intuitive Oct 26 08:30:15 Or have a Tweak to let the user choose :P Oct 26 08:31:16 But that's for later I'd say Oct 26 10:43:26 hey guys, I'm from the asteroidos project, we have been using your approach for the qemux86's graphic stack (i.e: mesa 10.3.7 with gallium-llvm) for a while now but we recently upgraded to OE Rocko and apparently faced the same problem as you did here https://github.com/webOS-ports/meta-webos-ports/commit/5ab5cce32fa588cbba4b899a20cb6c7abffee5d3 the commit message ends with "it's time to find a new way Oct 26 10:43:28 of doing graphics in LuneOS emulator", has there been any progress or idea since then? Oct 26 10:44:09 kido: Not much to be honesy Oct 26 10:44:11 honest Oct 26 10:44:16 We need to find something as well Oct 26 10:44:20 We're still on Pyro Oct 26 10:44:31 meh, that's what I was afraid of Oct 26 10:44:49 Just we don't have much qemux86 knowledge. Inherited it from LG/HP this way and kept it alive as long as we could :P Oct 26 10:44:54 But we need some more work on it Oct 26 10:45:04 Tofe might have some more insights Oct 26 10:45:04 I'll let you know if I find a solution but as far as I can remember I couldn't workaround the usage of this old mesa version Oct 26 10:46:28 don't the Qt for Device Creation have an emulator? Oct 26 10:46:36 kido: we didn't start working on it yet; but a lead was to use virtgl on qemu (and abandon virtualbox support eventually) Oct 26 10:46:44 right Oct 26 10:46:52 I was also considering this track indeed Oct 26 10:47:02 have you already tried it or is it just an idea? Oct 26 10:47:08 oh sorry Oct 26 10:47:16 didn't read correctly... my mistake Oct 26 10:47:34 :) no pb Oct 26 10:47:37 I'll give that a try and let you know if I come up with something interesting Oct 26 10:48:20 yes, we'll be very interested :) Oct 26 10:48:59 cool, thank you for the insights Oct 26 10:51:49 you're welcome Oct 26 10:53:44 Herrie|Laptop: bluetoothctl discovery behavior is identical with the one I coded in the system menu... and no log or error anywhere... Oct 26 10:54:07 Tofe: Might be worth to give Mako a try instead? Oct 26 10:54:17 maybe yes Oct 26 10:55:08 ah and my "sleep 1" before "rfkill unblock" sometimes is too short; I'd like to find a better way of deciding when to trigger it Oct 26 10:55:31 maybe simply with a loop and "rfkill list | grep bluetooth" Oct 26 10:56:26 or it could be that rfkill simply looks into /proc, so I could wait for the right file to appear there Oct 26 10:57:16 Just to exclude it's something device specific Oct 26 10:57:25 Because you could look for a long time otherwise Oct 26 10:57:35 right Oct 26 10:57:50 last build of testing for mako should be fine I guess ? Oct 26 10:58:54 Tofe: Yup, but we miss your patch there still for meta-smartphone? Oct 26 10:59:12 You only PR-ed for N5, but should be similar Oct 26 10:59:19 Rest should be fine Oct 26 10:59:23 (ah, "/sys/class/tty/ttyHS99/hci0/rfkill0" looks good...) Oct 26 10:59:29 At least it builds again Oct 26 10:59:48 ah yes, right Oct 26 13:08:57 Herrie|Laptop: discovery works on N4 Oct 26 13:09:05 but my UI doesn't :p Oct 26 13:18:11 Tofe: How it doesn't work? Oct 26 13:18:17 Miss something? Oct 26 13:18:21 It should be OK Oct 26 13:18:29 We should have all QT bits in there already? Oct 26 13:22:10 well, it's just a bug in the system menu I probably introduced Oct 26 13:23:35 Tofe: You pushed both LNC & Components :P ? Oct 26 13:26:54 yes yes :) Oct 26 13:27:18 but I never tried this scenario yet, so it's not a big surprise Oct 26 13:32:04 OK Oct 26 13:36:45 Tofe: Scanning works on N4? Oct 26 13:36:47 Or also not? Oct 26 13:38:10 discovery == scanning Oct 26 13:38:22 or ? Oct 26 13:38:52 Ehm yes discovery Oct 26 13:39:16 I think there might be a chance that you misread this conversation :) read it again, from 15:08:00 Oct 26 13:39:31 Ah I missed that line :P Oct 26 13:42:14 hop, updated https://github.com/shr-distribution/meta-smartphone/pull/41 Oct 26 13:45:58 Now we just need to get a hold of JaMa sometime :P Oct 26 13:46:04 He's been MIA a lot lately Oct 26 13:48:55 yes, must have a lot of other things to do I guess Oct 26 13:50:37 I think my N4 battery might be nearly dead Oct 26 13:55:37 Hi! I have some questions about Halium and Yocto/oe. Oct 26 13:55:37 I see that, for mako, we fetch a system zip using a recipe that has halium in its name. Oct 26 13:55:37 How do we build that? Does it include a kernel? If not, where does the halium kernel get built? Oct 26 13:55:37 Or is that on the device already because that's why you have to flash cm 12.1 first? Oct 26 13:56:50 I am trying to understand what has changed, you see. Oct 26 14:07:07 elvispre: You need any 5.1 based Android build Oct 26 14:07:16 Either CM 12.1 or Google's Oct 26 14:07:18 DOesn't really matter Oct 26 14:07:24 To be flashed first Oct 26 14:08:04 Then you can use our build Oct 26 14:08:15 We basically use Yocto to build the kernel from Halium/UBPorts Oct 26 14:08:36 https://github.com/ubports/android_kernel_google_msm/tree/ubp-5.1 is what we use for Mako Oct 26 14:08:51 They included our patches in their repo, so we don't need to maintain our own kernel anymore Oct 26 14:09:07 Herrie|Laptop: How do we build that kernel? Oct 26 14:09:15 In our regular build process ;) Oct 26 14:09:33 http://webos-ports.org/wiki/Build_for_Mako Oct 26 14:09:55 Which at some point will get to https://github.com/shr-distribution/meta-smartphone/blob/pyro/meta-lg/recipes-kernel/linux/linux-lg-mako_git.bb Oct 26 14:10:17 Sure, but I don't see any recipes for that kernel... Oh, OK :-) Oct 26 14:11:57 We changed quite a bit, but in general this is a good way forward, because all other OS-es are trying to use the same kernel now Oct 26 14:12:06 Instead of everyone maintaining their own ;) Oct 26 14:12:18 Yes. That does look like a very good idea. Oct 26 14:12:27 Just less reinventing the week Oct 26 14:12:34 And it makes new ports a lot easier too Oct 26 14:13:03 s/week/wheel Oct 26 14:13:55 I.e. if Halium runs, getting LuneOS running should be really straight forward :) Oct 26 14:14:25 And they have some more devices already: https://github.com/Halium/docs/blob/master/supplementary/device_overview.md Oct 26 14:17:16 Yes, I saw that. So we are building their kernels using our build system. Is that right? Oct 26 14:20:29 Actually, you already answered that above. (15:08 here.) Oct 26 14:23:44 Yocto, Halium, oe, cm, lxc, ubports... Oct 26 14:24:00 * elvispre|s needs to draw some diagrams Oct 26 14:26:09 elvispre|s: Yes LOL Oct 26 14:26:37 Well not much changed compared to previously except that Halium bits we use are a lot more lightweight compared to the CM bits we had before Oct 26 14:26:42 And more generic Oct 26 14:28:01 CM is pretty much out of the picture now ;) Oct 26 14:28:12 ubports shouldn't be there. Ideally the kernel would be with Halium Oct 26 14:28:16 They just didn't fork it yet Oct 26 14:38:19 Herrie|Laptop: I see. Now I understand why grepping for halium seemed a little incomplete. Oct 26 14:54:01 elvispre|s: Not sure you read, but we're moving from BlueZ4 to BlueZ5 and seeing if we can do Settings app in QML instead, so we can drop the BT and WiFi plugins from the Luna-WebAppManager Oct 26 14:54:15 Since all other OS-es are doing it in Qt directly too it seems Oct 26 14:57:13 Herrie|Laptop: Yes, I had mostly picked that up in my lurking. Enyo has been abandoned so we have to move on. Oct 26 14:58:14 Well not abandoned, but not much alive either Oct 26 14:58:21 And the plugins made Settings slow a bit too Oct 26 15:05:54 Is it BlueZ5 that Tofe has mostly working now? Oct 26 15:08:16 elvispre|s: Yes since it uses new API Oct 26 15:08:28 So some of the stuff in CardShell needs to be rewritten Oct 26 15:08:35 As well as initial work for Settings migration Oct 26 15:08:55 Cool! Oct 26 21:06:05 @dkirker @tofe yea i spent some time last summer and also a little bit recently working on that product. :-) since we never really get individual credit, i have to have someone to brag to lol Oct 26 21:06:30 of course, so did a whole lot of other people spend a lot of time working on it **** ENDING LOGGING AT Fri Oct 27 03:00:01 2017