**** BEGIN LOGGING AT Tue Jan 25 02:59:56 2022 Jan 25 06:59:33 Morning! Jan 25 07:06:19 Morning! Jan 25 07:48:43 Tofe: I can confirm that the webinspector works for the VBox image now as well :D Jan 25 07:48:44 That makes debugging a lot easier Jan 25 08:05:56 morning Jan 25 09:07:57 JaMa: Tofe fixed the remote debugging issue for webapps :D Jan 25 09:12:05 cool :) Jan 25 09:12:58 I noticed I & Tofe added some images to meta-pine64-luneos now, but I guess we might want to provide some images for other targets as well. Should we just create a new repo for this called luneos-testing-images or so? Or any other thoughts on this? Jan 25 09:13:14 Tenderloin and qemux86-64 would be good to upload as well Jan 25 09:14:36 is there some limit of binary releases hosting on github? Jan 25 09:15:00 long time ago I remember it wasn't allowed to host git with a lot of binaries on github or gitorious Jan 25 09:15:36 so I was hosting shr-chroot (minimalistic gentoo install for OE builds) on SHR git server only while everything else was mirrored on github/gitorious Jan 25 09:17:08 and it's still not clear from Nick's last reply what's left to do on fileserver/builder machines, if it's only loss of data or if something needs to be fixed first Jan 25 09:17:59 he was talking only about kaylee which isn't either builder nor fileserver Jan 25 09:18:01 Guest9634: Is that you Tofe? Jan 25 09:18:06 Or ? Jan 25 09:18:24 Ah JaMa ;) Jan 25 09:18:32 Well there is some limit for GitHub, but it seems mainly when it starts to get lots of traffic Jan 25 09:18:37 I doubt our images would cause that Jan 25 09:19:06 "We don't limit the total size of the binary files in the release or the bandwidth used to deliver them. However, each individual file must be smaller than 2 GB." Jan 25 09:19:48 "There are no hard limits for downloads of released software binaries, though we reserve the right to suspend or throttle your account if we determine your bandwidth usage to be significantly excessive in relation to other GitHub customers." Jan 25 09:19:54 we could also use google drive if someone has spare capaciity (mine is almost full) Jan 25 09:19:58 So I guess we shouldn't really have issues there Jan 25 09:20:37 There were people with 100.000's of downloads who got some issues, but for the rest I don't recall any stories Jan 25 09:21:03 IMHO the biggest disadvantage is that these uploaded images will be disconnected from their jenkins jobs, so someone will have to trust us that the images were built from some published sources (webos-ports-setup branch) and not tampered with Jan 25 09:21:05 If we get to those numbers I would be 1. Very happy, 2. We probably have other things to worry about Jan 25 09:21:37 I hate XDA posts pointing to various download sites to fetch ROMz for you daily phone (I would never do that) Jan 25 09:21:39 JaMa2: I agree, but for now we don't really have any options. I guess if it's you, me and Tofe uploading it should be OK Jan 25 09:22:00 And we can put a big disclaimer up Jan 25 09:22:35 I rarely use any image from our builder. I build more images locally than what I'll ever manage to test :) Jan 25 09:23:11 as temporary solution fine Jan 25 09:23:51 Yeah I guess we should get some more clarity from Nick on the status of the builder etc Jan 25 09:23:57 And what they would be able to provide Jan 25 09:24:07 for long term we need to get the fileserver back if possible and builder as well (even without jenkins master) Jan 25 09:25:04 that way we can continue to do "official" builds in some more controlled environment and publish it from the same place together with logs Jan 25 09:25:47 JaMa2: I agree Jan 25 09:27:16 You want to write an email to Nick with your questions/concerns about GitHub actions? Jan 25 09:27:25 I understood they were working on setting GitLab up as well Jan 25 09:27:47 Because I get an instance when I go to https://issues.webos-ports.org/ ;) Jan 25 09:28:33 PureTryOut[m]: You guys have any experience with GitLab CI and or GitHub Actions? Jan 25 09:38:15 oops, some catching up to do, one moment Jan 25 09:43:52 If we have the choice between our own Gitlab CI and Github Actions, Gitlab might be more flexible Jan 25 09:44:09 but I didn't try any of those two Jan 25 09:49:57 Tofe: Any for publishing some interim images on GitHub for now? I think that having Tenderloin and Qemux86-64 there would be good Jan 25 09:51:45 Herrie: I agree yes, that can be a good temporary solution Jan 25 09:52:07 What should we call the repo? luneos-testing-images? Jan 25 09:52:32 Or just luneos-testing Jan 25 09:53:29 we could also imagine storing some issues there or some documents, though maybe we should stick to one central place i.e. the wiki Jan 25 09:54:11 and if we get a gitlab on issues.webos-ports.org, that would be great :) Jan 25 09:59:21 Tofe: Well wiki for issues is not that great I guess Jan 25 09:59:31 I would prefer GitHub or GitLab for that Jan 25 09:59:36 Easier tracking, adding details etc Jan 25 10:04:37 Herrie: strange, I don't see the need for self-hosted gitlab for our needs Jan 25 10:05:10 JaMa2: Well I guess ka6sox wants to keep things in own hands somehow Jan 25 10:06:46 still git hosting on github.com works reasonably well and is reliable Jan 25 10:07:09 own gitlab just for git is IMHO worse than own jenkins master they didn't want to maintain Jan 25 10:07:58 and as long as we don't need any extra features like docker registries with projects I don't see any benefit of using own gitlab Jan 25 10:12:24 JaMa2: I agree Jan 25 10:12:32 We don't need anything fancy really Jan 25 10:28:55 Agreed too. Maybe it's just an overkill way to propose some planning tool for tasks and issues? Jan 25 10:31:30 Tofe; OK setup https://github.com/webOS-ports/luneos-testing and added some templates for issues and features Jan 25 10:35:05 nice :) Jan 25 11:00:02 Will put some of the known issues in there Jan 25 13:27:07 sent my first PR! Jan 25 13:27:09 https://github.com/webOS-ports/webos-ports-sdk Jan 25 13:27:52 This adds the most commonly used SDK commands from the original webOS SDK, supporting the full lifecycle of Enyo app dev from the command line, and drastically simplifying development Jan 25 13:27:57 (at least for apps) Jan 25 13:28:34 Oops, here's the PR: https://github.com/webOS-ports/webos-ports-sdk/pull/5 Jan 25 13:28:50 you've been busy ! Jan 25 13:30:46 i can be busier now that I've got my toolchain mostly working :) Jan 25 13:31:44 I experience a number of luna crashes, or apps not launching until I rebooted. where should i look for logs so I can help identify those bugs? Jan 25 13:34:17 Identify what leads to the crash (ideally starting from a reboot, to avoid sideeffects of a previous crash), and open an issue on https://github.com/webOS-ports/luneos-testing . To get a good trace you'd need debug symbols, and it can be a bit cumbersome to install the correct ones Jan 25 13:34:58 As long as we can reproduce it, we should be able to fix it, I think Jan 25 13:36:35 You can go further if you want in the issue description, by attaching the journalctl output (as a text file) and the /system/bin/logcat output (also as a text file), but we can do that on our side too Jan 25 13:37:34 If opening an issue is too long, it hinders people from doing it, which is worse Jan 25 13:56:47 ok, i didn't observe any clear repro scenarios yet, but I wasn't really paying attention. it was more like, after launching an app X number of times, it just wouldn't launch any more. I'll start paying better attention when it happens and look in those log file. Jan 25 13:57:40 My next plan is to get the museum working properly, and testing a few more key apps, so there's fun things to do on LuneOS, then start working on some of the system app UIs. Jan 25 13:58:06 In my experience, nothing exposes bugs like regular use :-) Jan 25 13:58:44 Exactly :) Jan 25 19:44:43 codepoet: You saw my comment about VMWare? Jan 25 19:45:03 I'm not sure the emulator works in VMWare, I never tried myself. I know it's a qemu image inside a VirtualBox warpper Jan 25 19:45:06 wrapper Jan 25 19:45:35 i didn't, was that on the PR? Jan 25 19:48:14 On the code itself Jan 25 19:48:19 I can make it on the PR as well if that helps Jan 25 19:48:27 It could be it works on VMWare just I never tested it Jan 25 19:48:36 I guess these .sh scripts only work on *nix right? Jan 25 19:48:45 Or does that work on Windows as well nowadays with WSL? Jan 25 19:48:58 If not I could wrap up some .bat equivalents probably Jan 25 19:49:47 i couldn't test the emulator stuff, since the build server isn't taking any calls right now, but I'll definitely look into it when we're back up and running. Jan 25 19:49:58 I'll put the emulator image shortly Jan 25 19:50:02 I built a bunch of images today Jan 25 19:50:16 The shell scripts should work on *nix and Mac, since the paths are the same. I was planning on doing .bats for Windows too. Jan 25 19:50:30 They'll be here: https://github.com/webOS-ports/luneos-testing/releases/tag/untagged-73e721209caa638893f3 Jan 25 19:50:39 Just my builder ran out of disk space again ;) Jan 25 19:50:48 I based scripts on my VSCode Extensions that are multi-platform: https://github.com/codepoet80/webos-vscode-extensions Jan 25 19:51:29 ok, sweet. i'm hoping I can get the emulator setup down to one script (like palm-emulate) Jan 25 19:52:14 who do i talk to about merging? before I do a bunch of new commits? Jan 25 19:52:50 Well it's mainly me & Tofe looking after the PR Jan 25 19:52:54 He had some comments Jan 25 19:56:06 i read those as feature requests :) Jan 25 19:56:18 Hmmz GitHub is really slow for upload, I thought it was my connection here, but even with my home connection it's slow like hell and that's like 1Gbit/1Gbit fiber (OK those are 400 Mbit/s on WiFi but still) Jan 25 19:56:25 Takes forever to upload a few 100 MB Jan 25 19:57:12 OK it's almost 500 but still.. Takes like 5 minutes Jan 25 19:57:25 ya they try to discourage storing binaries in there Jan 25 19:58:09 Well my connection will do it anyway Jan 25 19:58:13 WIll take a bit longer but well Jan 25 19:59:39 unrelated, but I'm reading up on this exploit chain for webOS TVs, wondering if I can do something like this to Touchpads: https://github.com/RootMyTV/RootMyTV.github.io Jan 25 19:59:58 its remarkable how much of legacy webOS is still in there (luna service bus, PalmSystem) Jan 25 20:01:28 Yeah well it's basically unchanged under the hood for a large extend Jan 25 20:01:39 Lots of rebranding from palm to luna and LG Jan 25 20:01:57 For the rest they took apart LunaSysMgr into various components and updated some bits here and there Jan 25 20:02:23 But basically it's still the same just more restrictive, secure and locked down (until recently at least) Jan 25 20:02:27 Homebrew is nice Jan 25 20:22:42 ok, i made some changes Jan 25 20:22:52 but i don't know how to do a new pull request while the previous one is pending Jan 25 20:23:13 Ehm make a new branch, add changes there and PR from there Jan 25 20:23:17 That's the only way really it seems Jan 25 20:23:32 Otherwise it gets added the existing one in my experience Jan 25 20:23:39 I'm sure there might be other ways (or not) Jan 25 20:23:41 ya it won't let me do that Jan 25 20:23:45 I'm also no git expert Jan 25 20:23:47 could you just merge my previous PR? Jan 25 20:23:53 It won't let you do what? Jan 25 20:23:56 Create a new branch? Jan 25 20:24:17 I'm often lazy and use GitHub web or GitHub for Windows client for that and create it based on a certain branch I have already Jan 25 20:24:57 won't let me combine. my changes are in my branch, and i can compare them, but I can't combine them, or re-submit. Jan 25 20:26:03 Not really sure what you mean by that Jan 25 20:27:19 ya, i have no idea what to do. Jan 25 20:27:33 looks like i'm just in limbo until the PR is merged Jan 25 20:28:35 That's really weird Jan 25 20:28:41 You should be able to create a new branch Jan 25 20:28:58 ok, i could close the previous PR, then re-submit Jan 25 20:29:46 Well what you can do: You now have a master branch: From there you create a new branch called "initial-pr" for example. Then do the PR from that branch to our repo Jan 25 20:29:54 Then add new features in master again Jan 25 20:30:15 When you're ready to do a new PR, create a new branch "subsequent-pr" and do the PR from there Jan 25 20:30:36 If you only have 1 branch, it will automatically take that branch in the web UI Jan 25 20:30:49 If you have multiple you can select which one to use Jan 25 20:31:05 I do quite a bit in the UI at times when I feel lazy or don't have the client at hand Jan 25 20:31:52 ya, I try to avoid the UI because I never understand what voodoo its doing in the background. I'd rather fight through Git's weird command line! Jan 25 20:32:44 anyway, new PR: https://github.com/webOS-ports/webos-ports-sdk/pull/6 Jan 25 20:33:00 I'll do the Windows scripts after that one gets merged. I added Tofe's feature request. Jan 25 20:34:57 Well the UI is pretty OK nowadays, but you can do it in command line too of course Jan 25 20:35:51 JaMa lives in command line ;) Jan 25 20:36:04 I think the only thing he uses UI for is browser at times LOL Jan 25 20:36:42 Anyway here are some images just to with: https://github.com/webOS-ports/luneos-testing/releases/tag/20220125-LuneOS-Testing-Builds Jan 25 20:36:49 Including the emulator one Jan 25 20:37:07 I'll double check the .ovf in the SDK, we updated it for our emulator image sometime in the past Jan 25 20:37:09 yay ,thanks Jan 25 20:38:13 Ah this image still includes Waydroid as well Jan 25 20:38:21 You can try to run that as well ;) Jan 25 20:38:45 what's a waydroid? Jan 25 20:38:46 The emulator that is Jan 25 20:38:57 Waydroid is Android inside of Linux ;) Jan 25 20:39:15 Still in early stages of support in LuneOS really, we basically just built it Jan 25 20:39:15 ooh cool Jan 25 20:42:47 Basically it's all there, you just need to run the following: https://github.com/webOS-ports/meta-webos-ports/blob/honister/meta-luneos/recipes-support/waydroid/waydroid.bb#L78-L91 Jan 25 20:47:12 can't imagine the perf will be great on touchpad Jan 25 20:48:05 No for sure not, but the concept is nice Jan 25 20:48:22 If the Touchpad would run mainline kernel it might be better, but that's still a bit away Jan 25 20:48:29 Though some people are working on that Jan 25 20:48:35 ya, Sailfish did something similar. it definitely makes their OS more useful Jan 25 20:48:48 So that means mainline kernel, no binary blobs etc Jan 25 20:48:52 Or minimal ones Jan 25 20:49:01 Well SFOS has Alien Dalvik and only paid Jan 25 20:49:09 This is free, maintained by community Jan 25 20:49:34 Alien Dalvik is only on officially supported targets of SFOS, not on community ports (at least not officially I think) Jan 25 20:50:41 There might be ways, but I never looked into it really. SFOS isn't that nice in terms of usability imho Jan 25 20:51:49 i don't love the gestures and menu, and their EAS support is flaky. but its quite stable. Jan 25 20:51:58 ok, I've now catched up Jan 25 20:52:09 codepoet: Yeah same thoughts here Jan 25 20:52:32 Well they've thrown a ton of cash, developers etc at it, so it ought to be Jan 25 20:52:47 And it had a proper base to start from, similar to webOS really Jan 25 20:53:22 Herrie: can you add me to webos-ports-sdk as read-write ? I think the PR can be merged, looks fine Jan 25 20:54:33 Tofe: Done Jan 25 20:55:06 There's very little difference in terms of how it operates under the hood. The whole luna concept in webOS is way better vs what I've seen elsewhere to be honest and quite intuitive. Just the approach of how SFOS uses Android bits vs others differs Jan 25 20:56:23 codepoet: merged, thanks ! Jan 25 20:57:52 thanks! gonna update my LuneOS touchpad now! thanks for the fresh bit! Jan 25 20:59:51 Well it should be similar to what you have really Jan 25 21:00:08 I just built everything from scratch here today Jan 25 21:00:17 It should fix the remote debugging which is very useful Jan 25 21:10:49 We didn't fix the disabling of udev-settle yet though Jan 25 21:15:22 Tofe; OK, well it'll still work, just slower Jan 25 21:20:32 Well I'm not sure, it looks like it does influence the moment when the wifi module loading is triggered Jan 25 21:40:21 codepoet; I guess this whole "create appliance" bit could possibly be dropped because we already provide a .ovf together with vmdk in the archive nowadays Jan 25 21:43:20 These bits I mean: https://github.com/webOS-ports/webos-ports-sdk/tree/master/appliance Jan 25 21:52:00 Tofe: You remember where you found those QMI patches for oFono for PP? Piggz from SFOS is asking Jan 25 21:52:43 Ah I guess from here https://github.com/sailfish-on-dontbeevil/ofono/commits/master/ofono Jan 25 21:59:38 Herrie: yes, it was probably from there Jan 25 23:30:06 ok, i've got the base create emulator script working well, but I'm not sure the expected behavior Jan 25 23:30:12 it won't start, because it doesn't like the CPU Jan 25 23:30:49 subsequent scripts require adb to find a device -- does it need a real device? or is it expecting to find the emulated device? Jan 25 23:31:10 also, BASEIMG and KERNEL refer to the build server, which is 404ing Jan 25 23:34:29 the virtual appliance "just works" though. so maybe we don't need these scripts at all? Jan 25 23:36:17 the OVF is *fire* Jan 25 23:36:53 however, adb doesn't see it as a device Jan 26 01:58:54 codepoet: We use ADB only on Android based devices. Devices such as emulator which use a mainline kernel (and PinePhonePro, PinePhone and maybe others in future), will use regular SSH/SCP on port 22 Jan 26 02:00:12 so a whole different way to push apps? Jan 26 02:03:08 Well not whole different, but instead of adb shell use ssh/scp Jan 26 02:03:16 k Jan 26 02:03:29 I guess novacom MIGHT work, but I never tried it to be honest Jan 26 02:03:46 so i guess in the scripts i could check if there's a adb device connected, then fall back to scp... but I'd need to know the IP Jan 26 02:04:01 maybe i can take IP as an argument, and if present, assume scp Jan 26 02:04:54 Just SSH/SCP is a lot more standardized vs previous novacom of course Jan 26 02:05:55 Ah for emulator it's port forwarded Jan 26 02:05:59 So localhost:5522 Jan 26 02:06:10 That's an easy one Jan 26 02:08:19 For the mainline devices not sure, guess would need to check with Tofe when he's around. There might be something via USB as well, but not 100% sure. I just always do via WiFi at my end Jan 26 02:09:08 ok, emulator next then Jan 26 02:11:25 But the approach to specify IP and optional port might work Jan 26 02:11:44 so since you're here Jan 26 02:11:59 what's the intent of the emulator scripts in that sdk repo Jan 26 02:12:16 they seem to be superfluous since your build produces the ovf Jan 26 02:12:44 and the script doesn't even produce a working vm configuration Jan 26 02:15:24 codepoet: That's what I pointed out above Jan 26 02:15:44 oh i thought you meant just the appliance part Jan 26 02:16:02 ya, the whole thing seems like duplication Jan 26 02:16:34 Well the creation of the appliance for sure because it's in the archive now already Jan 26 02:16:38 Not sure where that came from Jan 26 02:16:45 Maybe legacy SDK somehow Jan 26 02:16:56 And he tried to replicate that Jan 26 02:17:00 does the build use those scripts? or is it safe to nuke/drastically re-factor? Jan 26 02:17:17 No build doesn't use it Jan 26 02:17:46 Let me just cross check where the OVF comes from though Jan 26 02:17:54 k, cool Jan 26 02:18:36 We provide an ovf for qemux86 and qemux86-64 ourselves in meta-webos-ports Jan 26 02:18:50 Though for webOS OSE LG doesn't provide an OVF ;) Jan 26 02:18:59 There it might be useful somehow Jan 26 02:19:06 In some way or form Jan 26 02:19:28 Just remembered about that one now Jan 26 02:20:44 I mean see their painful instructions at https://www.webosose.org/docs/tools/sdk/emulator/virtualbox-emulator/emulator-user-guide/ Jan 26 02:20:56 We suggested them to include an OVF but to no avail Jan 26 02:22:10 ya the script i plowed through today automated most of that Jan 26 02:22:28 But we could do that in another phase, since OSE is not directly what we focus on of course, but it's a related project Jan 26 02:22:49 i spent like 2 hours fighting with vboxmanage cause its default Machine folder has a space in it, but it won't accept a space in its arguments Jan 26 02:22:49 That works similarly, though I find their emulator to be not very useful really Jan 26 02:23:12 wrapped things a dozen ways before i found the magic combo...then saw the ovf i downloaded from you and it just worked Jan 26 02:24:25 Well I guess we could keep the code for now and update it later for OSE Jan 26 02:24:33 I would need to revisit that OVF a bit Jan 26 02:24:49 And create an OSE image since it was on our build server too Jan 26 02:25:11 We builded it for LG "as a service" in exchange for some donated disks ;) Jan 26 02:29:04 Anyway it's somewhere in the middle of the night here and I only woke up for a sip of water, I better go back to sleep ;) Jan 26 02:29:16 thanks, gnight Jan 26 02:33:01 Any questions you come up with, you can drop them here so we can have a think about it when you're asleep ;) Jan 26 02:33:08 Since both Tofe & I are in Europe **** ENDING LOGGING AT Wed Jan 26 02:59:56 2022