**** BEGIN LOGGING AT Fri Apr 05 02:59:57 2019 Apr 05 05:52:18 Morning! Apr 05 06:36:37 Morning! Apr 05 06:36:57 JaMa: nope, that's called "night" :-p Apr 05 07:42:21 Tofe: ah, right, morning? Apr 05 07:42:41 Tofe: looks like your v2 webengine patch built OK Apr 05 07:56:38 wow ! Apr 05 09:24:04 I've flashed updated 5.12 build on tissot and the bluetooth issue (and black screen) is still there: Apr 05 09:24:07 Apr 04 09:49:35 tissot luna-next[2031]: WARNING: 07:49:35.619: file:///usr/palm/luna-next/shells/card/qml/StatusBar/SystemMenu/BluetoothElement.qml:23:1: plugin cannot be loaded for module "LuneOS.Bluetooth": Cannot load library /usr/lib/qml/LuneOS/Bluetooth/libLuneOSBluetooth.so: (/usr/lib/qml/LuneOS/Bluetooth/libLuneOSBluetooth.so: undefined symbol: _ZN7BluezQt5Agent16staticMetaObjectE) Apr 05 09:24:27 so it wasn't temporary issue from my local tinkering with the build Apr 05 09:26:13 ok, that's annoying Apr 05 09:26:49 will do a build on jenkins once the testing builds are finished Apr 05 09:27:12 annoying, but at least it's reproducible and not in qtwebengine :) Apr 05 09:28:22 if you want to go further, you can comment out this whole block: https://github.com/webOS-ports/luna-next-cardshell/blob/77659074d7f82732766904c413cbece0501f399c/qml/StatusBar/SystemMenu/SystemMenu.qml#L250 Apr 05 09:28:33 heh, just did :) Apr 05 09:29:15 I'm curious as to if the sync call in webengine works at all Apr 05 09:29:50 load average: 4.81, 4.10, 2.16 Apr 05 09:30:05 luna-next and qtwebengine were taking quite a lot of resources Apr 05 09:30:21 which might be side effect of one of the issues Apr 05 09:30:51 but luna-next doesn't want to stop now (to restart after updating the SystemMenu Apr 05 09:31:13 that's an issue with the pulseaudio android driver, I think Apr 05 09:31:26 usually I kill it violently Apr 05 09:31:45 file:///usr/palm/luna-next/shells/card/qml/StatusBar/SystemIndicators.qml:24:1: needs update as well Apr 05 09:31:46 it's been there on tissot since the beginning Apr 05 09:32:51 ah right, well this one should be easy enough I guess Apr 05 09:35:03 I'm surprised that you only get this issue with the bluez5 lib... there must be something specific to this recipe or source code Apr 05 10:32:34 sorry, had to take care of kid, but when returned the UI is shown, doesn't respond to touch, I haven't checked anything else yet Apr 05 11:08:28 definitely died a bit: adb shell Apr 05 11:08:29 error: closed Apr 05 11:09:50 but UI works fine after reboot Apr 05 11:10:06 Tofe: any good test case for the sync all? Apr 05 11:10:53 and should I temporarily drop the bluetooth with .patch file, so that qt 5.12 is a bit usable on first boot? Apr 05 11:11:58 browser works, accidentally tested mobile data as well Apr 05 11:13:50 better test some enyo apps Apr 05 11:14:34 trying to get wifi now, but wifi app doesn't react to network selection Apr 05 11:14:35 I guess Testr uses it too, here and there Apr 05 11:15:31 or rather it takes longer than my patience allowed :) Apr 05 11:17:41 I quite don't remember where these calls are most used, let me see... Apr 05 11:17:48 PalmBus subscriptions in Testr seem to fail Apr 05 11:18:14 but will need to compare with known-to-work image to be sure how it should look like when it works :) Apr 05 11:21:32 is wifi expected to have different MAC? that's probably why it was failing to connect for me Apr 05 11:21:39 (PalmSystem.addBannerMessage uses it, and PalmSystem.getResource also) Apr 05 11:21:48 different than in android I mean Apr 05 11:23:09 Mac has often been a problem, yes Apr 05 11:23:30 we try to generate one at first boot and stick to it, but I didn't test it for a long time Apr 05 11:23:50 also we try to fetch the one from android, but maybe it fails Apr 05 11:25:32 https://github.com/webOS-ports/org.webosports.app.testr/blob/afeb9ad17a79f3d3ea8c27a465213f8d34cc1b42/source/views/Notifications.js#L142 Testr uses sync calls for banner notifications Apr 05 11:27:26 wifi works (after adding MAC to my router) Apr 05 11:29:45 ok, good Apr 05 11:31:20 2019-04-05T11:28:04.810701Z [1158] user.warning activitymanager [] DB8 MOJ_SERVICE_WARNING {"sender":"org.webosports.app.testr 1016","method":"create","payload":{"activity":{"description":1016,"name":"org.webosports.app.testr","type":{"foreground":true}},"replace":true,"start":true,"subscribe":true},"error":"invalid parameters: caller='org.webosports.app.testr 1016' error='invalid type for property Apr 05 11:31:26 'description' for property 'activity''","reqErr":22} Apr 05 11:31:41 this is the only error in messages, but banner notifications in Testr doesn't seem to work Apr 05 11:31:53 ok, not good :) Apr 05 11:32:07 I'll test that from home Apr 05 11:32:22 there are images out there I guess? Apr 05 11:32:51 only my local one, on jenkins still doing the testing builds (with 5.11) Apr 05 11:33:08 but I've disabled rpi builds on jenkins, so should get to unstable soon(ish) Apr 05 11:33:18 or I'll upload mine Apr 05 11:34:39 should I patch out the Bluetooth now (to unblock testing other thing OOTB) or spend some time on it now? Apr 05 11:34:40 either way is fine Apr 05 11:35:00 my build is almost finished NOTE: Running task 6247 of 6683 to tinker a bit more Apr 05 11:35:55 there aren't many libraries used by bluetooth.so: Apr 05 11:35:56 aarch64-webos-linux-g++ --sysroot=/OE/build/luneos-warrior/webos-ports/tmp-glibc/work/aarch64-webos-linux/luneos-components/0.4.1+gitrAUTOINC+729b4ac099-r0/recipe-sysroot -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed --sysroot=/OE/build/luneos-warrior/webos-ports/tmp-glibc/work/aarch64-webos-linux/luneos-components/0.4.1+gitrAUTOINC+729b4ac099-r0/recipe-sysroot -Wl,-O1 -shared -o libLuneOSBluetooth.so Apr 05 11:36:03 plugin.o luneosbtagent.o luneosbtrequest.o moc_plugin.o moc_luneosbtagent.o moc_luneosbtrequest.o -lQt5Quick -lQt5Gui -lQt5Qml -lQt5Network -lKF5BluezQt -lQt5DBus -lQt5Core -lGLESv2 -lpthread Apr 05 11:36:26 let me see where _ZN7BluezQt5Agent16staticMetaObjectE should come from Apr 05 11:36:36 Answer: KF5BluezQt Apr 05 11:36:40 kde-bluez5qt Apr 05 11:36:55 maybe s/kde/kf5/ Apr 05 11:37:24 https://github.com/webOS-ports/meta-webos-ports/blob/master/meta-luneos/recipes-connectivity/bluez5/kf5bluezqt-mer.bb Apr 05 11:37:26 through ./build/modules/LuneOS/Bluetooth/plugin/moc_luneosbtagent.o Apr 05 11:37:48 yes, the luneosbtagent class inherits it Apr 05 11:38:05 ./recipe-sysroot/usr/lib/libKF5BluezQt.so.5.24.0 Apr 05 11:55:03 does that one have the requested symbol ? Apr 05 11:56:23 so... it doesn't find libKF5BluezQt.so.5.24.0 ? or something else ? Apr 05 12:00:21 sec, too many distractions from kid today (wife is away) Apr 05 12:00:31 but the symbol wasn't there when I've checked Apr 05 12:02:18 if the symbol isn't there, then the issue is with kf5bluezqt-mer itself Apr 05 12:02:24 i.e. it's not exported Apr 05 12:03:58 yes, I'll compare with 5.11 build when I get to it Apr 05 12:32:40 heh and I was looking in 5.11 workdir already, now switched to 5.12 and it looks the same, digging a bit more Apr 05 12:35:04 you mean, in both case the symbol isn't in libKF5BluezQt.so.5.24.0 ? Apr 05 12:40:28 from the WORKDIR both 5.11 and 5.12 look the same with this symbol Apr 05 12:40:29 https://paste.ubuntu.com/p/dGDn5FrV3w/ Apr 05 12:40:40 why it causes issue in runtime only with 5.12 isn't clear yet Apr 05 12:42:11 ok, yes, that's a mystery Apr 05 12:43:10 but then, also, does it mean this symbol isn't present in any binary on the device ?... Apr 05 13:08:29 good question, but package/usr/lib/qml/LuneOS/Bluetooth/libLuneOSBluetooth.so should be exactly the same as on device Apr 05 13:08:44 only exception could be prelink/mklibs during do_rootfs Apr 05 13:10:02 yes, it's identical one on target https://paste.ubuntu.com/p/x2WxBFxbpd/ Apr 05 13:10:47 "meh" Apr 05 13:14:49 the symbol isn't the difference Apr 05 13:14:51 but this is: Apr 05 13:14:52 NEEDED libQt5Qml.so.5 Apr 05 13:14:52 + NEEDED libKF5BluezQt.so.5 Apr 05 13:14:52 NEEDED libQt5DBus.so.5 Apr 05 13:15:11 should be easier to fix now Apr 05 13:16:42 -lKF5BluezQt is missing in the 5.12 build Apr 05 13:17:04 the command line I've pasted 2 hours ago was from warrior Apr 05 13:19:19 ah, ok! Apr 05 13:19:43 could it be my https://github.com/webOS-ports/meta-webos-ports/blob/master/meta-luneos/recipes-connectivity/bluez5/kf5bluezqt-mer/qt_BluezQt.pri somehow ? Apr 05 13:21:04 I was checking luneos-components side and there is modules/LuneOS/Bluetooth/plugin/plugin.pro:QT += qml quick BluezQt dbus Apr 05 13:21:41 will compare kf5bluezqt-mer builds Apr 05 13:22:13 at least it's not as foggy as earlier :) Apr 05 13:22:29 but the end result is clear: with 5.12 -lKF5BluezQt is missing in ./build/modules/LuneOS/Bluetooth/plugin/Makefile:LIBS = $(SUBLIBS) -lQt5Quick -lQt5Gui -lQt5Qml -lQt5Network -lKF5BluezQt -lQt5DBus -lQt5Core -lGLESv2 -lpthread Apr 05 13:22:47 should be simple enough to resolve even for me :) Apr 05 13:23:47 ok :) Apr 05 13:25:09 also checking https://cgit.kde.org/bluez-qt.git/log/ Apr 05 13:27:12 well, we use qmake on our side, not sure their CMake approach will help much Apr 05 13:29:02 I mean that kf5bluezqt wasn't updated in 2 years, while bluez-qt is still quite active, so I was looking what they are working on Apr 05 13:31:09 ah ok Apr 05 13:31:32 speaking of which, there's a little SRCREV bump possible for kf5bluezqt-mer Apr 05 13:32:31 but fixing the link issue should be done first to keep identical version between 5.11 and 5.12 Apr 05 13:34:35 agreed and it looks like the difference might be in luneos-components Apr 05 13:34:51 the kf5bluezqt-mer sysroot is identical in both Apr 05 13:35:16 luneos-components.do_configure log doesn't show anything suspicious as well, running qmake with debug now Apr 05 13:35:20 https://github.com/frankosterfeld/qtkeychain/commit/4a9e58b0eac4af17dfca4ccd0796a44244700991 mmmh is there a line missing in my .pri ? Apr 05 13:36:01 looks goo Apr 05 13:36:03 d Apr 05 13:36:31 let's add a line with .module = KF5BluezQt Apr 05 13:37:27 https://codereview.qt-project.org/#/c/248684/2/mkspecs/features/qt.prf Apr 05 13:40:36 yes, that helps qmake -d diff http://dpaste.com/0RQDAAT Apr 05 13:41:03 good ! Problem solved Apr 05 13:41:33 just in time for unstable build :) Apr 05 13:42:44 should switch the highlighting on the paste, as it's not that clear with such long lines without colors Apr 05 13:43:53 the lib is correctly added on line 86 and whole block before wasn't executed because of qt.prf:209: calling built-in isEmpty(MODULE_MODULE) condition Apr 05 14:14:29 hmm the build I've finished over night probably didn't have the qtwebengine patch for the sync Apr 05 14:15:09 I've forgot to update meta-webos-ports layer between killing the job after qemux86-64 was finished and restarted for qemux86, tissot and hammerhead Apr 05 14:15:21 that might explain why the banner test from Testr didn't work Apr 05 14:15:34 and it will cause another over night build for me Apr 05 14:17:08 also there is some sstate signature issues in luna-webkit-api luna-sysmgr-ipc-messages rdx-utils-stub cpushareholder-stub as these are unpacked from sstate after each MACHINE change Apr 05 14:17:09 ...if it builds Apr 05 14:17:16 yeah.. Apr 05 14:18:14 what's luna-webkit-api ? Apr 05 14:19:26 oh. hum. is that really still used ? Apr 05 14:19:38 DESCRIPTION = "Public APIs for keyboard and field functionality in WebKit and LunaSysMgr" Apr 05 14:19:54 it's a dependency of something, which doesn't really prove it's used or useful Apr 05 14:19:57 I'll check a bit later Apr 05 14:20:19 luna-appmanager luna-sysmgr luna-sysmgr-common Apr 05 14:21:30 I'm pretty sure it could be merged with luna-sysmgr-common Apr 05 14:22:35 well luna-webkit-api is allarch, that's probably why it's "special" Apr 05 14:23:17 the same for other 3, will check why they don't have identical signature first Apr 05 14:24:27 cmake in allarch.. Apr 05 14:24:28 Variable OECMAKE_C_COMPILER value changed from 'arm-webos-linux-gnueabi-gcc' to 'aarch64-webos-linux-gcc' Apr 05 14:24:31 Variable OECMAKE_CXX_COMPILER value changed from 'arm-webos-linux-gnueabi-g++' to 'aarch64-webos-linux-g++' Apr 05 14:25:06 yup, bad idea Apr 05 14:25:29 though it should be possible theoretically Apr 05 14:27:52 https://patchwork.openembedded.org/patch/157226/ broke it Apr 05 15:06:30 http://jenkins.nas-admin.org/job/LuneOS/view/testing/job/luneos-testing_workspace-compare-signatures/115/console found few more issues (even wayland-native) but let me fix this allarch first to make it a bit clearer Apr 05 15:32:50 fun fact (I had no idea before), xiaomi (maybe others too) refuses to apply OTA update if you've mounted system partition as R/W (I did to backup before upgrading to Pie) Apr 05 15:32:55 04-05 17:13:42.653 1071 1071 W update_engine: [0405/171342.653624:WARNING:mount_history.cc(66)] Device was remounted R/W 2 times. Last remount happened on 2019-04-04 23:24:57.000 UTC. Apr 05 15:33:10 04-05 17:19:04.638 12182 12865 E SystemUpdate: [Execution,NonStreamingAbApplyAction] Installation failed with error code: 20. Apr 05 15:34:39 makes more sense after reading: Apr 05 15:34:40 04-05 16:45:56.530 1071 1071 E update_engine: [0405/164556.530100:ERROR:delta_performer.cc(990)] The hash of the source data on disk for this operation doesn't match the expected value. This could mean that the delta update payload was targeted for another version, or that the source partition was modified after it was installed, for example, by mounting a filesystem. Apr 05 15:36:09 I was wondering why system_a and systemd_b had different checksums :) Apr 05 16:56:32 mmmh I don't know what I did, but my qt build has been invalidated Apr 05 16:56:46 so, what brand new build will I do... Apr 05 16:57:05 maybe that's the occasion to disable networkd and resolved Apr 05 16:57:19 did you update oe-core? Apr 05 16:57:37 systemd (not systemd-conf) causes quite a big rebuild as well :/ Apr 05 16:58:05 do you already have a PR for that? I would include it in my local build (if I don't forget again) as well before big rebuild Apr 05 16:59:27 I'm not sure how to deselect these PACKAGECONFIG Apr 05 16:59:38 it's done in luneos.inc, right? Apr 05 16:59:57 we already have .bbappend for systemd, so I would do it there Apr 05 17:00:43 I guess you can disable logind as well at this point Apr 05 17:01:01 or not, you mentioned it for remote login, right? Apr 05 17:02:11 so if I have "PACKAGECONFIG[resolved] =...", I do "PACKAGECONFIG_remove_systemd += "resolved" ? Apr 05 17:02:48 yes, let's keep logind; when I masked it, also, it caused issues with shutdown Apr 05 17:02:58 in .bbappend you do only PACKAGECONFIG_remove = "resolved" Apr 05 17:03:06 ok, on it Apr 05 17:03:20 in luneos.inc you would do PACKAGECONFIG_remove_pn-systemd = "resolved" Apr 05 17:03:50 ok, makes sense Apr 05 17:04:02 I'll just check that systemd still builds... Apr 05 17:07:43 but it'll be something like https://github.com/webOS-ports/meta-webos-ports/pull/329 Apr 05 17:09:46 another small bump of oe-core if you want to include it as well Apr 05 17:10:04 I'll just check systemd, then I'll bump it yes Apr 05 17:10:22 ok including it in webos-ports-setup Apr 05 17:10:45 What if I want to test qt 5.12 ? Apr 05 17:10:56 I take unstable ? Apr 05 17:15:19 yes, but give me a bit longer, I'll update it a bit more Apr 05 17:15:43 I'll actually merge the qt5 PR into meta-webos-ports master branch now when it's almost ready Apr 05 17:15:57 and once it works there we'll cherry-pick all qt5 changes to warrior Apr 05 17:16:06 looks good Apr 05 17:16:15 take your time, there's no hurry at all here Apr 05 17:16:33 so unstable will be everything from master (currently the same as warrior branches) except meta-webos-ports where only difference will be qt5 Apr 05 17:16:59 mmmh I should test tenderloin, at some point Apr 05 17:17:31 the mdev change worries me, as TP doesn't use the exact same init.sh Apr 05 17:17:57 (speaking of which, I should probably streamline it better) Apr 05 17:19:38 ah, I already did the work when migrating to Halium... good ! Apr 05 17:20:03 will push small fix for allarch recipes at the same time Apr 05 17:21:24 hmm I haven't built the qtwebengine with your patch yet.. but still we can fix it in follow-up patch at this point Apr 05 17:21:53 That'll be a surprise; I'm curious to see the result Apr 05 17:22:35 oh and we still need to fix this qemu usb touch thing, isn't it Apr 05 17:23:30 | patching file android-gadget-setup Apr 05 17:23:30 | Reversed (or previously applied) patch detected! Apr 05 17:23:56 it's related to nizovn's last PR in oe-core, isn't it Apr 05 17:24:44 maybe I just sync'ed my trees at the bad moment :p Apr 05 17:25:10 webos-ports-setup should be ready now Apr 05 17:25:41 yes, qemu usb touch thing is next on my TODO Apr 05 17:26:11 I'll help there. qemu is a big thing for wanabee users Apr 05 17:26:12 I don't think his PR for meta-oe was merged already Apr 05 17:26:36 I would like to spend some time on luneui-example image as well Apr 05 17:26:55 because rebuilding qtwebengine is pain Apr 05 17:27:01 does luneui-example spare the qtwebengine build ? Apr 05 17:27:06 ah ok good Apr 05 17:27:29 yes Apr 05 17:27:52 eventually it might need it as well, but now I want to keep it webengine-less Apr 05 17:28:09 so, my next target will be qemux86-64 with qt 5.12, that way I'll fix my patch along the way Apr 05 17:28:18 as qtwebengine almost doubles the image build Apr 05 17:28:48 qemux86-64 seems in similar shape as qemux86 now Apr 05 17:29:28 once we get the touch working (the same should fix both) I would like to compare performance with qemu-native on virglrenderer (all changes already in oe-core/warrior) Apr 05 17:29:41 so, what should I pick in webos-ports-setup for my build ? unstable ? master ? Apr 05 17:30:13 unstable and master are identical (except the branch name set in Makefile) Apr 05 17:30:30 I'll take unstable then, the name is more familiar to me Apr 05 17:30:50 I prefer to use the branch with Yocto release, so now using luneos-warrior directory with warrior branch and luneos-master with master Apr 05 17:31:30 the testing/unstable names are good as "rolling" release and for jenkins, so we have only 3 jenkins builds and they always get the right "release" Apr 05 17:31:56 so I'm rebasing stable/testing/unstable branches in webos-ports-setup on whatever branch is currently selected for them Apr 05 17:32:21 yes, it's also convenient for the devs to not get lost in the various yocto release names :p Apr 05 17:32:45 except that then then won't know which release they will get with "make update" :) Apr 05 17:33:04 hehe right :) Apr 05 17:33:08 but that's probably more important to me, than it should be for regular dev Apr 05 17:33:34 artifacts lge lost+found luneos-master luneos-pyro luneos-rocko luneos-sumo luneos-thud luneos-warrior oe-core shr-core standalone yoe-distro Apr 05 17:33:36 not that we are that many here, but hey, maybe one day.... Apr 05 17:34:00 I'm looking forward to delete 4 of these dirs soon :) Apr 05 17:34:47 not sure if I said it already, but unstable webos-ports-setup should be ready now Apr 05 17:36:00 I think you hinted it yes Apr 05 17:36:22 I've checked it out, now I'm starting the build Apr 05 17:36:32 good, if it fails, it will fail quickly Apr 05 17:38:30 ah, I almost forgot llvm. That one is also a pain. Apr 05 17:39:34 yeah, but only for qemux86* right? Apr 05 17:41:26 and mainline Apr 05 17:49:22 Tofe: do you know who to ping for https://github.com/libhybris/libhybris/pull/417 ? Apr 05 17:50:13 JaMa: bshah, mal, sledges Apr 05 17:50:46 but my patches may not be welcome, I don't know their point of view on this Apr 05 18:03:44 oops "ERROR: Problem encountered: nss-resolve is requested but resolve is disabled" Apr 05 18:10:49 JaMa: I PR this ^ ? Apr 05 18:11:26 yes please Apr 05 18:12:11 https://github.com/webOS-ports/meta-webos-ports/pull/330 Apr 05 18:12:54 I confirm systemd builds with this Apr 05 18:14:07 will cherry-pick to warrior as well Apr 05 18:15:22 thanks Apr 05 20:05:15 JaMa: there's a mistake in the bbappend for qtwebengine, there's a missing "patchdir=src/3rdparty" for the chromium patch Apr 05 20:06:50 https://github.com/webOS-ports/meta-webos-ports/commit/350a95548061aa1781fee661a88cd08fdb675c19 Apr 05 20:07:09 damn Apr 05 20:07:19 at least it failed quickly, right? :) Apr 05 20:07:23 fixing it now Apr 05 20:07:24 right Apr 05 20:08:17 I'm sorry about that, I remember even thinking about it that I shouldn't forget to copy paste it.. Apr 05 20:08:52 don't bother apologizing, it probably doesn't compile anyway :D Apr 05 20:09:13 if it doesn't then we'll be even :) Apr 05 20:09:20 ok ;) Apr 05 20:10:14 but I'm really happy about the Yocto, Qt upgrades Apr 05 20:10:24 I'm already deleting the old workdirs Apr 05 20:10:45 :) Apr 05 20:11:34 dev/sde2 2.6T 1.5T 1023G 60% /OE/build Apr 05 20:11:37 I'm glad too, once the last issues are solved we can focus more on the content Apr 05 20:11:42 it should save about 1TB of space :) Apr 05 20:11:52 that's great :p Apr 05 20:12:39 yes and for me it will be easier to try new things I get excited about in new Yocto Apr 05 20:13:16 instead of trying them in much newer Yocto which doesn't work well on LuneOS supported devices, or spending time backporting them to very old Yocto just to try them :) Apr 05 20:16:46 yes it'll be much more convenient now Apr 05 22:27:12 My average download speed of the binutils-gdb git repo can't be much more than 100 KB/s. Apr 05 22:28:10 It's excruciating! *This* is why I keep a few such source packages on a local mirror these days. Apr 05 22:29:14 (Having to renew them because we seem to be updating Yocto about once a week lately :-) ) Apr 05 22:30:57 elvispre: good news is that we run out of Yocto release to upgrade to for at least half a year :) Apr 05 22:31:24 \o/ Apr 05 22:31:30 elvispre: try fetching binutils-gdb from our jenkins, might be faster for you than git clone Apr 05 22:32:20 http://sources.webos-ports.org/git2_sourceware.org.git.binutils-gdb.git.tar.gz Apr 05 22:33:12 Is that a local mirror on the jenkins machine? Apr 05 22:35:05 yes, it's configured as premirror by webos-ports-setup so you should get it from there automatically Apr 06 01:20:01 morning? **** ENDING LOGGING AT Sat Apr 06 02:59:57 2019