**** BEGIN LOGGING AT Sat Apr 06 02:59:57 2019 Apr 06 05:24:07 JaMa: Anything before 6:00 is still night :P Apr 06 05:24:17 Morning BTW ;) Apr 06 05:24:26 Seeing a lot of progress everywhere :D Apr 06 05:25:04 JaMa: Which Qt is LGE upgrading to or you cannot share? Apr 06 05:25:20 Good they'll finally move beyond 5.6 at least :) Apr 06 06:34:56 Morning! Apr 06 07:21:12 Herrie|Laptop: it's not clear to me. I'm upgrading to 5.12 now but when and if it will be in OSE, I don't know Apr 06 07:21:52 beyond 5.6 is the issue mostly because the license :/ Apr 06 07:43:38 JaMa: OK don't remember what was the issue with the license exactly. Something changed after 5.6 that prevents LGE from upgrading? Seeing they're "big partners" you'd say they could find a solution somehow Apr 06 07:44:06 Here another day of putting up fence, doesn't go extremely quickly but well it looks nice ;) Apr 06 07:44:20 Just the ground is not very even and the wood also not, so makes it challenging at times :P Apr 06 07:56:33 Herrie|Laptop: the license changed from LGPLv2 to LGPLv3, so LG bought the commercial license to use newer Qt internally, but for external partners using OSE that might be too expensive option Apr 06 08:21:35 looks like a dead-end in the long run, but well, I guess they know :) Apr 06 09:18:45 Tofe: looks like we're even :) Apr 06 09:18:46 qtwebengine/5.12.2+gitAUTOINC+92b078a534_43316b156e-r0/git/src/core/renderer/web_channel_ipc_transport.cpp:179:92: error: 'binaryJson' was not declared in this scope Apr 06 09:18:50 | QJsonDocument docReply = QJsonDocument::fromRawData(reinterpret_cast(binaryJson.data()), Apr 06 09:18:53 | ^~~~~~~~~~ Apr 06 09:19:25 on qemux86 Apr 06 09:31:12 ahah Apr 06 09:31:34 ok, it's a copy/paste issue, nothing big Apr 06 09:34:03 https://github.com/Tofee/meta-webos-ports/commit/c5c7740efcd67ba4b0b63890fbaafea5103ab53d Apr 06 11:18:00 mmmh there's still a little fix to do... Apr 06 11:19:39 https://github.com/Tofee/meta-webos-ports/blob/master/meta-luneui/recipes-qt/qt5/qtwebengine/0003-Implement-Sync-IPC-messaging-through-qt.webChannelTr.patch#L129 at the end, it should be "DispatchWebChannelMessageSyncCallback callback" Apr 06 11:23:43 ... and it builds now ! Apr 06 11:24:50 https://github.com/Tofee/meta-webos-ports/commit/c62c8aef571df80d62f3909e75d9effbc7de5402 Apr 06 11:25:27 (of course this should be squashed into previous one, but I don't want to trigger another qtwebengine build locally...) Apr 06 15:46:21 Hmm. This must be how the PRSERVICE is supposed to work. Apr 06 15:48:23 My "local" build (freshly recreated from scratch) seems to be doing nothing but pull ipks from build.webos-ports.org Apr 06 15:56:55 But not any more. Are those first ~2500 recipes the meta-oe ones? After them, my build is on its own again. Apr 06 16:00:18 JaMa: To get this behaviour I needed to remove my build environment and start again. Apr 06 16:01:22 JaMa: Last night it was up to date but had a legacy (month old!) local.conf. Apr 06 16:47:57 me getting fed up with virtualbox' buggy vboxtouch: https://github.com/Tofee/qt5-plugin-generic-vboxtouch/commit/26e613f84e67f967c854a0bf5f3ab95b03f204bb Apr 06 16:49:00 Now the plugin works better, but the event still don't reach the UI, I don't know why... Apr 06 17:33:01 So I get an error downloading quilt-native and yet I get a dev-package image output nevertheless. Apr 06 17:33:13 Warrior is going to take some getting used to. Apr 06 18:16:59 elvispre: PRSERVICE is something different and doesn't influence PREMIRROR nor SSTATEMIRROR Apr 06 18:17:36 I guess you mean sstate archives not ipks (ipks are fetched only on target when you're doing opkg update && opkg upgrade, build uses only the sstate Apr 06 18:18:36 not sure what you mean with first ~2500 recipes, the tasks in runqueue are sorted by dependencies (order of layers don't influence the order of tasks) Apr 06 18:20:07 if the downloading error for quilt-native was about sstate archive than it's normal (and happens even before pyro), the error says, that it failed to fetch sstate and that normal task would need to be executed instead -> so it's correct that dev-package was created (as long as the Summary at the end of the build ends with "all were successful") Apr 06 18:20:24 Tofe: thanks, will cherry-pick and squash them now Apr 06 18:29:23 Tofe: unstable builds restarted Apr 06 18:49:31 JaMa: for vboxtouch, be careful: I'm committed everything, including the previous patches that were there Apr 06 18:49:57 ... and I should rename it, as it doesn't really have anything to do with vboxtouch anymore :) Apr 06 18:53:41 JaMa: Yeah, I was just hand waving. Thanks for the explanations. Apr 06 18:53:58 The behaviour I'm seeing is new to me. Apr 06 18:55:05 At first, I am building "n of 2500" (or so). Then when that's finished it becomes "n of 6677" (or so). Apr 06 18:56:12 That first group now just does ipk_setscene downloads which I don't remember seeing before. Apr 06 18:57:57 I guess the main thing that's different is SSTATEMIRROR now contains things that I used to have to build locally. Apr 06 18:58:22 (But now I am hand waving again.) Apr 06 19:00:53 either you were using different Ubuntu release than jenkins slaves (currently 18.04) Apr 06 19:01:43 or your local.conf modifications broke it, but it was enabled by default (and most likely working in correct circumstances) for very long time Apr 06 19:02:49 I might have even recommended to remove SSTATEMIRROR configuration from your local.conf when you said that you're using different ubuntu release and complained about long delay at the beginning of the build (when it checks what's available on sstatemirror) Apr 06 19:03:05 or I told it to someone else in this channel for sure Apr 06 19:03:28 Right. I did wonder why these caching mechanisms didn't seem to be doing anything. Apr 06 19:04:35 Tofe: should I switch the vboxtouch recipe in meta-qt5 to test it already? :) Apr 06 19:04:38 That could have been me and I missed the significance of what you said. Apr 06 19:05:19 Tofe: also have you tried that only with 5.12 or with 5.11 as well? Apr 06 19:06:41 JaMa: I tried it only with 5.12. But environment.conf as to be modified as well Apr 06 19:06:50 let me show you how Apr 06 19:08:29 JaMa: https://paste2.org/JCsIOfNz Apr 06 19:09:25 thanks will include it for next qemu* rebuild over night Apr 06 19:10:27 Basically, I discovered that vboxguest only provides mouse coordinates, not mouse clicks. So the vboxtouch's driver tried to combine vboxguest with a normal mouse driver on another evdev input. And the latter only provides clicks, not mouse position... quite a mess. Apr 06 19:11:33 So in the end, we have event3 that outputs only mouse clicks, and event5 that outputs only mouse moves... So I got rid of all the vboxguest magic, and just combined the two partial evdev inputs into one. Apr 06 19:12:08 What we give to vboxtouch as arguments, now, is a list of evdev inputs to merge. As many as you wish. Apr 06 19:12:56 I'll probably rename it to "evdevtouchmerger" at some point Apr 06 19:13:29 so you don't use vboxguest at all now? how do you get the eventdev with coordinates? Or is there something in the code which just kicks the evdev to start sending the coord events (like the vboxtouch presumably did before)? Apr 06 19:13:43 btw: how long did it take to do all this? :) Apr 06 19:14:32 JaMa: In VirtualBox, just choose "USB Tablet", and then /dev/input/event5 should show you mouse moves (with evtest for instance). event3 will show mouse clicks. Apr 06 19:14:50 It took about half a day, once the image was built Apr 06 19:15:16 and if it's only merging evdev inputs, isn't it pity to use qt APIs? I have no idea how useful this would be outside this case Apr 06 19:15:24 But unfortunately it's not finished at all: we send the events to Qt, but there's no effect Apr 06 19:15:46 ah, that's why it worked for me before and not for you? Apr 06 19:16:09 what worked? Apr 06 19:16:27 the coord events with evtest Apr 06 19:16:43 ah, it might be because of VBox's settings yes Apr 06 19:16:48 in my images I was receiving them even after removing vboxtouch plugin from luna-next Apr 06 19:17:07 and you weren't getting them until vboxtouch was started Apr 06 19:17:17 yes that was weird Apr 06 19:17:24 maybe I made some mistakes there Apr 06 19:17:39 I think I was seeing the same after rebooting the VM with vboxtouch plugin removed from luna-next (so it wasn't executed even once) Apr 06 19:18:00 but in the kernel, we clearly see that the vboxguest driver creates a virtual evdev mouse device -- with only mouse position Apr 06 19:18:34 have you seen any explanation why it's separated? Apr 06 19:19:13 Well, I didn't see any API in the kernel for retrieving mouse clicks, so I guess it's just not clearly exposed Apr 06 19:20:13 The only thing we lose here is the mouse circle shape Apr 06 19:20:16 ah for vboxguest to proxy them from the host kernel to the VM? Apr 06 19:20:36 yes, vboxguest doesn't provide that, it seems. Apr 06 19:20:49 interesting Apr 06 19:21:03 but VirtualBox exposes a usual USB mouse too, but only the clicks -- that's handled by the bare kernel Apr 06 19:21:13 I wasn't big fan of circle shape anyway Apr 06 19:21:51 It's true we could do some "cat event3 event5 > mergedevent" somehow, and it should work with evdevmouse from Qt Apr 06 19:22:03 I'm just not sure how to do this approach Apr 06 19:22:18 as the ioctl is two-ways Apr 06 19:22:30 thanks a lot for working on it, at least partially resolves my emulator TODO and I was already feeling quite bad for not getting to it sooner Apr 06 19:27:59 Tofe: should I leave LUNA_NEXT_DEBUG enabled as well? Apr 06 19:28:25 ah it's added dynamically in the dev image Apr 06 19:28:27 meta-luneos/recipes-core/images/luneos-dev-image.bb: echo "LUNA_NEXT_DEBUG=1" >> ${IMAGE_ROOTFS}${sysconfdir}/luna-next/environment.conf Apr 06 19:34:35 Tofe: are those license terms taken from e.g. qtbase? I wonder if ( GPL-3.0 & The-Qt-Company-GPL-Exception-1.0 | The-Qt-Company-Commercial ) & ( GPL-2.0+ | LGPL-3.0 | The-Qt-Company-Commercial ) is the correct combo here Apr 06 19:36:12 probably isn't because some files which you didn't modify still has the old license clause Apr 06 19:36:49 the old one says: LICENSE = "LGPL-2.1 & GPL-3.0" Apr 06 19:37:36 ** This file is part of the QtGui module of the Qt Toolkit. Apr 06 19:39:08 ok, it's the same as e.g. qtbase/src/gui/painting/qpathsimplifier_p.h Apr 06 19:43:18 JaMa: I... didn't look at the licensing side at all. But I copied evdevmousehandler from QtBase's qevdevmousehandler, if that helps. Apr 06 19:46:42 with top 2 commits it builds now https://github.com/webOS-ports/meta-webos-ports/commits/jansa/master Apr 06 19:51:13 yep, good Apr 06 19:51:36 though the webappmanager status seemed quite bad, maybe worse than warrior Apr 06 19:52:05 the Sync calls work? Apr 06 19:52:35 I don't know, I don't get any enyo app to start Apr 06 19:52:57 there might be other problems lurking behind Apr 06 19:55:22 ok Apr 06 19:55:54 for instance, firstuse is started, but doesn't show up, which is weird. Apr 06 19:56:01 the build on jenkins will take a bit longer, it was supposed to rebuild just qtwebengine now, but first qemux86 build failed because of missing "make update" so now it's rebuilding quite a lot of stuff Apr 06 19:56:18 when I start it manually, I have to setup the correct PLATFORM variables to wayland and wayland-egl Apr 06 19:56:33 (and the wayland session too) Apr 06 19:56:36 I'll do my builds over night, the hybrid drives I'm using didn't help much with build time :/ Apr 06 19:58:01 With Qt 5.12 it seems that WAYLAND_SESSION get a default value, which isn't /tmp/luna-session... so maybe this could explain that, if luna-appmanager isn't started with the correct value for example Apr 06 19:58:16 In 5.11 there was no default value iirc Apr 07 00:40:57 not morning **** ENDING LOGGING AT Sun Apr 07 02:59:57 2019