**** BEGIN LOGGING AT Tue Apr 02 02:59:57 2019 Apr 02 05:53:50 Morning! Apr 02 05:54:39 JaMa: only the diffs, I hacked tmp-work directly Apr 02 05:55:17 but I'll prepare PRs for tonight Apr 02 11:03:45 Morning! Apr 02 11:03:53 novaldex: ping Apr 02 11:16:15 morning Apr 02 11:47:41 * JaMa imported 20 virtualbox appliances to see where we stand with warrior and 64bit anbox Apr 02 11:48:44 in case anyone else hits the same, vbox VM name is restricted to 63 chars (otherwise VERR_CFGM_NOT_ENOUGH_SPACE error is shown when you try to start it - unfortunately not when you try to create or import VM with such long name) Apr 02 11:49:11 and slash in name is acceptable for import, but then it fails with VERR_FILE_NOT_FOUND if you try to modify some settings Apr 02 11:49:32 Good to know! Apr 02 11:57:21 only storaged.service is failing with warrior now Apr 02 11:57:22 2019-04-02T11:56:43.440263Z [46] user.err storaged [] NYX_OPEN_ERR {} module (nyxMassStorageModeMain.module) does not exist in /usr/lib/nyx/modules nor in /usr/lib/nyx/modules.mock Apr 02 11:57:43 there are only 4 nyx-modules available: Apr 02 11:57:44 /usr/lib/nyx/modules/nyxDisplayMain.module Apr 02 11:57:44 /usr/lib/nyx/modules/nyxOSInfoMain.module Apr 02 11:57:44 /usr/lib/nyx/modules/nyxDeviceInfoMain.module Apr 02 11:57:44 /usr/lib/nyx/modules/nyxSystemMain.module Apr 02 11:57:54 I've removed only security and security2 (due to openssl) Apr 02 12:02:57 with qt 5.12 it's a bit worse, shows just black screen after LuneOS logo (on first boot as well as after luna-next.service restart) Apr 02 12:04:11 luna-next log https://paste.ubuntu.com/p/29Z2DhM28r/ Apr 02 12:05:20 the same on qemux86-64 Apr 02 12:06:30 the luneui-examples images are useless, don't seem to boot at all, but it might be debug-tweaks recently removed from my local.conf, which prevents it from showing output during boot and doesn't enable sshd Apr 02 12:12:34 anbox doesn't work in runtime, fails to initialize SDL, but I think that including it for qemux86-64 doesn't hurt at this point (at least to notice if we break the build with it on jenkins) Apr 02 12:12:44 now going to test tissot/hammerhead builds Apr 02 12:13:17 ah and in all these builds I never got the firstuse for some reason (sumo, thud, warrior, master from jenkins as well as local builds) Apr 02 12:14:03 JaMa: I really have to PR the little nodejs fixes then, I think it'll help Apr 02 12:14:41 also, for Qt 5.12, keep in mind that our WebAppManager is running without any PalmService, which surely doesn't help Apr 02 12:14:51 but those should affect only warrior, not sudo and thud, right? Apr 02 12:15:21 only the levels where it was disabled yes Apr 02 12:15:28 so only warrior Apr 02 12:15:43 I didn't catch that you were running sumo Apr 02 12:15:47 Tofe: I'm aware of that issue with 5.12, I was just expecting some clearer error in log :) Apr 02 12:16:24 I was testing all releases to find out if warrior is any better or significantly worse :) Apr 02 12:16:58 now doing the same on hammerhead/tissot to also verify the glibc fix and test with latest libhybris from that meta-smartphone PR Apr 02 12:17:00 "libLuneOSBluetooth.so: undefined symbol: _ZN7BluezQt5Agent16staticMetaObjectE" <-- this is the original cause for the back screen Apr 02 12:17:06 black* Apr 02 12:17:41 so... bluezqt5 issue ? did you tinker with the build ? Apr 02 12:18:25 I always tinker with the build :) but this isn't expected outcome :) Apr 02 12:19:18 do you know what component provides libLuneOSBluetooth.so? for some reason I don't see it anywhere in sstate-control Apr 02 12:19:35 it's from luneos-components iirc Apr 02 12:20:24 ok see it in luneos-components through buildhistory Apr 02 12:21:10 maybe it's not included in the sysroot because of qml subdirectory Apr 02 12:21:53 what would not be included ? Apr 02 12:24:46 I thought that meta/classes/staging.bbclass is quite picky about what to stage from libdir, but looking at the bbclass I don't see where it was Apr 02 12:24:52 maybe it was only for datadir Apr 02 12:26:07 https://github.com/webOS-ports/meta-webos-ports/blob/master/meta-luneos/recipes-connectivity/bluez5/kf5bluezqt-mer.bb could be a culprit, I guess Apr 02 12:26:39 if it doesn't install the plugin in the correct subfolder for example Apr 02 12:29:25 https://paste.ubuntu.com/p/rZCDZXdcHn/ Apr 02 12:29:59 it's also worth noting that this build with master (unlike thud) has dev-pkgs and dbg-pgks added to the image and enabled DEBUG_BUILD Apr 02 12:30:00 and where is luneos-components ? Apr 02 12:30:44 https://paste.ubuntu.com/p/pF3qcPyjkC/ Apr 02 12:31:25 before spending too much time on this issue I should do the 5.12 build on warrior (without DEBUG_BUILD enabled) Apr 02 12:31:41 lets see if the same issue exists on tissot as well Apr 02 12:32:06 now it was the same on qemux86(-64), so it wasn't random one-of issue from my local tinkering Apr 02 12:34:35 btw swap fails on tissot with sumo Apr 02 12:34:36 Mar 26 20:04:54 tissot systemd[1]: Activating swap /SWAP.img... Apr 02 12:34:36 Mar 26 20:04:54 tissot swapon[880]: /sbin/swapon: invalid option -- 'o' Apr 02 12:34:36 Mar 26 20:04:54 tissot swapon[880]: BusyBox v1.27.2 (2019-03-29 02:47:00 UTC) multi-call binary. Apr 02 12:34:39 Mar 26 20:04:54 tissot swapon[880]: Usage: swapon [-a] [-e] [-d[POL]] [-p PRI] [DEVICE] Apr 02 12:35:22 oh. I wonder where this option is set. Apr 02 12:37:09 and the nyxMassStorageModeMain.module is missing in qemux86 already in sumo Apr 02 12:40:31 ah, we forgot it in the cmake file? Apr 02 12:43:49 not really, it looks kind of good Apr 02 12:44:40 what looks good? Apr 02 12:45:00 luneui-example image doesn't boot on tissot it seems (like on qemux86) something for me to check later Apr 02 12:45:20 drops number of testable images from 14 to half at least :) Apr 02 12:45:31 the qemux86.cmake for nyx-modules Apr 02 12:46:13 you're on sumo+qt 5.12, right? or something else? Apr 02 13:08:57 Well I think we still need to tweak some things for Nyx for OSE? I remember they went down a bit different path v.s. us Apr 02 13:11:44 Tofe: this is warrior+qt 5.12, but the same storaged issue exists in sumo Apr 02 13:11:48 so maybe in pyro as well Apr 02 13:13:53 src/msm_mtp/CMakeLists.txt:webos_build_nyx_module(MassStorageModeMain Apr 02 13:13:54 if we had the same storaged issue in sumo, where we had a pretty good status, then it's not an urgent issue for warrior, moreso if the UI doesn't start :) Apr 02 13:14:02 maybe it just isn't enabled in qemux86 config Apr 02 13:14:26 yes, this was just the only systemd service failing right now Apr 02 13:14:48 before there were couple more like sleepd, because I had remove all the nyx-modules before (due to openssl) Apr 02 13:14:55 https://github.com/webOS-ports/nyx-modules/blob/tofe/webosose/CMakeLists.txt#L35 <-- MSMMTP is enabled here by default Apr 02 13:15:17 https://github.com/webOS-ports/meta-webos-ports/commit/2bd58eaaffb5dd8b50a49d1f827a9f6732583be4 Apr 02 13:15:31 but it isn't in NYX_MODULES_REQUIRED IIRC Apr 02 13:15:46 ah, mmh Apr 02 13:16:12 we would need to add NYXMOD_OW_MSMMTP Apr 02 13:16:25 right Apr 02 13:17:51 maybe we should enable few more in meta-luneos/classes/webos_nyx_module_provider.bbclass Apr 02 13:18:23 like do we need touchpanel(_mtdev) somewhere? Apr 02 13:18:43 touchpanel_mtdev yes, in almost all devices Apr 02 13:19:08 not a big role (just backlight timeout), but still Apr 02 13:19:13 all of these are probably missing if I remember how NYX_MODULES_REQUIRED worked correctly Apr 02 13:19:36 we are probably saved by our cmake overrides Apr 02 13:20:09 ah, should check why the override didn't work for msmmtp then Apr 02 13:20:18 https://github.com/webOS-ports/meta-webos-ports/blob/master/meta-luneos/recipes-webos/nyx-modules/nyx-modules/hammerhead.cmake#L22 like here Apr 02 13:20:39 we don't setup msmmtp Apr 02 13:27:38 https://github.com/webOS-ports/meta-webos-ports/commit/d0f1f0cf82fe29050cc8245360fb4ace1e060595 Apr 02 13:29:21 thanks Apr 02 13:32:25 JaMa/Tofe: I think at some point we might want to have a look at upgrading Maliit as well Apr 02 13:33:53 They switched from QMake to CMake a while ago and applied quite some bits & pieces that might solve some of our VKB issues as well Apr 02 13:35:16 I.e. https://github.com/maliit/framework/commits/master and https://github.com/maliit/plugins/commits/master Apr 02 13:37:57 on tissot/sumo: https://paste.ubuntu.com/p/8fkhZXgf9W/ Apr 02 13:39:01 but surprisingly this time swap didn't fail (unlike my local sumo build) Apr 02 13:40:53 ah, because there is no swap Apr 02 13:44:22 I should find out why busybox/tar always gets killed on my tissot, it's happening every single time Apr 02 13:44:39 makes the sideload about 2 times slower Apr 02 13:49:26 my local thud build https://paste.ubuntu.com/p/BPc8mYq8w6/ need to find out what enables swap in fstab Apr 02 13:51:33 also we'll definitely need to disable all these automatic /run/media mounts Apr 02 13:53:08 in case of hard reboot, it can be harmful Apr 02 13:54:01 and the swap works if I use defaults in fstab and actually create the /SWAP.img on the device Apr 02 13:59:34 meta-luneos/classes/luneos_image.bbclass: echo "/SWAP.img none swap sw 0 0" >> ${IMAGE_ROOTFS}/etc/fstab Apr 02 14:00:13 it's always done except when WEBOS_MACHINE_NO_SWAP_PARTITION is set Apr 02 14:01:26 testing with luneos-unstable-thud/luneos-dev-package-tissot--unstable-0-49.zip now Apr 02 14:03:23 for automount, it seems it comes from udev-extraconf, with automount.rules. Not sure how to override that... Apr 02 14:04:48 maybe just an empty "automount.rules" file in our bbappend Apr 02 14:04:57 ah recipes-core/initrdscripts/initramfs-boot-android/init.sh is supposed to create it Apr 02 14:05:31 https://github.com/webOS-ports/meta-webos-ports/commit/0d04360415233041fddc010e0f93c73025825bde Apr 02 14:10:12 SWAP.img isn't in thud build from jenkins https://paste.ubuntu.com/p/3StbMMZqT8/ Apr 02 14:10:17 in fstab Apr 02 14:11:37 testing luneos-unstable-warrior/luneos-dev-package-tissot--unstable-0-51.zip Apr 02 14:15:20 https://paste.ubuntu.com/p/B9r4GG7fMX/ Apr 02 14:17:22 so if we disable automount and fix storaged, we're all green? Apr 02 14:24:53 /SWAP.img creating was removed from init.sh in your "initramfs-boot-android: use Halium's init script" maybe we should dropit from the meta-luneos/classes/luneos_image.bbclass now? Apr 02 14:26:12 for me (and my really quick basic testing) the warrior seems to work best Apr 02 14:27:10 JaMa: that's a grey area for me: is swap useful on our devices ? Apr 02 14:28:52 I haven't tried master + 5.12 + new libhybris yet, because dbg-pkg included in my local build makes the image too big for sideload Apr 02 14:29:08 sideload-host file size -1583068846 block size 65536 Apr 02 14:29:08 file has too many blocks (4294943141) Apr 02 14:30:46 Tofe: I think tissot has enough ram to handle itself on hammerhead it might be different story Apr 02 14:31:17 so it needs to be a bit flexible for low-end devices Apr 02 14:31:32 after the boot tissot uses around 1/10 of ram Apr 02 14:32:05 tissot has 3GB ? Apr 02 14:32:38 3,5GB it seems Apr 02 14:32:41 3660536 Apr 02 14:32:58 now trying similar images on hammerhead Apr 02 14:33:10 anyway, if we want it to be flexible, it's either a machine variable or a bbappend. So, not in the bbclass, I guess. Apr 02 14:34:48 it worked so far with my Halium init script and without swap; let's keep it that way and maybe improve a bit on arm32 Apr 02 14:41:39 MACHINEs can use the WEBOS_MACHINE_NO_SWAP_PARTITION variable to disable it Apr 02 14:42:02 but we might use variable with better name for that as this double negative is a bit confusing Apr 02 14:43:42 there is also the option for swap in the userdata partition I've noticed in the init Apr 02 14:44:17 from Halium ? Apr 02 14:44:34 with rfs mounted during init it might be easiest to just check whether fstab has the /SWAP.img entry Apr 02 14:45:00 and generate it only when it does, then the bbclass with WEBOS_MACHINE_NO_SWAP_PARTITION variable is the only place where the behavior is selected Apr 02 14:46:25 we could also use systemd-swap itself, if it's not already the case Apr 02 14:47:21 - # Setup the swap device Apr 02 14:47:21 - [ -e ${rootmnt}/android/userdata/SWAP.img ] && swapon ${rootmnt}/android/userdata/SWAP.img Apr 02 14:47:25 but your solution if more simple I guess. And yes, we should invert the variable logic Apr 02 14:47:29 is* Apr 02 14:47:42 this was in meta-luneos/recipes-core/initrdscripts/initramfs-boot-android/halium-boot.sh Apr 02 14:48:33 still is in https://github.com/Halium/initramfs-tools-halium/blob/halium/scripts/halium#L618 Apr 02 14:49:29 in what branch do we ship halium-boot.sh itself ? Apr 02 14:50:55 currently I don't think we do from meta-webos-ports Apr 02 14:51:08 ah ok, I misunderstood; that's good Apr 02 14:51:10 I've noticed this only when searching for SWAP.img where it was created before Apr 02 14:51:56 local hammerhead/sumo build doesn't look so good (no UI) https://paste.ubuntu.com/p/YrJ4txqj4f/ Apr 02 14:51:59 I don't like having it in Halium, actually: when will we create the swap file ?... it can't be created before Halium finds and mounts the rootfs... Apr 02 14:53:07 sumo ? oh. Apr 02 14:53:21 ah but qt 5.12 Apr 02 14:53:27 still... Apr 02 14:53:28 agreed that halium init isn't best place for us Apr 02 14:53:32 no 5.11 in sumo Apr 02 14:53:49 ah, that's bad Apr 02 14:53:51 I have 5.12 only in master build (which is warrior + DEBUG_BUILD + dbg-pkg + qt 5.12) Apr 02 14:54:09 might be better with sumo from jenkins, flashing it now Apr 02 14:54:40 but if db8 failed, it might be that a whole lot went wrong Apr 02 14:55:04 yes and it was using a lot less memory :) Apr 02 14:55:12 hehe :) Apr 02 14:56:50 my local sumo (and probably thud) builds were missing the last uevent_helper IIRC, so the warrior build is the one most relevant Apr 02 15:02:11 sumo from jenkins is a bit better, but still no UI: https://paste.ubuntu.com/p/PMgPCNBnKk/ Apr 02 15:11:33 right Apr 02 15:12:47 I can give it a try, if you upload that somewhere Apr 02 15:15:17 use whatever is on jenkins, my local builds aren't important Apr 02 15:15:54 just tried local thud build and it doesn't even boot, well.. Apr 02 15:16:31 now on luneos-unstable-thud/luneos-dev-package-hammerhead--unstable-0-69.zip Apr 02 15:32:49 warrior works the best on my hammerhead again https://paste.ubuntu.com/p/b5XGzWFfN4/ first build with working UI Apr 02 15:34:57 the biggest mystery for me right now is how jenkins builds end without SWAP.img in /etc/fstab (unlike my local builds) even in bitbake -e executed in jenkins workspace I get expected: Apr 02 15:35:01 ROOTFS_POSTPROCESS_COMMAND() { Apr 02 15:35:03 write_package_manifest; license_create_manifest; rootfs_set_image_name ; clean_python_installation ; verify_acg ; ssh_allow_empty_password; ssh_allow_root_login; postinst_enable_logging; rootfs_update_timestamp ; write_image_test_data ; set_systemd_default_target; systemd_create_users; empty_var_volatile; webos_swap_hook; webos_enable_devmode; sort_passwd; rootfs_reproducible; Apr 02 15:35:09 } Apr 02 15:35:16 and Apr 02 15:35:18 webos_swap_hook() { Apr 02 15:35:18 if [ "1" == "1" ] ; then Apr 02 15:35:18 echo "/SWAP.img none swap sw 0 0" >> /home/jenkins/workspace/luneos-unstable/webos-ports/tmp-glibc/work/tissot-webos-linux/luneos-dev-image/1.0-r0/rootfs/etc/fstab Apr 02 15:35:21 fi Apr 02 15:35:24 } Apr 02 15:48:26 local warrior build looks reasonable as well (UI works), just the /SWAP.img is there again: https://paste.ubuntu.com/p/8HRm7b56Jr/ Apr 02 15:51:15 now the known to be broken luneos-warrior/luneui-example-package-hammerhead--1.0.2+gitAUTOINC+481644a737-r0-20190329150528.broken-glibc.zip confirmed that it's indeed broken, trying to get some logs confirming init was killed Apr 02 16:03:46 local build from master doesn't look too bad on hammerhead https://paste.ubuntu.com/p/zZy3FGKv54/ the same issue with bluetooth as on qemux86, the fix for storaged worked and new libhybris didn't make it significantly worse (firstuse was usable) Apr 02 16:12:34 similar on tissot: https://paste.ubuntu.com/p/XkDjMgzpKH/ Apr 02 16:14:19 Tofe: Herrie: should I go ahead and merge anbox+unused PRs and nyx-modules fix and switch testing to warrior? or do we wait for more testing on other devices? With nodejs-* fix from Tofe it won't be any worse than current testingsumo (or a lot better at least on my devices) Apr 02 16:14:51 the libhybris bump from meta-smartphone seems harmless as well, but that can wait until upstream merges the PR there Apr 02 16:15:40 I'll prepare some changes which will be needed for next oe-core/thud bump which includes http://git.openembedded.org/openembedded-core/commit/?h=warrior&id=13e45fffb66c7cb7ba0d07bed063c0c5ce57004b Apr 02 16:16:15 and I'll try to debug a bit more why /SWAP.img gets added to fstab (only in my local builds), confirmation from some other local builds would be welcome Apr 02 16:16:45 actually i can just drop it from the .bbclass now until it's resolved differently, because it won't work without init.sh changes Apr 02 16:17:34 + the automount disable is high on the priority list Apr 02 16:40:45 back Apr 02 16:54:32 https://github.com/webOS-ports/meta-webos-ports/pull/326 (depends on https://github.com/webOS-ports/nodejs-module-webos-sysbus/pull/2 and https://github.com/webOS-ports/nodejs-module-webos-dynaload/pull/2 ) Apr 02 16:56:06 if someone uses rebase & merge on those 2 it will break your SRCREVs, right? Apr 02 16:56:15 right Apr 02 16:56:23 I hoped it wouldn't come to that :p Apr 02 16:56:41 better me not doing that than :) Apr 02 16:57:22 because I usually do it even when using github UI (because I don't like those merge commits especially when they are for just one commit in fast-forward history) Apr 02 16:57:43 well, if you do it through a rebase, I'll just update my PR, no worries Apr 02 16:58:01 Herrie isn't in the vicinity, so better be done with this Apr 02 16:58:14 you can merge all 3 Apr 02 16:58:19 can I Apr 02 16:58:21 or you don't have perms to do that? Apr 02 16:58:46 I don't, it's one of those rare remaining repos Apr 02 16:58:57 ah, ok let me do that now Apr 02 16:59:08 do you want merge commits or rather update PR? Apr 02 16:59:32 I don't really mind either way :) Apr 02 16:59:37 at least for these repos Apr 02 16:59:52 I'll update PR, it's a bit cleaner Apr 02 17:00:26 ok, done Apr 02 17:02:22 PR updated Apr 02 17:05:50 and the nyx-modules fix: Apr 02 17:05:51 924d4b640..367ce192a master -> master Apr 02 17:05:51 004765882..32e643280 warrior -> warrior Apr 02 17:07:55 good Apr 02 17:08:05 automount disabling is on its way... Apr 02 17:08:40 perfect Apr 02 17:09:13 https://github.com/shr-distribution/meta-smartphone/pull/98/files this should be enough, right ? the recipe should be that one instead Apr 02 17:09:16 we could skip storaged for x86 btw Apr 02 17:09:19 /be/pick/ Apr 02 17:10:33 Also I hesitated where to put this disabling (meta-smartphone or meta-webos-ports), but the former seems to fit as well Apr 02 17:10:54 looks reasonable to me as well Apr 02 17:12:35 JaMa: I'll update my local tissot warrior build when you'll have merge this and we are in a good state for a test Apr 02 17:13:36 If we reach a good functional level on warrior, it should be ok for testing Apr 02 17:13:52 SWAP.img fstab entry dropped in: 367ce192a..2b49a4cd4 master -> master Apr 02 17:13:53 32e643280..8e1edf3a6 warrior -> warrior Apr 02 17:13:57 JaMa: Sorry got disconnected Apr 02 17:14:03 Go ahead please Apr 02 17:14:22 ok, doing the unused and anbox PR now Apr 02 17:14:30 yay Apr 02 17:16:10 all merged now :) Apr 02 17:16:21 ok, I'll update & build Apr 02 17:17:30 even meta-smartphone ? Apr 02 17:17:42 ah nope on meta-smartphone Apr 02 17:17:47 in call now, lets see Apr 02 17:18:00 I have it locally anyway Apr 02 17:18:06 take your time Apr 02 17:18:58 Herrie|Phone: that'll be quite a release, in the end ! Apr 02 17:19:19 Tofe: Yeah! Apr 02 17:19:31 I need to get my builder fixed Apr 02 17:19:43 hehe :) Apr 02 17:20:04 I guess I'll have some time soon to get a liveUSB created Apr 02 17:20:21 Seems something got corrupt in terms of selinux Apr 02 17:20:35 Unable to get context for user... Apr 02 17:20:46 missing ACL of some sort? Apr 02 17:20:53 Not sure Apr 02 17:21:06 Can login but that's about it Apr 02 17:21:15 Cannot ssh in, no UI Apr 02 17:21:23 No wifi Apr 02 17:21:28 ok, you're quite blind there... Apr 02 17:21:39 So guess something got broken Apr 02 17:22:09 the good news is, if it's broken that much, it's probably obvious in the logs Apr 02 17:22:13 Maybe one of the kids was playing wirh buttons too much Apr 02 17:22:40 Need to simply disconnect them from front panel :P Apr 02 17:22:48 A Raid isn't child-proof, it seems :) Apr 02 17:23:13 Well it's my non-RAID SSD ;) Apr 02 17:23:21 smartphone done as well Apr 02 17:23:26 great Apr 02 17:23:32 my build is already on the way Apr 02 17:23:42 RAID is for storage. SSD for OS and build. Apr 02 17:23:53 makes sense Apr 02 17:24:09 Mrs and little ones gone, horrible weather outside so time to get this LiveUSB ready Apr 02 17:24:34 the garden is now 50cm underwater... :p Apr 02 17:25:22 oh, no, qtwebengine wants a rebuild :( Apr 02 17:30:24 Well let's have a look Apr 02 17:30:44 Tofe: Well I'm not in the low part of NL now ;) Apr 02 17:32:55 Seems I'm somewhere between 10 and 15m above sea level ;) Apr 02 17:35:00 :) Apr 02 17:36:24 But the garden is big, so lots of work LOL ;) Apr 02 17:36:34 But getting there..... Need to put 35m of fence this week ;) Apr 02 17:36:48 But first need to put all cabling and lights, equalize the ground a bit etc Apr 02 17:40:09 So where are we aiming in terms of release now? Still Sumo or Thud or even Warrior? Apr 02 17:44:37 We're heading for Warrior Apr 02 17:45:28 With Qt 5.11 Apr 02 17:46:50 OK good :) Apr 02 17:47:12 Then we should be OK for a while and can focus on adding features and fixing things instead of fighting with Yocto ;) Apr 02 17:47:45 yes, I hope so as well Apr 02 17:50:28 Some boot bits repaired, however still not booting it seems Apr 02 17:50:33 I guess I'll let it run for a bit Apr 02 17:50:35 Maybe it' Apr 02 17:50:42 s doing some disk checks & fixes Apr 02 17:51:03 Stuck @ Kubuntu pulsing logo for now Apr 02 17:51:23 well it's a bit better :) Apr 02 17:52:16 Still not really much chance to get in... Apr 02 18:16:16 Tofe: we should do the 5.12 relatively soon after warrior upgrade to allign the branches to have warrior everywhere :) Apr 02 18:16:32 and I'll need to work on 5.12 for lge anyway, so that's a bonus :) Apr 02 18:25:13 my build is also running, but will take a while it's almost from scratch due to latest oe-core/warrior changes Apr 02 18:26:07 Tofe: do you want to pick newer oe-core as well for you qtwebengine rebuild (or rather just qtwebengine without everything else as well) Apr 02 18:28:09 JaMa: you mean 5.12 ? doesn't matter for me Apr 02 18:28:29 for 5.11 it's already at 91% Apr 02 18:41:42 I meant oe-core/warrior changes, not 5.12 yet, but that can wait for another rebuild Apr 02 18:47:27 this one https://github.com/webOS-ports/webos-ports-setup/commit/01be1ef207e4243586c9a7628ff6e90eb1c202f2 Apr 02 19:10:19 ah ok Apr 02 19:10:49 well, as you wish; my build is almost ready now, so I won't update it unless necessary :) Apr 02 19:11:01 there may be some interesting llvm fixes Apr 02 19:12:46 just keep it in mind when you're starting another _long_ build Apr 02 19:13:47 I've intentionally kept the very latest oe-core/warrior commit from this webos-ports-setup update, because the will need few pending changes for meta-qt5, meta-raspberrypi, meta-oe, meta-rpi-luneos, meta-webos-ports layer to aling with warrior compatibility :) Apr 02 19:14:30 ok Apr 02 19:15:51 and jenkins builds includes this already Apr 02 19:16:53 "systemctl --all | grep failed" --> empty ! Apr 02 19:18:53 wifi isn't working well :/ Apr 02 19:19:02 hoho Apr 02 19:19:34 "Error wifi: Method "GetProperties" with signature "" on interface "net.connman.Service" doesn't exist" Apr 02 19:19:40 when in connmanctl Apr 02 19:20:30 ah, sorry, it's me Apr 02 19:20:38 I can get the wifi list from connmanctl Apr 02 19:20:48 is it new with warrior or just latest warrior? Apr 02 19:20:51 ah Apr 02 19:20:52 so it's probably a middleware issue Apr 02 19:21:44 " Error: Cannot find module 'webos' " meh ? Apr 02 19:21:50 don't we include it, now? Apr 02 19:22:44 looks like we forgot to re-add it to RDEPENDS :p Apr 02 19:22:51 hmm no, you bumped the SRCREV, but didn't revert my change yet Apr 02 19:22:54 yup Apr 02 19:23:01 should I? Apr 02 19:23:11 if you please Apr 02 19:24:29 done Apr 02 19:26:00 also, sound is dead Apr 02 19:26:10 though noone seems to complain Apr 02 19:34:15 mmmh doesn't help with wifi :/ Apr 02 19:34:49 though it seems quite specific to the firstuse app Apr 02 19:35:26 I can connect through preferences Apr 02 19:38:23 backlight has seen better days too Apr 02 19:39:26 tsss... systemd-logind.... I'm sure it takes control Apr 02 19:41:10 we probably want to get rid of it... don't we? Apr 02 19:41:42 bluetooth seems to work Apr 02 19:41:54 rotation sensors is ok Apr 02 19:43:10 yup, it's the culprit, it acts when the power button is pressed Apr 02 19:48:44 Also, good news: I think I've understood how the mojo migration of qtwebchannel works Apr 02 19:55:19 nice! Apr 02 20:07:25 for logind, I'm not yet sure if we should mask it, or just tweak the configuration to disable poweroff Apr 02 20:10:03 I'd say mask. We don't need another daemon doing the same job as our webos ones... Apr 02 20:10:22 JaMa: do you know how we mask a systemd service ?... Apr 02 20:11:29 or just rule it out completely... maybe it's in luneos.conf or something like that, via a variable Apr 02 20:12:20 * Tofe is tired and going to sleep :) Apr 02 20:17:26 before we were creating symlinks to /dev/null IIRC (mostly to mask generating sysv init scripts as a service) but that might not be applicable for real systemd services nor clean solution Apr 02 20:17:58 if it's using the systemd.bbclass mechanism than there was something like SYSTEMD_AUTOENABLE, let me check Apr 02 20:18:26 meta/recipes-connectivity/dhcp/dhcp.inc:SYSTEMD_AUTO_ENABLE_${PN}-server = "disable" Apr 02 20:19:08 if you want to disable logind completely, then we can use systemd PACKAGECONFIG to remove: meta/recipes-core/systemd/systemd_241.bb:PACKAGECONFIG[logind] = "-Dlogind=true,-Dlogind=false" Apr 02 20:20:13 logind.conf is handled by meta/recipes-core/systemd/systemd-conf_241.bb Apr 02 20:20:59 I'll think about it; first I probably should read more about loging and what's it's supposed to handle. For instance it might make sense for ssh connections and so on Apr 02 20:21:06 logind* Apr 02 20:21:09 so we can even make it MACHINE_ARCH without performance hit on build time Apr 02 20:21:27 yes, I know almost nothing about logind as well Apr 02 20:21:53 time to sleep a bit now :) gn8 ! Apr 02 20:21:55 sleep on it and we'll see tomorrow Apr 02 20:21:59 gn8 Apr 02 20:22:38 * JaMa will go off for now as well for a bit, bb **** ENDING LOGGING AT Wed Apr 03 02:59:57 2019