**** BEGIN LOGGING AT Mon Apr 18 02:59:56 2022 Apr 18 07:56:40 Morning! Apr 18 08:19:43 Morning! Apr 18 08:19:55 Tofe: Good it's fixed at last :) Apr 18 08:21:56 yep :) Apr 18 10:38:25 Herrie: do you know how I can flush all my db8 data on the image ? if I start a new build of luneos-dev-image it'll take 6 hours because of my little webruntime patch :/ Apr 18 10:44:39 ... and now I've just broken the thing. Oh well. Apr 18 11:26:49 Tofe: Well from what I know db8 data is stored as file somewhere on filesystem Apr 18 11:34:49 You can delete a DB8 kind via API call or remove data from a db8 kind Apr 18 11:44:51 Tofe: launch and open don't always do the same, but you know that I guess? Apr 18 11:53:26 Herrie: I don't know precisely no, actually Apr 18 11:54:18 Well launch is fine for opening apps, just like open Apr 18 11:54:27 open call also handle mime types Apr 18 11:54:38 So open various file types Apr 18 11:54:47 At least that's my understanding Apr 18 11:55:56 http://www.banneret.nl/webos/documentation/all/reference/services/application-manager.html Apr 18 12:11:06 Seems open is not there in SAM but we can keep using legacy call for that I guess Apr 18 12:11:16 Or add it to SAM but that might be more work Apr 18 12:12:19 When I looked into it a while ago, seemed that the whole dealing with mime types is not there in SAM anymore Apr 18 12:51:54 codepoet: ^ Is my understanding correct about open and launch? Apr 18 15:38:59 HerrieTP_: ok, I didn't think of mime types, it makes sense Apr 18 15:41:13 looking at our code, it seems that if we manage to call SAM's "launch" from our "ApplicationManager::launch(appid, appArgUrl)" method, then we'll have all the usecase for free Apr 18 16:05:56 Tofe: Yeah that would work Apr 18 16:06:19 Anyway launch in luna-sysmgr and sam are the same I think Apr 18 16:06:32 Just open did more in luna-sysmgr Apr 18 16:07:44 ok I'll redirect our "launch" call then Apr 18 16:08:24 except, maybe, if I see a "filename" parameter, indicating a download request Apr 18 16:08:33 or mime request maybe Apr 18 16:08:55 I think I removed the launch from luna-sysmgr ls2 already so it should use the sam one? Apr 18 16:09:04 Or I'm mistaken? Apr 18 16:09:13 here it's the core apps that use it Apr 18 16:18:52 ok, it's pretty much implemented, not difficult. However, if apps were to call other API or luna-appmanager, it wouldn't behave well, as the app would be in the list of running apps Apr 18 16:19:03 s/or/of/ Apr 18 16:28:57 Tofe: I mean that when we remove the API from luna-appmgr/luna-sysmgr LS2 role files, it should use the launch call from sam even when calling the com.palm one, or not? At least for some it worked that way Apr 18 16:29:10 Anyway I'm fine with the updated call as well of course Apr 18 16:29:16 We did that in other places too Apr 18 16:29:34 HerrieTP: ah, yes, you're right Apr 18 16:29:45 but we can do it in a second time, no problem for me Apr 18 16:30:03 But I had other issues before with legacy call not working and new one did Apr 18 16:30:03 I just want to make sure the "noWindow" stuff works as intended Apr 18 16:30:36 Yeah ls2 stuff is a bit weird at times anyway Apr 18 16:31:02 for now I'm still rebuilding webruntime (yes yes, I started after saying "Oh well" here some hours ago) Apr 18 16:31:27 Next big point, I think, would be maliit Apr 18 16:33:23 maliit shouldn't be that hard, I have some WIP in branch but didn't get to it recently Apr 18 16:34:19 I disabled the Asian languages which might be the cause of the crash I was seeing due to the nasty startup sh they use which refers to it Apr 18 16:35:28 I don't recall if we did patch maliit a lot Apr 18 16:35:48 Not a whole lot Apr 18 16:36:15 But we fixed some stuff from UB Apr 18 16:36:46 It would be interesting to see if we would still need it Apr 18 16:37:25 I mostly want to keep our QML vkbd, which I like Apr 18 16:39:07 Tofe: Yeah that's where we had most patches Apr 18 16:43:29 HerrieTP: my little patch would look like this: https://github.com/webOS-ports/luna-appmanager/compare/herrie/OSE-wam-honister-chromium87...Tofee:herrie/OSE-wam-honister-chromium87?expand=1 but I didn't compile it yet Apr 18 16:59:25 Tofe: lsm is failing to compile here on Tenderloin Apr 18 16:59:35 I will paste the log in a bit Apr 18 17:02:25 https://paste.ubuntu.com/p/FQc7ZDpX5j/ Apr 18 19:10:50 mmh "error: conflicting declaration of C function 'void glShaderSource(GLuint, GLsizei, const GLchar**, const GLint*)'" Apr 18 19:24:59 It does ring a bell somehow Apr 18 19:25:23 I'll check for some tenderloin specifics in meta-webos-ports and meta-smartphone Apr 18 19:25:44 I recall we had something similar previously with libhybris maybe? Apr 18 20:33:01 HerrieTP: I think I had something similar with some opengl debugger library Apr 18 20:34:20 but the difference in the declaration is minor really; it's "const GLchar**"' against "const GLchar* const*" Apr 18 20:34:58 maybe it was apitrace or something like that Apr 18 20:35:45 "Sep 21 06:56:05 However, I've only tested the apitrace build with mesa: if another virtual/egl provider uses slightly different EGL headers definitions, the build could fail. I even needed to patch apitrace to get it working working with mesa." Apr 18 20:37:40 https://github.com/webOS-ports/meta-pine64-luneos/blob/18c4fc528932a83443637e77243771b9c2477550/recipes-graphics/mesa/apitrace/0004-Fix-APIs-conflicting-definitions.patch it was similar, but not exactly the same conflicts Apr 18 21:22:41 Tofe: OK will check another day, bit tired today Apr 18 21:22:48 Thnx for pointers Apr 18 23:11:29 Tofe: I'm seeing the same now when building for tenderloin (after testing that webruntime fix for python2) Apr 18 23:12:28 it seems to include gl2 and gl3 headers at the same time, which might be the cause Apr 18 23:15:29 JaMa: It might be worth to try mako or hammerhead to see if we have the same probs there Apr 18 23:17:45 Since those are also armv7 Apr 18 23:17:52 Rest we have is different arch **** ENDING LOGGING AT Tue Apr 19 02:59:57 2022