**** BEGIN LOGGING AT Thu Sep 28 03:00:03 2017 Sep 28 05:02:11 DougReeder: Thnx ;) Sep 28 05:02:20 I know that, but not in the market yet.... Sep 28 05:02:28 Seems my building machine had it's best time :'( Sep 28 05:30:58 Morning Sep 28 05:31:15 Herrie|Laptop: oh, that's sad; it isn't that old though Sep 28 05:49:43 Well 6/7 years Sep 28 05:49:47 Got it to boot now Sep 28 05:49:54 But seems it has random issues on booting Sep 28 05:50:02 Could be PSU not sure Sep 28 05:50:28 Did a CMOS clear now Sep 28 05:50:37 Maybe it was some bios setting Sep 28 06:08:51 maybe; an overheating doesn't improve the situation for sure Sep 28 07:57:05 Tofe: It gets quite hot on webengine compilation. About 65c but it should be able to stand at least 70 Sep 28 08:08:43 My previous CPU went up to 80 regularly :p Sep 28 08:10:55 I might want to tweak the fan speed a bit :P Sep 28 08:11:10 I checked the paste it was nice and evenly spread Sep 28 10:34:52 so I just packaged lemon. it's interesting that it needs a source file (lempar.c) in `/usr/bin` Sep 28 10:37:17 also, good news. I only had to patch 1 script in libpbnjson to get it to work without Bash Sep 28 10:53:22 so, cmake-modules-webos by default makes everything install to `/usr/local/webos`. however, this is not allowed in Alpine packaging standards (anything under `/usr/local` by the package manager is forbidden) Sep 28 10:53:49 so, I've patched cmake-modules-webos to install everything to `/usr/webos` instead. now this in itself works, but a package depending on a package that previously got installed to `/usr/local/webos` now fails to find it Sep 28 10:54:31 which lines do I have to change in which package to make it find it again? Sep 28 11:12:41 PureTryOut[m]: i'm a bit surprised by this path, it looks like the default fallback path; maybe it didn't detect something else ? Sep 28 11:13:33 no clue. so it isn't supposed to install to `/usr/local/webos` normally? Sep 28 11:15:03 not /usr/local, for sure Sep 28 11:15:26 our user apps are in /usr/palm/applications, for instance Sep 28 11:15:44 let me have a look at this cmake module Sep 28 11:20:12 thanks! Sep 28 11:21:47 PureTryOut[m]: Maybe it would be an idea to move to Yocto build system in future? It's quite flexible and tested in the field and used by large players like Intel, LG etc ;) Sep 28 11:21:50 you'll need env variables in your build env: https://github.com/openwebos/cmake-modules-webos/blob/master/webOS/webOS.cmake#L295 Sep 28 11:22:13 Learning curve might be a bit steep, but it's quite advanced in terms of offering etc :) Sep 28 11:24:19 Tofe: should I just set `WEBOS_INSTALL_ROOT` to `/usr` then? Sep 28 11:24:45 no wait Sep 28 11:24:49 just to `/` Sep 28 11:25:43 PureTryOut[m]: I'm trying to see where these are set in our toolchain Sep 28 11:27:08 Herrie|Pre3: I'm not sure why? I'm only interested in packaging Luna for Alpine, why would a different build system help me? Sep 28 11:27:55 PureTryOut[m]: or even empty should be ok; but it has to be defined, that's the trigger https://github.com/openwebos/cmake-modules-webos/blob/master/webOS/webOS.cmake#L195 Sep 28 11:28:20 ooh I see Sep 28 11:28:25 I'll just set it to `/` for now then Sep 28 11:28:25 PureTryOut[m]: the rest should follow, for most of it Sep 28 11:31:48 PureTryOut[m]: All depends on your requirements ;) If you're happy with what is there currently that's fine. There are things like meta-qt5 layers. Might save you work in long run. Not sure what Alpine offers ;) Sep 28 11:38:39 Herrie|Pre3: frankly I don't think the pros would cover all the efforts needed. Sep 28 12:22:28 Tofe: Really depends but might be very true Sep 28 13:23:32 Tofe: Experimenting a bit with voltages now since I have cold boot problems mainly it seems. So might be too low RAM voltage. Sep 28 13:57:34 Morning! Sep 28 14:01:32 Hi! Sep 28 14:01:38 I checked out latest qemux86 and qemux86-64 from last night: both do not allow hardware keyboard; qemux86-64 does not even offer touch/virtual keyboard. Sep 28 14:02:25 qemux86-64 is therefore not usable at all : stuck in "first use app" without keyboard Sep 28 14:04:04 previous qemux86 (478) works better and has both keyboards available in parallel. On 487 I did not find any new major issues. Sep 28 14:05:25 Ah, thanks, we must have done a mistake in the last testing release then Sep 28 14:12:12 qemux86-64 - when selecting the input field the virtual keyboard flashes up for 2 ms and hides again. It appears like a wrong default flag setting for the virtual keyboard display switch. Sep 28 14:18:30 yes, a focus issue, or a sudden crash Sep 28 14:35:40 MartinHov: This is weird, there were no real relevant changes in meta-webos-ports layer between 478 and 479 build for qemux86. Sep 28 14:36:10 It might have been from a change in meta-qt5, openembedded-core or meta-openembedded layers Sep 28 14:36:24 Situation on qemux86 didn't improve after a reboot? Sep 28 14:37:32 qemux86-64 is a known issue, but I haven't found anything in logs yet really. Just a lot of RIL and oFono errors which I'm addressing with https://github.com/webOS-ports/meta-webos-ports/pull/253 Sep 28 14:38:36 Tofe: Good news, cold boot issue seems gone for now and have a completed Hammerhead build finally with Halium Kernel + our GCC 5/6/7 and other patches. Soon flashing and moment of truth :-) Sep 28 14:45:08 Herrie|TP: oh, great! Sep 28 14:45:33 Likely it won't boot but who knows :-P Sep 28 14:59:17 Herrie|TP: Indeed - Situation on qemux86 *did* improve after a reboot. hardware keyboard works on build 479 after reboot. Sep 28 15:00:09 Tofe: I get UI, but wifi doesn't work it seems Sep 28 15:00:17 It turns on WiFi but doesn't find networks Sep 28 15:00:24 But it's already better then I expected :P Sep 28 15:03:13 Tofe: Full log: https://bpaste.net/show/f77e294ad204 Sep 28 15:08:20 Tofe: My initial hunch would be it's their connman vs ours Sep 28 15:08:29 We have OE connman, they have their own Sep 28 15:08:40 But based on nothing but gut feeling :P Sep 28 15:11:58 ok - 478 and 479 behave the same now: After reboot the HW KB works fine. first key stroke sets focus on "just type" input and virtual keyboard is displayed (fine!). Hitting Escape then brings back the "LuneOS desktop". Next key starts the Launcher again - but without any focus on the input field. So no virtual keyboard and no HW KB input is possible until the focus is manually set to the input field "Just Sep 28 15:11:58 type". Sep 28 15:23:39 Tofe: Seems it needs some tweaking here and there still :P Sep 28 15:23:46 But getting UI is already quite something I'd say Sep 28 15:24:34 TOfe: Rotation, sound works it seems Sep 28 15:25:21 😢 luna-service2 has a hard dep on systemd Sep 28 15:25:33 I can make it optional in CMakeLists.txt, but then it fails on compiling Sep 28 15:26:04 PureTryOut[m]: Open webOS was released with Upstart if I recall correctly and we migrated to systemd Sep 28 15:26:08 So it shouldn't be that hard Sep 28 15:27:18 I dislike harddeps on init systems... 😕 Sep 28 15:28:15 interestingly enough the commit that added the dep, only said "add support for systemd" Sep 28 15:28:24 https://github.com/webOS-ports/luna-service2/commit/fb6e272f0812557c46b41c34b0f91896000ef9b4 Sep 28 15:28:26 the title anyway Sep 28 15:28:38 yeah I can patch that out easily luckily Sep 28 15:29:21 ls2 is one of the most critical parts of the OS, so it needs to start early. Sep 28 15:29:55 It does all kinds of things for creating stuff at first boot with activitymanager & configurator Sep 28 15:34:42 Pretty much central hub in OS Sep 28 15:36:02 hmm Sep 28 15:36:19 I mean, OpenRC does have several runlevels, one of them being boot. so it can probably be put in there Sep 28 15:36:22 "Luna-service2 provides a bus-based IPC mechanism used between components in webOS. Luna-service2 is composed of a client library and a central hub daemon. The client library provides API support to register on the bus and communicate with other components. The hub provides a central clearinghouse for all communication. Utilities for monitoring and debugging the bus are included" Sep 28 15:36:25 I guess it requires a bit more than just removing the systemd parts then Sep 28 15:38:39 btw, is the following a good replacement? https://paste.pound-python.org/show/ldzGI4rMwDNlA9AcOuss/ Sep 28 15:38:52 it seems to work fine Sep 28 15:39:01 I can PR it if you guys want Sep 28 16:56:42 PureTryOut[m]: I think this won't work, diff works on files Sep 28 16:58:51 PureTryOut[m]: and for systemd dependency, we could eventually spawn a systemd-notify process to avoid the binary dependency Sep 28 17:00:38 PureTryOut[m]: but that won't work either for OpenRC; eventually if you have an idea about a cross-init solution we can take a patch Sep 28 17:02:34 Tofe: Our HCI SMD (BT) bits also don't work but that was expected with the Halium kernel since they have the backported 4.2 BT stack from Ubuntu Sep 28 17:04:57 Herrie: yes, quite expected Sep 28 17:05:26 though if BT doesn't work, I don't see the point of using this kernel :D Sep 28 17:05:49 but it's probably pretty easy to get it working Sep 28 17:05:59 Tofe: It probably works, but our hackidy hack script to bring it up doesnt; 0 Sep 28 17:06:00 ;) Sep 28 17:06:32 we should have a look at how ubports does it for N5 Sep 28 17:10:15 Yeah probably Sep 28 17:13:51 Tofe: Not sure I understand the ofono-conf.bb Sep 28 17:14:16 Herrie: where ? Sep 28 17:14:25 The PACKAGE_ARCH = "${MACHINE_ARCH}" takes care that it will take the device specific environment.conf if available? If not it will take the generic one? Sep 28 17:14:28 https://github.com/webOS-ports/meta-webos-ports/blob/14ecfd7a287ac43b764310911330c99f358e8646/meta-luneos/recipes-connectivity/ofono/ofono-conf.bb Sep 28 17:14:44 I made this PR: https://github.com/webOS-ports/meta-webos-ports/pull/253 Sep 28 17:14:58 To stop RIL and oFono from spamming log in Qemu targets Sep 28 17:15:04 Just not really sure how it works Sep 28 17:25:11 If I understand correctly, PACKAGE_ARCH = "${MACHINE_ARCH}" means there should be a package per machine arch, so not just "arm". Without this, I don't know which conf file it would take. Sep 28 17:27:31 the .conf file is used by systemd ( https://github.com/webOS-ports/meta-webos-ports/blob/14ecfd7a287ac43b764310911330c99f358e8646/meta-luneos/recipes-connectivity/ofono/ofono/ofono.service#L10 ) to set the environment for the process Sep 28 17:28:20 Therefore I think you PR looks good Sep 28 17:28:24 your* Sep 28 17:28:25 Tofe Sep 28 17:28:37 Tofe: Just my builder needs to do a whole rebuild again to test :P Sep 28 17:28:42 QTBase, webengine etc :S Sep 28 17:28:48 ooow Sep 28 17:29:01 Probably due to some other changes since previous build Sep 28 17:29:35 Probably yes Sep 28 19:22:09 DougReeder: ping Sep 28 20:11:49 bshah: https://github.com/Halium/android_kernel_lge_hammerhead/pull/1 Sep 28 20:11:52 There it is ;) Sep 28 20:49:19 Herrie: nice :) Sep 28 20:51:34 Tofe: How will your PR look? Sep 28 20:51:50 I checked legacy in general background should be white for textfields, unless there are multiple Sep 28 20:55:50 Tofe: Sent you some screenshots for reference Sep 28 20:56:25 my PR is about being lighter when unfocused Sep 28 20:59:45 Tofe: Well in general they're too grey :-P Sep 28 21:03:06 too dark you mean ? Sep 28 21:03:48 See examples and you know what I mean Sep 28 21:06:34 well, ok, I see Sep 28 21:31:50 Tofe: Build machine didn't shut down yet since I'm home since 14:00 Sep 28 21:31:56 So quite some improvement :D Sep 28 21:33:05 Also switched from 12V mainboard connector from 4 to 8 one where only 4 are used (seems recommended according to manual, which is a bit weird), but might give more stable voltage. Sep 28 21:33:47 Anyway it doesn't seem to have cold boot issues anymore. I added 0.125V to northbridge and also some additional voltage to RAM Sep 28 21:33:57 Needs to run at 1.5, made it 1.53 Sep 28 21:34:03 Kept CPU at default Sep 28 21:34:09 In order to control the temp Sep 28 21:34:20 When I raise it with 0.125V it went up 5-7 degrees Sep 28 21:34:29 So decided to keep it auto :P **** BEGIN LOGGING AT Thu Sep 28 23:16:11 2017 Sep 29 01:09:00 Herrie, pong. **** ENDING LOGGING AT Fri Sep 29 03:00:01 2017