**** BEGIN LOGGING AT Fri Sep 08 03:00:00 2017 Sep 08 04:31:56 JaMa: Thnx Sep 08 05:22:34 JaMa: ah, yes, thanks Sep 08 07:06:48 and Morning :) Sep 08 07:43:23 Tofe: Now that the switches are in webengine code they should be removed from luna-webappmanager I guess? Sep 08 07:45:37 Herrie|Work: yes, with some care though: I didn't include all the switches (like accessFiles) and we should first double-check that the new switches actually work :) Sep 08 07:49:22 Ah ok Sep 08 07:49:25 Also with these fixes we *should* be able to remove that patch https://github.com/webOS-ports/meta-webos-ports/blob/master/meta-luneui/recipes-qt/qt5/qtwebengine/chromium/0009-Disable-some-sandboxing-capabilities.patch Sep 08 07:50:34 I'll try these modifications on my end Sep 08 07:51:01 Tofe: OK Sep 08 08:11:43 Seems my qemux86-64 build finished and is waiting for me at home Sep 08 08:11:49 I doubt it will boot, but who knows :P Sep 08 08:12:36 Herrie|Work: one thing I'd like to try in the short term is Qt's hi-dpi code Sep 08 08:12:53 Tofe: OK :) Sep 08 08:13:00 Any idea when we should push a release out? Sep 08 08:13:12 Herrie|Work: when we fix qemu, I think Sep 08 08:13:13 Would be good if we get qemux86 working I guess Sep 08 08:14:58 I'm waiting for my hammerhead build to finish (with the switches reworked), then I'll start a qemu build and help there Sep 08 08:20:43 Tofe: It must be something systemd probably since it works on Hammerhead Sep 08 08:20:51 Also luna-next crashes it seems Sep 08 08:20:56 So that might be due to some QT upgrade Sep 08 08:21:36 Herrie|Work: the crash might be related to too Mesa somehow Sep 08 08:21:51 But having ssh working is a must to be able to debug the rest Sep 08 08:28:43 JaMa wanted to update Mesa as well he said Sep 08 08:28:50 We're on a very old one due to qpa or something Sep 08 08:28:54 Would need to check logs Sep 08 08:28:57 JaMa: ^ Sep 08 08:55:05 Herrie|Work: yes, we're still using very old mesa because of fbdev Sep 08 08:55:49 that didn't change in pyro, but for master I gave up on trying to keep this old mesa usable with latest dependnecies (like new llvm) Sep 08 09:04:48 JaMa: we use mesa-10.6 ? Sep 08 09:07:04 meta-webos-ports/meta-luneos/recipes-graphics/mesa/mesa_10.3.7.bb Sep 08 09:07:13 oh, 10.3... Sep 08 09:07:23 last one where it worked like this Sep 08 09:08:01 JaMa: what break if we just use upstream mesa ? Sep 08 09:08:06 breaks* Sep 08 09:08:11 and there is conflict between uvesafb and vboxvideo kernel module Sep 08 09:08:31 fix was recently backported to pyro, so it might work better now in latest image Sep 08 09:08:55 Tofe: I don't remember the details, check the commit message for this mesa recipe Sep 08 09:09:07 ok Sep 08 09:09:27 Tofe: it was something with fbdev0 expected by our QPA or LSM directly isn't available with newer mesa Sep 08 09:10:03 newer mesa exposes only dri/kms and your graphics wasn't compatible with it Sep 08 09:10:31 we might try to switch from virtualbox to qemu and use virtgl, but that also isn't ideal Sep 08 09:10:46 as qemu with virtgl support isn't available in any host DISTRO Sep 08 09:11:00 and there are no recipes for virtglrenderer-native in oe Sep 08 09:11:10 http://lists.openembedded.org/pipermail/openembedded-core/2017-September/141684.html Sep 08 09:11:13 mmh Sep 08 09:12:13 uvesafb is provided by the old mesa right? Sep 08 09:12:48 uvesafb is kernel module not from mesa Sep 08 09:13:08 ah ok Sep 08 09:13:17 and there is race condition between vboxvideo and uvesafb which one will initiallize the fbdev driver Sep 08 09:13:25 we have resolution configured for uvesafb Sep 08 09:13:43 but when vboxvideo loads and initiallizes it sooner it causes uvesafb to fail Sep 08 09:13:52 and then surface-manager crashes Sep 08 09:14:16 maybe we can disable vboxvideo Sep 08 09:15:11 Tofe: yes, that's what I did, blacklist vboxvideo and load uvesafb a bit sooner Sep 08 09:15:22 http://git.openembedded.org/openembedded-core/commit/?h=pyro&id=3a8613a101aebf4f2a75ea95dac72202bbda8238 Sep 08 09:16:10 ok :) Sep 08 09:16:28 maybe we're missing the vboxvideo blacklist in LuneOS, let me check Sep 08 09:18:51 no, not missing it, I did both in LuneOS in 713deaf3255a9afccc635de49b853a54bc654aab Sep 08 09:19:31 https://github.com/webOS-ports/meta-webos-ports/commit/713deaf3255a9afccc635de49b853a54bc654aab Sep 08 09:19:33 ok Sep 08 09:20:12 something I didn't really understand, doesn't uvesafb create the fbdev0 device ? Sep 08 09:20:55 but the resolution isn't set correctly in current pyro image Sep 08 09:20:59 I see "options uvesafb mode_option=640x480-32" Sep 08 09:21:06 instead of 1024x768-32 Sep 08 09:22:41 hmm it looks like I haven't wrote it in commit message in meta-webos-ports, let me find the links to discussion in some other secret repos :) Sep 08 09:22:50 :) Sep 08 09:25:39 10.3.7 is last mesa version where fbdev+eglfs works correctly, see Sep 08 09:25:40 https://github.com/webOS-ports/meta-webos-ports/commit/ab0a72f8f3c44b0ab486ac568c90d8d806459705 Sep 08 09:25:42 https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg68503.html Sep 08 09:25:45 http://lists.openembedded.org/pipermail/openembedded-core/2015-February/101922.html Sep 08 09:27:48 oh ok, they completely dropped support in mesa itself Sep 08 09:27:54 that's what I didn't catch Sep 08 09:28:49 maybe the QPA or whatever was the reason back then no longer depends on this fbdev+eglfs Sep 08 09:29:32 maybe, I don't know Sep 08 09:29:39 we've internally switched to virglrendered + latest mesa recently without many changes to qtbase, but I don't want to touch this area Sep 08 09:30:03 in case someone considers this private IP now Sep 08 09:31:41 ok **** BEGIN LOGGING AT Fri Sep 08 10:56:16 2017 Sep 08 13:53:20 all is built now for me (n5 and qemu), testing isn't far away! Sep 08 16:24:55 Herrie|2: the whole QtWebEngine switches thing seems to work Sep 08 16:25:17 Herrie|2: can you just check that you also get a crash on html5test.com ? Sep 08 16:26:54 Tofe: how did you test qtubuntu-camera? Here it fails with: | Project ERROR: exiv2 development package not found Sep 08 16:27:33 and the bzr installation isn't enough, we will need http://lists.openembedded.org/pipermail/openembedded-core/2017-September/141976.html applied in oe-core master and pyro Sep 08 16:27:36 JaMa: just a bb qtubuntu-camera on hammerhead, Sep 08 16:27:59 but I've built it manually on bonaire so it should populate the premirror with right bzr bits Sep 08 16:28:15 now building libqtubuntu-media-signals Sep 08 16:28:18 JaMa: I don't have that patch, at least I think Sep 08 16:28:34 strange, then it should fail the same for you (as with RSS) Sep 08 16:28:49 can you check that the version which was merged in master is the same as what you have locally? Sep 08 16:29:05 one moment Sep 08 16:29:19 Tofe: you don't have that patch (I've just sent it to ML), but you could have the local premirror already prepopulated from previous release Sep 08 16:29:54 Tofe: it's just missing dependency, I just wanted to check if there is something else missing as well Sep 08 16:30:17 master commit looks good Sep 08 16:30:29 strange Sep 08 16:31:43 ./src/src.pro:PKGCONFIG += exiv2 libqtubuntu-media-signals libmedia libcamera hybris-egl-platform libpulse-simple Sep 08 16:31:54 ./unittests/storagemanager/storagemanager.pro:PKGCONFIG += exiv2 Sep 08 16:32:02 here's what I did, incrementally: 1. re-enable the recipe, 2. try the build --> fail like for you, 3. empty the ${S}/.qmake.conf by hand --> it passes, 4. modify the recipe to remove that file before configure, start a bb luneos-dev-package --> ok Sep 08 16:32:35 the .qmake.conf file is brought from the upstream repo, and is quite nasty Sep 08 16:32:51 it overloads the PKG_CONFIG env variables Sep 08 16:33:08 hmm even more strange Sep 08 16:33:09 DEPENDS = "libhybris qtbase libqtubuntu-media-signals exiv2 qtmultimedia pulseaudio" Sep 08 16:33:47 configure_prepend() { Sep 08 16:33:52 you're missind do_ here Sep 08 16:34:11 buiding again Sep 08 16:34:19 oh. but I thought it would re-fetch ? ah nooo... oops. Sep 08 16:35:19 and, of course, declaring a function with an unknown name is no issue at all, so no complains Sep 08 16:35:49 I've been sloppy here :) Sep 08 16:36:00 ok that fixed it, will push the fix Sep 08 16:36:12 ok thanks Sep 08 17:01:59 I've tried to boot both qemux86 and qemux86-64 built with pyro and both are stuck after "booting the kernel.". After a while some graphics artefacts are shown (which looks like when the uvesafb and vboxvideo conflicted) and ssh is stuck as well (there were some fixes on oe-core ML for ssh key generation with systemd maybe this issue exists in pyro as well) Sep 08 17:02:05 next step booting it with qemu Sep 08 17:02:44 and fixing that uvesafb resolution Sep 08 17:10:24 QEMU_AUDIO_DRV=alsa qemu-system-i386 -enable-kvm -m 2048M -drive file=luneos-dev-emulator-qemux86-20170907102314.vmdk,if=virtio -serial stdio -show-cursor -usbdevice tablet -soundhw hda -net nic -net user,hostfwd=tcp::6622-:22 -kernel bzImage--4.10.17+git0+e92bd55409_6648a34e00-r0-qemux86-20170906231808.bin -append root=/dev/vda2 Sep 08 17:11:16 works fine after 1st boot in which you disable all vbox modules (to let the systemd continue until sshd start) root@qemux86:~# rm /etc/modules-load.d/vbox* Sep 08 17:25:50 QEMU_AUDIO_DRV=alsa qemu-system-i386 -enable-kvm -m 2048M -drive file=luneos-dev-emulator-qemux86-20170907102314.vmdk,if=virtio -serial stdio -show-cursor -usb -device usb-tablet -soundhw hda -net nic -net user,hostfwd=tcp::6622-:22 -kernel bzImage--4.10.17+git0+e92bd55409_6648a34e00-r0-qemux86-20170906231808.bin -append root=/dev/vda2 -device virtio-vga,virgl Sep 08 17:26:14 works as well in newer qemu 2.10.0 with virgl support enabled Sep 08 17:30:21 Tofe: luna-next fails to start in it, do you see anything obvious? https://pastebin.com/mhR76YDL Sep 08 17:30:59 oh, I didn't see your messages, let me catch up Sep 08 17:31:38 might be related to https://bugreports.qt.io/browse/QTBUG-61156 Sep 08 17:34:32 JaMa: yes, that's a good guess Sep 08 17:34:41 now what's our eglfs configuration... Sep 08 17:36:56 do you have some older qemux86 image built with pyro, but with qt 5.7 or 5.8? Sep 08 17:37:33 maybe Sep 08 17:38:00 http://build.webos-ports.org/luneos-testing/images/qemux86/luneos-dev-emulator-qemux86-20170805233956-testing-0-460.zip is my best guess Sep 08 17:45:33 ok fetching it now, will test it tomorrow (if current qtwebengine build is finished soon) Sep 08 17:46:34 ok :) Sep 08 17:46:46 that's already good progress, I can login in qemu too Sep 08 17:51:02 this 460 build booted and shows UI in VirtualBox Sep 08 17:51:46 but no luck with ssh Sep 08 17:51:58 ok, so we have half of it there :) Sep 08 17:52:00 or clicking on Continue :) Sep 08 17:52:08 so one third Sep 08 17:52:21 well, we can get a login shell Sep 08 17:52:25 with qemu Sep 08 17:52:40 that's good, we can debug it that way Sep 08 17:52:50 agreed Sep 08 17:57:05 http://lists.openembedded.org/pipermail/openembedded-core/2017-September/141895.html Sep 08 17:57:47 https://patchwork.openembedded.org/patch/141502/ Sep 08 17:58:43 but if it's broken only for read-only rootfs then probably not related to the issue we're seeing Sep 08 18:32:12 mmh I could log in ssh just right now Sep 08 18:32:19 I didn't do anything special Sep 08 18:50:02 "vboxtouch: Using vbox device /dev/vboxguest " , then "vboxtouch: cannot open /dev/vboxguest" Sep 08 18:51:23 ah but it's qemu, silly me Sep 08 19:06:12 ok, selecting the "virtio" network card in VirutalBox lets us go into ssh Sep 08 19:08:04 "vboxtouch init: cannot open evdev mouse /dev/input/by-path/platform-i8042-serio-1-event-mouse" Sep 08 19:13:32 good find, works for me as well Sep 08 19:15:02 now, the vboxtouch seems a bit off Sep 08 19:16:02 is that from the qt5-plugin-vboxtouch recipe? Sep 08 19:16:08 I think so Sep 08 19:16:46 it's not retrieving the correct device path it seems Sep 08 19:19:27 ah, the path can be overloaded with VIRTUALBOX_TOUCH_EVDEV_MOUSE env variable Sep 08 19:29:21 Tofe: Seems like progress :D Sep 08 19:29:56 yup Sep 08 19:30:17 could it be the kernel config changed, and the i8042 driver has been ruled out ? Sep 08 19:30:48 time to trigger raspberrypi3-64 and qemux86-64 jobs and go to bed, cya tomorrow Sep 08 19:31:03 Tofe: it surely could be different kernel config with new kernel Sep 08 19:31:47 maybe even the network issue rings a bell, IIRC newer kernel didn't have the driver for the default network card so I had to change it to something else Sep 08 19:31:48 "CONFIG_SERIO_I8042=y" so there's something at least Sep 08 19:34:16 "ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input5" maybe that path ? Sep 08 19:36:16 https://github.com/webOS-ports/meta-webos-ports/commit/b93d4754ae0a7b8af765b3662dea9915103ec663 Sep 08 19:36:29 rings a bell but was already done ^^ Sep 08 19:36:41 got it, /dev/input/event4 Sep 08 19:37:49 though I'd better find a more stable path Sep 08 19:38:11 Tofe: https://github.com/webOS-ports/meta-webos-ports/commit/b93d4754ae0a7b8af765b3662dea9915103ec663 Sep 08 19:38:22 That's the change for network card Sep 08 19:38:41 Herrie|Laptop: you've been beaten by JaMa :) Sep 08 19:42:13 why isn't there any "by-path" for event4 ? Sep 08 19:43:39 Tofe: This VBOX/Qemu is even more of a black box for me compared to actual targets LOL Sep 08 19:44:02 :p Sep 08 19:57:04 must be a missing udev rule, but I don't really see why that would have changed Sep 08 19:58:19 Well the thing with Qemu is that the kernel constantly updates :P Sep 08 19:58:31 Not like our real targets :P Sep 08 19:58:38 hehe yes Sep 08 19:58:40 Which are a lot more stable in terms of kernel version :P Sep 08 19:58:48 So also lots of small kernel configs can change Sep 08 20:06:13 I'll continue investigating a bit later, but this issue is now a bit less blocking Sep 08 20:11:20 Getting to SSH in already helps Sep 08 20:11:46 You're on a 5.7/5.8 or 5.9 already? **** ENDING LOGGING AT Sat Sep 09 03:00:00 2017