**** BEGIN LOGGING AT Fri Dec 13 02:59:58 2019 Dec 13 08:24:54 Morning Dec 13 08:25:43 Morning! Dec 13 08:51:12 Morning! Dec 13 08:55:11 Where is the best place to see the status of things? Dec 13 08:59:02 ka6sox: the status of which kind of things ? https://www.webos-ports.org/wiki/Device_Status returns an error Dec 13 09:00:30 hmmm...wiki broken error? Dec 13 09:04:47 Seems more like a server issue Dec 13 09:11:16 yes, I'm seeing that... Dec 13 09:14:10 let me see if we can figure out why. Dec 13 13:06:13 Tofe: I'm a bit stuck now with the LS2 migration. Seems that LS2 calls that happen through luna-webappmanager don't get a serviceId assigned. So the resulting call has service NULL. Which causes some issues here and there Dec 13 13:06:48 For example: "2019-12-13T10:19:39.496754Z [16.842665204] user.warning storaged [] LS_REQUIRES_SECURITY {"SERVICE":"(null)","CATEGORY":"/diskmode","METHOD":"hostIsConnected"} Service security groups don't allow method call." Dec 13 13:07:23 Which isn't causing huge issues for now, but in luna-appmanager I had way bigger issues which would prevent cardshell from starting, which is not good of course ;) Dec 13 13:07:43 yes, not very good indeed :) Dec 13 13:09:32 There are only 2 places where the "hostIsConnected" method are being called in the rootfs being from systemui: The call is: kind:enyo.PalmService, name:"hostIsConnected", service:"palm://com.palm.storage/diskmode/", method:"hostIsConnected", onResponse:"handleHostIsConnected" Dec 13 13:09:50 So it's probably somewhere in enyo.PalmService where the issue might be. Dec 13 13:12:27 https://github.com/webOS-ports/luna-webappmanager/blob/master/src/extensions/palmsystemextension.cpp#L45 and next line, see the "NULL" ?... Dec 13 13:12:33 Which probably calls: https://github.com/webOS-ports/enyo-1.0/blob/webOS-ports/master/framework/source/palm/services/PalmService.js Dec 13 13:12:49 Ah yes Dec 13 13:13:19 for now we can put luna-webappmanager's id, but ideally it would the appId Dec 13 13:13:25 +be Dec 13 13:14:43 Happy to test something if you have suggestions for code Dec 13 13:14:58 can you try applicationWindow->application()->id() ? Dec 13 13:16:15 oops, it won't build, you'll need "applicationWindow->application()->id().toUtf8().constData()" Dec 13 13:20:08 Let me first build luna-webappmgr for qemux86-64 ;) Dec 13 13:20:30 HAve no local sources yet it seems Dec 13 13:22:34 Which means webengine compilation Dec 13 13:22:38 Well will be quick enough Dec 13 13:23:50 OK made the change, pushed it, so it can build it right away Dec 13 13:32:39 It's just a blind code test, I hope it builds :) Dec 13 13:36:25 Tofe: qtwebengine is almost done, we'll see Dec 13 13:36:55 HAd qemux86 built locally, but have qemux86-64 image i'm testing with in VBOX, so need to build everything for -64 as well now ;) Dec 13 13:37:05 Though it were minor packages so far Dec 13 13:46:22 Tofe: I now have some more permission errors in the logs, but at least with an ID ;) Dec 13 13:46:25 So seems it works Dec 13 13:48:31 I still have 1 without an ID, but that one doesn't come through luna-webappmanager it seems, so that can explain Dec 13 13:50:56 ok good :) Dec 13 13:51:20 luna-appmanager still has issues though ;) Dec 13 13:51:27 But will try to work through that now Dec 13 14:23:50 webos-ports is back up...internals has an issue... Dec 13 14:40:30 JaMa, is the autobuilder cooperating? Dec 13 14:42:35 ka6sox: I don't use autobuilder Dec 13 14:42:53 sorry, I meant your jenkins builds Dec 13 14:43:21 I haven't seen any issues with jenkins (other than lack of disk space) Dec 13 14:44:06 okay, we are working on getting the new expansion going..this means everyone will need to be idle so I can update milla and not fail builds. Dec 13 14:44:19 I'll need to get a time with khem too. Dec 13 14:44:41 you can shutdown milla even when some build is running on bonaire Dec 13 14:45:03 in worst case it will fail to fetch some sstate or fail to rsync the artifacts (which are "cheap" to re-rsync later) Dec 13 14:45:10 yup. Dec 13 14:45:23 okay likely in a few hours. Dec 13 14:45:42 almost done with work today...(and its almost dark here too!) Dec 13 14:49:12 I want to go to Christkindlesmarkt before it gets too cold. Dec 13 14:59:01 ka6sox: is it some kind of Santa Lucia ? Dec 13 15:01:13 Christmas Market Dec 13 15:02:59 ah ok Dec 13 16:08:15 Tofe: Came across this one that wasn't merged yet from a while ago: https://github.com/webOS-ports/qtsensors-sensorfw-plugin/pull/4/files Dec 13 16:56:23 Herrie: can you get me write access on the repo ? Dec 13 16:56:27 I guess that's why :) Dec 13 16:57:22 Done ;) Dec 13 16:58:06 merged Dec 13 17:23:58 Thnx **** BEGIN LOGGING AT Fri Dec 13 17:33:43 2019 Dec 13 22:02:53 Tofe: any plans to update pinephone mesa to e.g. ./meta/recipes-graphics/mesa/mesa_19.2.4.bb backported from oe-core/master? the version in meta-pine64-luneos doesn't have elf-tls option yet http://jenkins.nas-admin.org/job/LuneOS/view/unstable/job/luneos-unstable_pinephone/13/console Dec 13 22:04:26 JaMa: updating pinephone's mesa should be fine for me yes Dec 13 22:05:31 JaMa: it's already available, or should I backport it first? Dec 13 22:07:49 it's not yet in meta-webos-ports (nor the backports layer from dunfell) Dec 13 22:08:56 anyway meta-pine64-luneos is below meta-webos-ports, iirc Dec 13 22:09:44 But there's nothing urgent on that front, it's mostly as it's best for you Dec 13 22:10:51 what you mean "below" in this context? lower BBFILE_PRIORITY? Dec 13 22:11:22 yes Dec 13 22:11:24 it's separate git repo (where I already have write access) so I can adjust, but won't be able to test in runtime Dec 13 22:11:28 in bblayers Dec 13 22:12:04 but I just realized it doesn't matter actually Dec 13 22:12:27 if luneos selects a preferred version, meta-pine64-luneos will use that one, end of story Dec 13 22:13:53 time for sleep, be back in the morning :) Dec 13 22:13:56 yes Dec 13 22:14:57 and I just checked and 19.2.4 is actually a bit "older" than the SRCREV you're currently using, the SRCREV is from master quite a few commits after 19.2 was branched out, so you might need something from there Dec 13 22:15:33 even this: # MESA_EGL_NO_X11_HEADERS was renamed to EGL_NO_X11 in: Dec 13 22:15:33 # https://github.com/mesa3d/mesa/commit/6202a13b71e18dc31ba7e2f4ea915b67eacc1ddb Dec 13 22:15:58 is after the 19.2 branching point.. let me see where elf-tls was merged back to master Dec 13 22:17:04 hmm never mind.. meta/recipes-graphics/mesa/files/0002-meson.build-make-TLS-ELF-optional.patch Dec 13 22:17:14 will just add this patch to your mesa version as well Dec 13 22:23:56 Tofe: BTW: in https://github.com/webOS-ports/meta-pine64-luneos/commit/07c5cdde67fa95b9e7a2a36a93b129ac693064fe#diff-805f6cbf0a7d4d36b12edfe01dd2d93a you forgot to remove the actual 0007-Support-for-branching.patch file (which I've noticed only after manually trying to apply all 7 patches included in this file :)) Dec 13 22:32:24 even more mess in mesa http://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/master&id=28f61f044560f2f21109ccea64841ca2c4acee88 will fix that in oe-core, then no changes will be needed in pinephone Dec 13 22:37:09 and it's still wrong, I need more coffee or sleep, gnight Dec 13 22:38:58 the option didn't came from upstream, but it was already there in meta-pine64-luneos from older oe-core patch https://github.com/webOS-ports/meta-pine64-luneos/blob/master/recipes-graphics/mesa/mesa/0003-meson.build-make-TLS-GLX-optional-again.patch and current oe-core has reintroduced this patch but with this option renamed Dec 13 22:48:26 Tofe: please check last 2 commits in https://github.com/webOS-ports/meta-pine64-luneos/commits/master when you have time, only the 2nd to last is also in zeus **** ENDING LOGGING AT Sat Dec 14 02:59:57 2019