**** BEGIN LOGGING AT Mon Dec 03 03:00:03 2018 Dec 03 07:24:35 JaMa: ok, it was just to be sure, I guessed as much Dec 03 07:52:38 (Morning!) Dec 03 07:53:52 Herrie: thanks for the merge, I've started a new build Dec 03 08:23:20 Morning! Dec 03 08:23:27 Tofe: Anyway it wouldn't hurt to poke them ;) Dec 03 08:25:14 Maybe when they get it from multiple sides they'll start to realize something :P Dec 03 08:28:20 yes I'll PR anyway, if someone else wants to do its own distribution based on OSE he'll stumble on the same issue Dec 03 08:30:21 Tofe: Why is this an issue? I don't really understand the bottom of it Dec 03 08:30:51 I can understand you would want to distinguish between desktop and Qemux86 for a number of reasons, but why would this affect our targets is what I don't understand Dec 03 08:32:13 Herrie|Laptop: the problem is with the consequence: it defines the WEBOS_TARGET_MACHINE_IMPL_GUEST symbol, which leads to deactivate the upstart code that sends the notification to systemd Dec 03 08:33:14 I didn't really analyze the steps in-between, as we already had this commit without OSE Dec 03 08:38:30 Tofe: Ah that makes sense! Dec 03 08:38:45 No notification means ls-hubd would not start I guess Dec 03 08:43:32 Tofe: A quick search lead me to this: https://github.com/webosose/cmake-modules-webos/blob/master/webOS/LegacyDefines.cmake#L30 Dec 03 08:43:57 Which means that if we'd overwrite it to "hardware" we should be OK Dec 03 08:44:36 Seeing the default seems to come from https://github.com/webosose/cmake-modules-webos/blob/master/webOS/webOS.cmake#L1120 Dec 03 08:50:20 The core issue might actually be in https://github.com/webOS-ports/meta-webos-ports/blob/75ac53cdacc5f60ae1a8f3543af23e62a7b55568/meta-luneos/conf/distro/include/luneos.inc#L136 which should read "hardware" not "device" imho? Dec 03 08:52:46 Herrie|Laptop: partially, but more important bit is the webos_machine_impl_dep inherit which I've removed from the recipe Dec 03 08:53:59 based on this inherit it sets PACKAGE_ARCH to MACHINE_ARCH (by inheritting webos_machine_dep as well, because you cannot have one MACHINE hardware and one emulator while sharing the same TUNE_PKGARCH (e.g. real i686 HW and VirtualBox) Dec 03 08:54:30 and webos_cmake bbclass sets WEBOS_TARGET_MACHINE_IMPL only when webos_machine_impl_dep is inheritted Dec 03 09:04:16 JaMa: I understand that's not ideal, however we currently don't really have any i586/i686 hardware targets, only VirtualBox Dec 03 09:04:31 It might be a different story when we'd have a qemuarm I guess where it really would become a problem Dec 03 09:04:43 It's implementation by LG is far from ideal, I agree Dec 03 09:25:06 JaMa: the fix here for ls-hubd is within the CMakeLists, not in the recipe Dec 03 11:25:56 I was talking about this https://github.com/webOS-ports/meta-webos-ports/blob/master/meta-luneui/classes/webos_cmake.bbclass#L31 Dec 03 11:26:28 that's why WEBOS_TARGET_MACHINE_IMPL isn't set inside the build after I've removed webos_machine_impl_dep inherit Dec 03 11:27:23 oh, ok Dec 03 13:20:52 JaMa: OK, but shouldn't we in general set https://github.com/webOS-ports/meta-webos-ports/blob/75ac53cdacc5f60ae1a8f3543af23e62a7b55568/meta-luneos/conf/distro/include/luneos.inc#L136 to "hardware" instead of "device"? I think "device" is an invalid value. Dec 03 13:53:55 Herrie|Laptop: ideally the WEBOS_TARGET_MACHINE_IMPL variables should be defined only in webos_machine_impl_dep.bbclass not luneos.inc and shouldn't be used anywhere without inheriting this bbclass **** BEGIN LOGGING AT Mon Dec 03 15:55:23 2018 Dec 03 16:23:07 JaMa: Ideally yes I guess, but the device value is incorrect anyway, no? Dec 03 16:53:59 yes, I don't know about anything using device as a value, either hardware or emulator (with some strange IMHO unused in novacomd Dec 03 16:55:56 JaMa: Based on reading https://github.com/webosose/cmake-modules-webos/blob/master/webOS/LegacyDefines.cmake#L30 I would say there should be only 3 values allowed: "hardware", "emulator" or "guest" Dec 03 16:56:02 Which used to be different as per https://github.com/openwebos/cmake-modules-webos/blob/2349338e62290528a4c000d6bab068a55a47b8eb/webOS/LegacyDefines.cmake Dec 03 16:57:06 In OWO "emulator" and "simulator" where mixed it seems: https://github.com/search?q=org%3Aopenwebos+WEBOS_TARGET_MACHINE_IMPL&type=Code Dec 03 16:57:29 So were "guest" and "host" by the looks of it.... Dec 03 16:57:52 Which I guess could have lead to "funny issue". Dec 03 16:58:06 My gut feeling is that the novacomd uses legacy Palm values Dec 03 16:58:15 Some where changed for OWO, however they forgot novacomd Dec 03 17:12:46 i decided to check and see if there's been any improvements in WSL that get building any further .. looks like we have a failing openssl recipe.. https://pastebin.com/80Ff5Tj0 patch failed, not an obvious wsl-caused problem Dec 03 17:39:07 Herrie|Laptop: if you feel like it, we can try changing the value to "hardware". Your analysis seems quite convincing Dec 03 17:39:27 Tofe: Well see JaMa's comment Dec 03 17:39:45 Ideally we'd do it directly in the webos_machine_impl_dep Dec 03 17:39:50 And drop it from the luneos.inc Dec 03 17:40:02 Anyway the device value was flat out wrong :P Dec 03 17:40:10 That would never trigger anything by the looks of it Dec 03 17:40:26 but I thought we didn't want to inherit webos_machine_impl_dep Dec 03 17:40:45 so... we just drop it? Dec 03 17:41:32 oh sorry ! I didn't see the PR Dec 03 17:42:08 ok so yes let's try to just drop it Dec 03 17:43:17 testing-tissot seems ready, I hope it works better Dec 03 18:18:34 The latest testing build seems to work quite well. It still has some issues activating wifi (simply an rfkill issue it seems) but otherwise that was fine. Dec 03 23:11:37 not sure if that above ^^ error on openssl is important to anything or not, if i re-issue the build command after, it looks like it happily carries on. Dec 03 23:12:55 doesn't look like much headway has been made in WSL as far as dealing with the "locked files" problems that occur, linux-libc-headers and base-files both failed with sstate_package problems Dec 03 23:17:57 EricBlade: I am building with Ubuntu running in Hyper-V. What advantages might using WSL instead offer? Dec 03 23:18:32 nothing, other than not having to install a VM... if it worked.. which it doesn't. Dec 03 23:18:53 I admit to being interested too. Dec 03 23:19:14 I just haven't been brave enough to try it on my big build machine. Dec 03 23:19:45 IF it worked.. you could theoretically get all of the machine's resources, without having to allocate them to VM. though disk access in WSL is significantly slower than on a VM Dec 03 23:20:08 Can WSL use USB devices? That would be an advantage. Dec 03 23:20:27 I believe you can use disks and serial Dec 03 23:29:11 There is *something* that both base-files and linux-libc-headers packages are triggering in /home/eric/webos-ports-env/webos-ports/openembedded-core/meta/classes/sstate.bbclass .. that makes an attempt to *move* a file that is currently open, which is not a valid operation in Windows, and therefore doesn't work. The WSL people have been trying to work with the NTFS people to resolve that, but it's my impression that it's not b Dec 03 23:29:11 n easy process. Dec 03 23:31:25 what I don't know, is if it's something in those specific recipes, or something in the package's build processes, or whatever, or if it can be worked around by altering sstate_package Dec 03 23:33:20 i suppose changing the 'os.rename' to shutil.copy would probably have some kind of affect Dec 03 23:38:05 yep, looks like it does. it at least continues on without erroring. Dec 03 23:46:54 i should probably have made that "try move, if fail, then copy" because as is i doubt i have enough disk space on my system drive to complete this .. but it does look like i've got reason to believe it will be successful if i don't run out of space Dec 04 01:04:52 ... approaching 1100 tasks completed Dec 04 02:05:59 hmm. turns out you can't replace os.rename() with shutil.copy() if the target is a directory. **** ENDING LOGGING AT Tue Dec 04 03:00:15 2018