**** BEGIN LOGGING AT Wed Mar 20 02:59:57 2019 Mar 20 07:09:15 ah yes, I saw that wayland-egl was moved from Mesa to libwayland... Mar 20 07:38:09 JaMa: wow, the first part doesn't look right. We build and link libhybris against its own libwayland-egl, but then brutally cut it down ? That's probably the cause yes :) Mar 20 07:39:06 Let me see if there's a nice way to make libhybris depend on libwayland instead, and just not build wayland-egl at all in libhybris Mar 20 07:44:25 it's all a bit entangled in a single "if" https://github.com/libhybris/libhybris/blob/07b547e90db625685050bdfd00c92ccafc64aa09/hybris/egl/platforms/common/Makefile.am#L13 but if we test the wayland's version we should manage a proper generic fix Mar 20 08:18:29 Tofe: dirty test might be to remove wayland-egl from wayland do_install (only for android MACHINEs) and keep the one from libhybris Mar 20 08:18:55 Tofe: but then we might have the same incompatibility on wayland side, but probably easier to try Mar 20 08:19:11 or just copy the removed libs to the image manually for very first try Mar 20 08:20:09 JaMa: worth a try, yes Mar 20 08:20:34 But that'll be for tonight Mar 20 08:28:24 Tofe: I'll try from my end hopefully Mar 20 08:29:55 rpi also removes the one from wayland: https://github.com/agherzan/meta-raspberrypi/commit/7f7bc9e778b6def018c451ecb23f5169cd18f5ed https://github.com/agherzan/meta-raspberrypi/commit/de8912cbcb06b221fb4617f3042e06b68f74c814 Mar 20 08:31:47 Isn't there a flag in wayland to not build wayland-egl ?... Mar 20 08:33:22 will check, but doubt it Mar 20 11:00:05 Tofe: https://github.com/webOS-ports/meta-webos-ports/commit/05165c97f1446f05c270f8caae4f7d216d9e38de will trigger warrior build with this on jenkins later today Mar 20 11:38:37 JaMa: does this mean wayland becomes MACHINE specific? Mar 20 11:39:13 Tofe: effectivelly yes, but should have the same signature for now Mar 20 11:39:55 as long as we don't have different egl providers in the same TUNE_PKGARCH group.. Mar 20 11:40:07 JaMa: couldn't we put ${libdir}/libwayland-egl into a separate wayland sub-package ? Mar 20 11:40:20 unfortunatelly no, it's not about packages Mar 20 11:40:30 it's the library in sysroot which causes the issues Mar 20 11:41:20 ah yes it's a DEPENDS issue, not RDEPENDS Mar 20 11:41:32 damn Mar 20 11:42:08 We'll have to find a better way before hammerhead-mainline is merged :p Mar 20 11:42:23 yes, or mainline all of them, haha :) Mar 20 11:42:28 hehe Mar 20 11:43:14 Actually it'll probably happen, as 3.4 kernel will one day become a no-go... Mar 20 11:43:19 we can probably use e.g. android as MACHINE_CLASS and then append something to TUNE_PKGARCH Mar 20 11:43:52 but that will still require us to build most of the stuff twice Mar 20 11:44:23 but now we're building 4 different rpi architectures which neither really works, so it won't be much worse Mar 20 11:44:36 :) Mar 20 11:44:36 I mean rpi2 rpi3 rpi3-64, qemux86-64 Mar 20 11:45:45 we should probably gather the logs from milla to see if someone downloads one of these Mar 20 11:46:11 I do hope we'll be able to use wayland'd egl implementation also for libhybris images, it would solve our issue here Mar 20 11:46:17 and keep the jobs, but stop building them regularly until someone goes to work on them Mar 20 11:46:58 I'm still interested in rpi3-64, qemux86-64, but without enough time to fix even existing qemux86, they are on much lower priority Mar 20 11:47:32 current status on rpi isn't very encouraging, here's from #qt-lighthouse this morning: " What is the current state of wayland integration on rpi. I have a yocto build (qt 5.12.2) where the client freezes after the first frame with qt.qpa.wayland.backingstore: Buffer already comitted, ignoring." Mar 20 11:48:09 Tofe: only small part of the issue, we still have libhybris as the provider, so whatever depends on virtual/egl is efectivelly different for androind machines and the rest Mar 20 11:49:35 but at least wayland gets to stay in common arm recipes Mar 20 11:52:07 * Tofe feels he has missed a point :) Mar 20 11:52:12 but than e.g. qtbase will depend on virtual/egl and it doesn't help much Mar 20 11:52:35 there are only a few recipes which depend on wayland and not on any virtual/*gl* Mar 20 11:53:12 and those few + wayland don't take much time to build, unlike the egl-specific stuff like qtbase and everything up from there Mar 20 11:53:34 yup, ok Mar 20 11:55:24 what about always disabling libwayland-egl in wayland recipe, and provide a separate recipe which only provides this and ignores the rest of wayland output ? Mar 20 11:55:50 looks messy only by writing it Mar 20 12:01:04 like moving it back to mesa :) Mar 20 12:01:46 at least we're not the only one with this issue Mar 20 12:02:10 exactly Mar 20 12:02:13 all machines with custom gl stack have this and get away only because not many people use the same TUNE_PKGARCH for many different MACHINEs Mar 20 12:04:44 for rpi there is a hope in vc4 and for hammerhead and others in mainlining them :) Mar 20 12:16:31 btw in local incremental build this will cause errors like this: Mar 20 12:16:33 ERROR: luna-sysmgr-common-3.0.0-3+gitAUTOINC+5831362832-r0 do_package: [Errno 17] File exists: '/OE/build/luneos-master/webos-ports/tmp-glibc/sysroots-components/tissot/libhybris/usr/lib/libwayland-egl.so.1.0.0' -> '/OE/build/luneos-master/webos-ports/tmp-glibc/work/aarch64-webos-linux/luna-sysmgr-common/3.0.0-3+gitAUTOINC+5831362832-r0/recipe-sysroot/usr/lib/libwayland-egl.so.1.0.0' Mar 20 12:16:44 you need to manually clean the RSS of affected components Mar 20 12:16:54 or just delete whole tmp-glibc Mar 20 12:17:35 ok, yes that's not surprising Mar 20 12:18:22 gosh, why didn't they do a separate library like libinput ... Mar 20 12:21:01 it wouldn't change much, we would end with different provider for this library, so again the only difference would be wayland itself (unless it would be depending on this library as well for some reason) Mar 20 12:21:54 we would need stable API and more importantly ABI to make these drop-in replacements for different MACHINEs to install different one without influencing anything above Mar 20 12:22:51 and then we would need to extend OE to define that something matches with well defined/known API/ABI and never needs to be rebuilt as long as the same API/ABI version is defined somewhere in the recipe Mar 20 12:23:37 still, something I didn't completely understand: the implementation of this library is kindof identical between libhybris, mesa and wayland, isn't it ? Mar 20 12:24:06 now we can only say that e.g. qtbase never needs to rebuild no matter how much libhybris was changed or that it always needs to be rebuilt when the signature of libhybris changed (even if it was just summary description in its .ipk package) Mar 20 12:24:25 yes, from API POV Mar 20 12:25:16 and only kindof, because some alternative gl stacks also provide own header files which are sometimes forked from some older mesa, sometimes with small modifications on top Mar 20 12:25:43 so as first step we would need everything to use header files from mesa only to define API there Mar 20 12:25:58 no, I really mean the implementation: https://github.com/wayland-project/wayland/blob/1.16/egl/wayland-egl.c vs https://github.com/libhybris/libhybris/blob/07b547e90db625685050bdfd00c92ccafc64aa09/hybris/egl/platforms/common/wayland-egl.c Mar 20 12:26:34 - though there must be a difference in the ABI, of course, because otherwise it wouldn't crash at all - Mar 20 12:27:03 oh, some have modified the API ... ok then Mar 20 12:27:35 and for ABI you also have different library names/versions, so something linked against mesa-gl and some custom binary stack like in rpi's userland won't load the same libraries Mar 20 12:28:54 some require extra libraries, so your qtbase binary might get linked with e.g. libmali.so as well Mar 20 12:29:31 I see, there are some binary blobs that already require a certain libwayland-egl API/ABI Mar 20 12:29:42 and then you cannot use it on any other MACHINE which might provide similar (or the same) egl API, but your mesa packages won't provide this silly libmali.so Mar 20 12:30:23 or rather not require, but provide Mar 20 12:31:13 ok. What a mess, for a 100 LOC simple library... Mar 20 12:31:44 yes Mar 20 12:32:45 I wonder how nvidia proprietary drivers do this, maybe they are clever enough to provide identical API/ABI in their own /usr/lib/opengl/nvidia/lib/libEGL.so.1.1.0 Mar 20 12:33:26 maybe :) so far they didn't really have to care about that Mar 20 12:34:15 https://paste.ubuntu.com/p/YN4XxS4YNq/ Mar 20 12:34:48 the library is quite different, but e.g. in gentoo you can easily switch between the provider with "eselect opengl" Mar 20 12:35:08 and choose between proprietary nvidia version or xorg-x11 Mar 20 12:35:18 _without_ rebuilding anything on top of it Mar 20 12:36:00 with mali I see that the differences are "leaking" into the binaries which use them Mar 20 12:37:26 e.g. like that libmali.so which you need to link with or you get unresolved symbols in the app (instead of exposing only the same symbols as mesa does in library named the same (e.g. libEGL.so.1) Mar 20 12:38:20 userland on rpi has similar extra libraries as well, that's why qtbase needs to use pkg-config to get them all for linkage or get failed build because of symbols Mar 20 12:39:00 e.g. https://github.com/raspberrypi/userland/blob/master/pkgconfig/egl.pc.in Mar 20 12:39:11 Libs: -L${libdir} -lEGL -lGLESv2 -lbcm_host -lvchostif Mar 20 12:39:37 and you don't want your qtbase binaries to be linked with bcm_host if you plan to use them on e.g. hammerhead Mar 20 12:50:44 btw this is quite nice, recently someone linked it form oe-core ML https://abi-laboratory.pro/index.php?view=timeline&l=boost Mar 20 12:52:02 not the boost itself, but the visualization of many common libraries Mar 20 12:53:45 I was using abi-compliance-checker before and something from debian reproducible builds project I cannot remember the name, but something like diascope.. Mar 20 12:54:18 dev-util/diffoscope Mar 20 12:54:55 try.diffoscope.org Mar 20 12:55:02 hmm lets see these 2 libEGL :) Mar 20 12:56:11 https://try.diffoscope.org/rhrbvppdcvtx.html Mar 20 13:00:59 looks like the most interesting part with symbols was skipped due to report size, will use diffoscope locally Mar 20 20:39:22 JaMa: copying libhybris' libwayland-egl.so libs over the libwayland's ones did fix the crash Mar 20 20:39:49 good, you beat me to it again, still waiting for the builds to finish :/ Mar 20 20:39:55 :) Mar 20 20:40:11 NOTE: Running task 4951 of 7496 with warrior Mar 20 20:40:19 and I had time to go to a wine-tasting meeting in-between! Mar 20 20:40:23 NOTE: Running task 4859 of 6590 with master Mar 20 20:40:50 I went to change winter tires (expecting builds to be finished when I return) Mar 20 20:41:13 well my build was already ready :) Mar 20 20:41:40 my was almost ready, but then i got that great idea to include another small change .. Mar 20 20:41:44 but, at least, we now know that it's really the good lead Mar 20 20:42:02 ok, lets see if warrior build works Mar 20 20:42:15 if it fails on something else, I'll cherry-pick it to thud Mar 20 20:42:27 qemux86 build is almost finished on jenkins, tissot is next in queue Mar 20 20:42:39 [16069/18052] CXX v8_snapshot/obj/third_party/icu/bundled_icuuc/uloc.o Mar 20 20:42:47 ^ is the qtwebengine qemux86 build on jenkins Mar 20 20:43:24 what is the qemux86 status, by the way ? still struggling with this egl driver thing? Mar 20 20:43:43 not the egl, but vboxtouch plugin Mar 20 20:43:49 oh. Mar 20 20:44:08 https://paste.ubuntu.com/p/gJktWTFKfC/ Mar 20 20:44:40 ioctl's issued by vboxtouch plugin all fail now since the vbox modules upgrade Mar 20 20:45:01 I've fixed the crach in vboxtouch itself (failing to shutdown properly when it cannot init touch) Mar 20 20:45:20 that fixed the UI to start, but the touch doesn't work still Mar 20 20:50:13 ok, I hope it's just something simple... Mar 20 20:50:23 * JaMa too Mar 20 20:50:39 Tissot seems to be on-par for thud, with the wayland-egl fix stuff Mar 20 20:51:14 I can't say for hammerhead though, it would probably be best to just build it on bonaire Mar 20 20:51:30 I was hoping to compare the old vbox external kernel modules with the current modules from vanilla kernel staging, but they are completely different it seems Mar 20 20:52:00 do you still have the links? Mar 20 20:52:17 and debugging from qt app through plugin to kernel module in vbox and then to kernel module in host system doesn't make it much easier to understand what's going on Mar 20 20:52:24 links for what? Mar 20 20:52:43 the old vbox external kernel modules versus the current modules from vanilla kernel staging Mar 20 20:52:59 I have it all loaded in visual-studio Mar 20 20:53:38 it's a shame they don't just emulate a /dev/input/eventX hardware Mar 20 20:54:42 yes, that's the other option probably to somehow emulate it, because it's surprising that vboxtouch plugin doesn't seem to be used by anyone, so there must be some way to do it differently Mar 20 20:55:14 in webOS (OSE) emulator we never used vboxtouch IIRC Mar 20 20:56:01 for vboxtouch qt plugin, we're talking about http://layers.openembedded.org/layerindex/recipe/71323/, right? Mar 20 20:56:01 but LGE had own qpa for emulator which was using nyx for touch IIRC Mar 20 20:56:23 correct Mar 20 20:56:26 ok Mar 20 20:57:00 with webOS OSE using qemu instead of VirtualBox it is using the qpa from upstream with some small fixes Mar 20 20:57:21 so that could be another option to stop using VirtualBox, but I'm not ready to give up on it Mar 20 20:59:54 where is that staging vanilla driver ? Mar 20 21:00:11 I only see vboxvideo Mar 20 21:00:18 * I looked at virtualbox source code to figure out the interface of Mar 20 21:00:18 * the vboxguest ioctls used here, but I didn't copy any of that code. Mar 20 21:00:18 * Richard Braakman Mar 20 21:00:23 hehe & Mar 20 21:00:28 https://github.com/nemomobile/qt5-plugin-generic-vboxtouch/blob/master/vboxtouch/vboxtouch.cpp#L50 Mar 20 21:00:40 that's why it all looks like magic numbers to me Mar 20 21:01:13 Tofe: vboxguest kernel/linux/drivers/virt/vboxguest Mar 20 21:01:24 :) Mar 20 21:02:47 I've overlooked vboxguest at first as well, so we were using vboxvideo from linux-yocto and vboxguest from externally built modules Mar 20 21:03:28 then when it was crashing like this I've noticed vboxguest and got rid of externally built one (assuming it will resolve some incompatibility between the 2) Mar 20 21:03:42 "meh", vboxguest just rewrites evdev events all over... Mar 20 21:04:44 yes and does some things on top like changing the cursor shape, some coordinates changes when you resize vbox window etc Mar 20 21:06:36 https://github.com/webOS-ports/meta-webos-ports/commit/42e290089146987b9dab8890c1bd26fea085bc96 Mar 20 21:07:24 yup, good Mar 20 21:07:45 https://github.com/meta-qt5/meta-qt5/commit/201fcf27cf07d60b7d6ab89c7dcefe2190217745 Mar 20 21:10:41 ah, it was just an uninitialized attribute... classic, but efficient :) Mar 20 21:12:00 but that was just side effect of ioctl failing and plugin shutdown crashing the luna-next as well Mar 20 21:15:20 Here are some of the magic number that are use: https://github.com/torvalds/linux/blob/6f0d349d922ba44e4348a17a78ea51b7135965b1/include/uapi/linux/vboxguest.h#L223 versus https://github.com/nemomobile/qt5-plugin-generic-vboxtouch/blob/master/vboxtouch/vboxtouch.cpp#L116 Mar 20 21:15:32 (both for logs, for me and for you :) ) Mar 20 21:17:01 this example is actually good: the ioctl seems to have changed. If I'm correct, it should now be : https://github.com/torvalds/linux/blob/6f0d349d922ba44e4348a17a78ea51b7135965b1/include/uapi/linux/vboxguest.h#L282 Mar 20 21:17:27 but I don't have the source code of the previous external module to compare Mar 20 21:19:08 you're really good at this :) Mar 20 21:19:52 I usually get some priority interrupt between finding the first 2 links and finding the matching 3rd one :) Mar 20 21:20:11 :) Mar 20 21:20:24 like now, qtwebengine build finished, so I'm back looking if the build will finish correctly :) Mar 20 21:23:15 damn 3 failures Mar 20 21:25:46 gosh, the vboxtouch driver is using a quite different API than what's in the kernel... a lot has changed... But, now the API is public :) Mar 20 21:31:23 still, it's mainly the kernel's data structures that have changed. The module's function flow is still correct it seems. Mar 20 21:33:11 got a fix for the 3 failures, testing it now Mar 20 21:40:03 Tofe: https://github.com/shr-project/VirtualBox-kernel-module-src Mar 20 21:40:16 thanks Mar 20 21:40:44 sec, these are the host modules Mar 20 21:40:57 should find the guest ones as well Mar 20 21:41:59 ah ./meta-oe/recipes-support/vboxguestdrivers/vboxguestdrivers_5.2.22.bb downloads the VirtualBox archive itself Mar 20 21:42:10 ok :p Mar 20 21:43:03 but nevermind, maybe it's possible to adapt the vboxtouch driver with what we havze Mar 20 21:43:15 https://github.com/shr-project/VirtualBox-source Mar 20 21:43:17 it's just 2-3 ioctls to adapt, after all Mar 20 21:43:38 but it's just unpacked archives + the patches applied Mar 20 21:46:15 I think I'll sleep on this -- I'll need my own qemux86 build anyway if I want to try and hack around... Mar 20 21:51:02 ok, gnight Mar 20 22:20:47 I've found an issue with our premirror setting, we're using: http://sources.webos-ports.org/webos-ports/ but the webos-ports was actually just a symlink to his parent directory (the files are in http://sources.webos-ports.org/) and somehow it got lost somewhere Mar 20 22:21:18 I've recreated symlink and now you shouldn't see any exiv2 or other fetch issues (if jenkins builds can build it at least once) Mar 20 22:23:49 Tofe: do you still need swrast for hammerhead-mainline or is freedreno working fine for you now? Mar 20 22:24:08 Tofe: I've removed all gallium drivers (including swrast) when removing svga, so now this meta-luneos/recipes-core/packagegroups/packagegroup-luneos-extended.bb:RDEPENDS_${PN}_append_hammerhead = " alsa-utils-systemd mesa-driver-swrast" Mar 20 22:24:15 depends on non-existent package Mar 20 22:46:41 Tofe: this seems to have the history from svn, this function should be the first ioctl: https://github.com/mdaniel/virtualbox-org-svn-vbox-trunk/blob/master/src/VBox/Additions/common/VBoxGuest/VBoxGuest.cpp#L2789 Mar 20 23:05:51 hmm tissot image with debug symbols is too big for sideload it seems, from recovery.log: Mar 20 23:05:54 sideload-host file size -1323621225 block size 65536 Mar 20 23:05:57 file has too many blocks (4294947100) Mar 20 23:06:00 fuse_sideload umount failed: Invalid argument Mar 20 23:06:25 it's quite big: -rw-r--r-- 1 bitbake bitbake 2.8G Mar 20 23:55 luneos-dev-package-tissot--1.0.2+gitAUTOINC+12c8eb4d79-r0-20190320225202.zip Mar 20 23:25:32 smaller luneos-package (without debug symbols) can sideload ok, but doesn't boot, guess will try again tomorrow with the warrior build from jenkins (fingers crossed for successful build now) **** ENDING LOGGING AT Thu Mar 21 02:59:57 2019