**** BEGIN LOGGING AT Fri May 15 02:59:57 2020 May 15 06:22:56 JaMa: Getting the same error on Mido with the latest unstable May 15 06:24:58 I have no gesture bar, no volume buttons working, no system menu, so seems something is off with QML. I see a lot of these: May 13 05:02:33 mido luna-next[2368]: WARNING: 03:02:33.706: file:///usr/palm/luna-next/shells/card/qml/StatusBar/SystemMenu/SystemMenu.qml:352:21: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function May 15 06:24:58 onFoo() { ... } May 15 06:58:49 Let me see if I can tackle those quickly, shouldn't be rocket science by the looks of it May 15 08:35:29 JaMa: This should do it I would say for luna-next-cardshell but it doesn't solve the issues yet though: https://github.com/webOS-ports/luna-next-cardshell/commit/9bbeb52b6ffd08c4f8de6afcf2aabd53e5658221 May 15 09:06:17 Morning May 15 09:07:42 Herrie: the QML change is just a wrning for now, but yes, we should fix it before it's an error :) May 15 09:08:11 For the node.js version mismatch, I think I discussed it with JaMa a week or two ago May 15 09:08:30 it "should" be just a minor change to do in a recipe May 15 09:08:52 for the boot partition, I think it's new May 15 09:09:32 but it could be related to the mdev changes I did some time ago for the initrd May 15 09:16:38 Herrie: for the QML functions slots, some are missing their arguments; most of them have none, so most of the commit is fine though May 15 09:16:41 Tofe: Well Mido boots May 15 09:16:52 So I suspect the issue was me toying with Halium 7.1/8.1 on Hammerhead May 15 09:17:10 Didn't test Tenderloin yet May 15 09:17:15 Herrie: I don't think android really needs /boot May 15 09:17:15 Will fix those warnings May 15 09:17:20 They need fixing anyway May 15 09:17:27 At some point May 15 09:17:34 They're easy enough in general May 15 09:18:01 the node.js error should explain most of your issues I think May 15 09:18:22 Let me double check those fixes first ;) May 15 09:18:47 you're probably still in first-use mode, even after completing the app May 15 09:21:03 Tofe: Yes on reboot it's stil there May 15 09:21:07 And I get FirstUse again May 15 09:23:23 Tofe: In these cases, should I add cardViewInstance? https://github.com/webOS-ports/luna-next-cardshell/blob/herrie/qt-5.15/qml/LunaSysAPI/SystemService.qml#L152 May 15 09:24:11 Herrie: no, this one is fine, currentCardChanged has no args May 15 09:24:47 Qt could have provided a little script to check all these signals/slots... May 15 09:25:25 Herrie: in a general manner the on*Changed shouldn't have args May 15 09:31:07 Tofe: OK and this one? https://github.com/webOS-ports/luna-next-cardshell/blob/herrie/qt-5.15/qml/CardView/CardGroupDelegate.qml#L90 Should add window there? May 15 09:31:15 And on L96? May 15 09:31:20 Rest seems clear to me May 15 09:32:13 Herrie: these look fine May 15 09:32:25 "window" comes from the broader context May 15 09:34:59 I checked them, then it should only be changes in LaunchBar/Launcher.qml: function onStartLaunchApplication() -> function onStartLaunchApplication(appId, appParams) twice May 15 09:36:06 ok, it's true that most of our signals have no args, or don't use them May 15 09:36:39 migrating the rest of the QML apps will be a bit boring too May 15 09:37:03 Tofe: Will get onto that May 15 09:37:06 Not hard in general May 15 09:37:15 Already started with phone May 15 09:37:20 Seem VKB needs as well May 15 09:41:04 https://github.com/webOS-ports/org.webosports.app.phone/commit/52c933f2b3e9a7a401fd6a0b8a21d6f9c17f9800 May 15 09:46:04 https://github.com/webOS-ports/webos-keyboard/commit/5d7fd07e1384d39f85b88be8f55e98689c85c293 May 15 09:51:36 And https://github.com/webOS-ports/luneos-components/commit/cfc82cacc1e33aaa6191b0618c3fc451e840a166 May 15 09:51:41 That are the ones I saw so far May 15 09:52:42 Tofe: For the phone app, an easy way to verify somehow? May 15 10:01:38 Tofe: Changed them for Phone app May 15 10:11:38 Herrie: I think the vkb is ok May 15 10:14:41 Herrie: it's a bit cumbersome to check, actually... the signals are sometimes declared in QML (via the "signal" keyword) but also in C++ (in the "Q_SIGNALS" part of the header), and some come from Qt itself (like rowsInserted) May 15 10:15:06 https://doc.qt.io/qt-5/qabstractitemmodel.html#rowsInserted May 15 10:15:52 for the latter, it could also be that we need to keep a correct ordering of the arguments: "parent, first, last", even if parent isn't used May 15 10:16:15 There is probably no check whatsoever in js May 15 10:20:35 If we don't put them we get some undefined error in logcat? May 15 10:27:12 Herrie: that would end up in the journal, but... I wouldn't be so optimistic May 15 10:31:26 Journal that's what I mean May 15 10:32:11 oooooooooooh wait wait wait May 15 10:32:43 it's just for the "Connections" QML element that we should use functions !! May 15 10:33:01 dammit I misunderstood completely the warning May 15 10:36:15 now I understand better Qt's move: indeed, for Connections, we use "onFoo:" but it doesn't match any declared signal in the QML element itself, so syntaxiclly it's not pretty May 15 10:36:58 So they want us to use functions when we use Connections, and the QML Connections element will map the signals. May 15 10:38:45 Herrie: I think I misguided you into too much work here May 15 10:43:55 So simple functions without params work? May 15 10:44:38 That was my understanding from the qt page May 15 10:59:15 Tofe: I was looking at https://doc.qt.io/qt-5/qml-qtqml-connections.html May 15 11:20:49 Herrie: if the params aren't needed, we don't need to put them, I guess May 15 11:24:38 though the example you're pointing to includes the params May 15 11:26:24 (I just realized you indeed did only change the Connections elements, so you didn't do any useless work, which is great :) ) May 15 11:28:43 So I guess it's a bit trial & error to see if we need the params in the ones you pointed out? May 15 11:33:12 we can also look at the signal header itself May 15 12:18:03 ka6sox: I'm seeing a lot of Input/output errors from the fileserver today: http://jenkins.nas-admin.org/job/LuneOS/view/unstable/job/luneos-unstable_workspace-rsync/454/consoleFull May 15 12:22:05 In general build.webos-ports.org is slow here in recent weeks May 15 12:22:21 To connect and also the downloads are not as quick as they used to be May 15 13:02:41 JaMa: Dunfell behaves OK-ish on Mido & qemux86-64. Seems the biggest issue is this nodejs issue for now May 15 13:15:12 Herrie: thanks for the ACG work ! I'll test it this week-end :) May 15 13:15:59 Tofe: I need to rebase it May 15 13:16:06 I just wanted to see which recipes gave issues May 15 13:17:19 Let me rebase it shortly May 15 13:54:27 We are getting slammed by China with DOS attacks...they are working thru the address ranges. May 15 13:54:49 I'll look at the I/O error issues. May 15 13:54:54 ka6sox: thanks! May 15 14:42:38 ka6sox: Chinese think you're hosting a COVID-19 cure/vaccine ? May 15 14:43:09 Herrie, unknown...but they are going through our address range. May 15 14:45:51 Tofe: Needed to redo it a bit, so here it is, that's mergable. https://github.com/webOS-ports/meta-webos-ports/pull/428 Will build test at home first too May 15 14:52:27 This should hopefully cover 90-95% of the needed migration May 15 14:52:39 There's still some loose ends from what I recall, but it shouldn't be a whole lot May 15 14:58:49 Tofe: Build testing for qemux86-64 now May 15 14:59:04 Pushed a quick fix to packagegroups already, seems I forgot that one previously May 15 15:14:49 Herrie: yes I saw the mails :) You already re-enabled the luna-webappmanager ACG ? May 15 15:17:09 Tofe: Yeah think so May 15 15:17:09 It was there before May 15 15:17:27 I remember journal was pretty clean and there were some minor things to fix still May 15 15:17:39 Just haven't been able to do a whole lot with RAM issues and COVID lately May 15 15:17:46 Now finally finding time again May 15 15:36:30 I'm now building tissot May 15 15:38:08 ah, damn, qtwebengine May 15 16:39:00 pushed small ls2 fix for gcc10 May 15 17:05:58 and the same for qmltermwidget May 15 17:12:06 Tofe: Found a few other minor things, pushing shortly May 15 17:14:27 Must have missed a few things with my original push somehow :S May 15 17:15:54 Herrie: do you see anything obviously wrong in https://github.com/Swordfish90/qmltermwidget/commit/e1b6ac5c6ca3db037127f6be2721fa902a1bbd81 ? May 15 17:19:50 JaMa: Nothing obvious really May 15 17:20:25 Not sure why they install historic layouts May 15 17:20:30 It wasn't there initially it semes May 15 17:20:38 The kblayouts2 that is May 15 17:21:18 hmm it looks like this whole section is useless, because it's also installed by "assets" above May 15 17:45:01 Tofe: Pushed some minor fixes May 15 17:45:07 Having some issues still @ my end though May 15 17:45:45 qtsensors-sensorfw-plugin: giving me Project ERROR: Library 'sensorfw' is not defined. May 15 17:45:57 Which is weird, because sensorfw is being built OK it seems May 15 17:48:14 Herrie: ok, I've taken it into account, thanks May 15 18:33:38 Herrie: can I push 'a0ad355 (shr/herrie/ls2, origin/herrie/ls2) mediaindexer: Migrate to LS2 ACG model' into zeus branch with SRCREV bump (including gcc-10 fix) or will it break your ACG migration if it's not all in one go? May 15 18:36:00 JaMa: Should be fine May 15 18:36:10 We build master anyway for ACG May 15 18:36:24 ok May 15 19:45:35 Tofe: 3 other minor fixes pushed. Not sure why it worked before and stopped working on my builds but well May 15 20:39:59 Tofe: I'm stuck with Mido & qemux86-64 now on sensorfw-plugin May 15 20:46:40 Will call it a day while I let it build for Tenderloin too May 15 21:00:49 Herrie: on my side I stopped the build because I wanted to play some game, so I'll resume it tomorrow too; but I can begin with building sensorfw-plugin then May 15 21:16:42 ok I reproduce the build error immediately :) it might be something the Mer guys removed or modified in sensorfw, I saw you updated the recipe May 15 21:17:37 anyway I'll look at it tomorrow, I'm a bit tired **** ENDING LOGGING AT Sat May 16 02:59:57 2020