**** BEGIN LOGGING AT Sun Nov 27 02:59:57 2022 Nov 27 09:02:41 Morning! Nov 27 09:21:51 morning Nov 27 11:30:56 JaMa: What would be the best approach to use more of the OSE recipes directly? I.e. what steps to take? 1st add the webos_submissions & webos_enhanced_submissions bbclasses so we can use the upstream references directly? 2nd step to add meta-webosose to layers.txt, 3rd to switch to upstream recipes with patches? Or you have other thoughts? Nov 27 11:34:00 depends on what are long term goals of LuneOS, forking meta-webosose would be easiest, but looses much of LuneOS identity (at least from my POV) Nov 27 11:37:21 as on September 30th: Nov 27 11:37:21 11:31 < JaMa> also langdale release is very soon, do we want to update or stay on kirkstone LTS? Nov 27 11:37:24 11:37 < Tofe> well I'm not sure yet; before that, it may be a good idea to discuss with Herrie about our next steps (about mainline, pinephone[pro], apps, status etc) Nov 27 11:37:27 11:49 < JaMa> yes, we should discuss future of whole project without infra and more people getting involved it's almost as dead as SHR 10+ years ago when I've moved from SHR to openwebos :/ Nov 27 11:38:15 2022-07-06.log:12:44 < JaMa> eventually we should discuss LuneOS feature a bit more when Tofe is back, it's useful that we're sharing more and more components from OSE, but it also feels to me that we're a bit loosing our identity (due to lack of manpower to do all thing differently) and then we might just drop meta-webos-ports and fork meta-webosose (e.g. my meta-webosose/kirkstone) and additional Nov 27 11:38:21 layer(s) in webos-ports repo to Nov 27 11:39:09 JaMa: Well we duplicate a lot from OSE now, which is really not needed anymore when they're on Kirkstone Nov 27 11:39:59 I've done a lot of work in past couple of days to get Enhanced ACG working (need to cleanup a lot still before PR-ing) and there are a few lose ends, but we should be able to use upstream OSE for most components already with a few patches. I don't think it means losing a lot of identity Nov 27 11:40:13 We could add meta-webosose layer and then just use .bbappend where needed Nov 27 11:40:23 Should be a lot easier to upgrade going forward that way Nov 27 11:40:29 And keep in sync with OSE Nov 27 11:40:40 Not sure what LG's long term plans for OSE are, but who knows Nov 27 11:40:45 I guess nobody ? Nov 27 11:40:47 things like MACHINE_ARCH being the default, will be difficult to undo Nov 27 11:41:01 and not sure if you want to use luneos as a DISTRO or webos like meta-webosose does Nov 27 11:42:14 Well we're hacking around to get luneos as distro for now, I'm open to change it to webos. Then again the hacks we have are not too many Nov 27 11:42:22 MACHINE_ARCH is not good indeed Nov 27 11:43:06 meta-webos-ports used to be a "rebased" fork of meta-webos and it made sense long time ago when we were able to relatively easily forward port the needed changes to Open webOS (to keep the diff relatively small) Nov 27 11:43:54 now with OSE no really accepting PRs on github it doesn't look that great Nov 27 11:44:12 Well the things we carry are mainly specific patches for LuneOS and to keep legacy compatibility Nov 27 11:44:16 Not needed to upstream most of those Nov 27 11:44:45 But adding the classes as a start isn't bad I guess, so we can streamline the recipes a bit as a first step? Nov 27 11:45:11 They do seem to accept some fixes, but not as PR ;) Nov 27 11:45:19 Some things we PR-ed got merged/fixed at some point Nov 27 11:45:23 if you want to change LuneOS into bunch of patches and recipes on top of OSE, then go ahead - it makes sense from the manpower perspective (lack of) - it's just less interesting for me Nov 27 11:46:00 JaMa: Well it doesn't change much in the end I think? It means we can focus more on development of the OS vs catching up with OSE all the time Nov 27 11:46:25 Identity stays the same, it's more logistics and I think in the end it will reduce the work you need to put into it as well? Nov 27 11:47:24 well now LuneOS is its own distro with better layer layout and not limited by anything OSE does Nov 27 11:48:06 once forked from meta-webosose it's just "another" OSE fork Nov 27 11:49:35 I agree it makes sense from manpower POV and if you and Tofe want to do that, then I'm OK with that. I'm just saying that another OSE fork is much less interesting for me, because LuneOS for me was to do stuff which I cannot easily do in OSE or internal LGE builds Nov 27 11:52:46 JaMa: I guess we could have some middle ground somehow Nov 27 11:52:50 And see what works best Nov 27 11:52:59 Just I see a lot of duplication going on now Nov 27 11:53:15 And we're running behind on the benefits that OSE could bring in some areas Nov 27 11:54:06 true and we're also already compatible with langdale and mickledore, while OSE won't upgrade to newer Yocto for next 2 years Nov 27 11:54:55 But we have your branches of OSE for that? Nov 27 11:55:08 We just need to see how we can have best of both worlds Nov 27 11:55:12 I'm sure there's a way Nov 27 12:05:25 JaMa: OSE in terms of Yocto is in a lot better state compared to initial release Nov 27 12:05:46 We'd still upgrade to newer yocto using your branches and not wait for OSE at least in my view Nov 27 12:06:04 We can still be bleeding edge with Qt etc Nov 27 12:06:13 Just Chromium we're dependent on LG Nov 27 12:07:53 well if you rebase LuneOS fork on top of my rebased branches then yes, it will be a lot more messy Nov 27 12:12:09 JaMa: I think we just want to keep up with "fixes" from OSE and new features (camera, audio, bluetooth etc) so we can piggyback on those instead of reinventing the wheel ourselves or borrow from SFOS Nov 27 12:15:25 I don't think we want to be an OSE-lite, just don't want to be much behind OSE in terms of features Nov 27 12:15:43 Target devices are different, goals are different, but we share a lot of DNA Nov 27 12:16:33 We're now pretty much on 2019-2020 OSE component level, want to bring this to 2022 with Enhanced ACG and then see what's the best to take it forward Nov 27 12:16:41 While keeping identity Nov 27 12:18:13 it will be still a lot of work to migrate, lets discuss this when Tofe is available Nov 27 12:19:46 JaMa: I know.... Nov 27 12:23:27 But with enhanced ACG the path forward should be a bit easier at least Nov 27 18:56:21 On the train, back from a family diner (means a certain quantity of wine, around here), so I'll first sleep over the discussion before saying anything :) Nov 27 19:09:12 just leaving a question for later: can't we achieve the same bb contents using bbappend and bbclass overrides? Nov 27 19:42:55 Tofe: That was my thought too Nov 27 19:43:17 Seems my new laptop might be here tomorrow already Nov 27 19:45:14 Seems they're shipping from Eindhoven with UPS Nov 27 20:23:44 I should get my motherboard either tomorrow, or on tuesday with the ssd Nov 27 20:25:13 Today I started a pinephone build from scratch: "date ; bb webruntime ; date ; bb -k luneos-dev-image ; date" ==> Sun Nov 27 07:34:14 AM UTC 2022 ==> Sun Nov 27 04:14:47 PM UTC 2022 ==> nodejs still building right now ! Nov 27 20:28:29 one weird thing though is that "glances" is reporting my cpu is at 3.24 of max 3.90GHz Nov 27 20:29:20 Tofe: Date is set to 29th here too, but UPS is weird Nov 27 20:29:40 Normally they should be able to deliver tomorrow I'd say, but we'll see Nov 27 20:30:05 yes, all carriers are weird :) Nov 27 20:31:52 Anyway curious to see what will be the build time on it :P Nov 27 20:33:01 yes, quite so :) Nov 27 20:34:13 But would need to install (K)Ubuntu on it first I guess. Nov 27 20:34:34 Comes with Win10/11 and I guess still cannot build with WSL Nov 27 20:45:27 I realize my CPU currently never exceeds 3.6Ghz, though it could go to 3.9Ghz Nov 27 20:46:13 I'll have a little look; not too much though, because it has only a couple of days until retirement Nov 27 20:49:55 "Intel specifies maximum turbo frequency for a single running core." ahah, little devils... Nov 27 20:51:23 But well, I wanted a low TDP, and that's one consequence Nov 27 21:51:46 ==> Sun Nov 27 10:51:27 PM UTC 2022 **** ENDING LOGGING AT Mon Nov 28 02:59:56 2022