**** BEGIN LOGGING AT Thu Aug 24 03:00:01 2017 Aug 24 05:59:34 Tofe: https://bpaste.net/show/c1ce5e3b34ca Aug 24 05:59:47 It seems it doesn't find additional_features somehow. Aug 24 06:01:56 It seems it changed slightly between 53 and 56: https://github.com/qt/qtwebengine-chromium/blob/53-based/chromium/content/browser/web_contents/web_contents_impl.cc#L1951 and https://github.com/qt/qtwebengine-chromium/blob/56-based/chromium/content/browser/web_contents/web_contents_impl.cc#L2027 Aug 24 06:03:50 Morning BTW Aug 24 06:48:41 Morning! Aug 24 06:49:37 Herrie: that looks like a missing patch or smthg like that Aug 24 06:49:54 I can try to find out which patch adds this class member Aug 24 07:07:12 Herrie: it should be provided by this fellow: https://github.com/webOS-ports/qtwebengine-chromium/blob/webOS-ports/master/chromium/content/common/view_messages.h#L354 ... could it be it disappeared from 5.9 ? Aug 24 07:08:33 5.9 is based on chromium 56 ? Aug 24 07:18:29 Tofe: Yeah it is based on Chromium 56 Aug 24 07:18:40 Tofe: Could be I forgot to patch something let me check Aug 24 07:19:26 Herrie|Pre3: no, it's actually that they modified this part of the code Aug 24 07:19:31 https://codereview.chromium.org/2363573002 Aug 24 07:25:00 https://codereview.chromium.org/2363573002/diff/280001/third_party/WebKit/public/web/window_features.mojom tadaaa (at the end of the file) Aug 24 07:31:24 ... and it will get worse in the next versions, where they moved the code for window feature parsing elsewhere: https://codereview.chromium.org/2905283003/diff/120001/third_party/WebKit/Source/core/page/CreateWindow.cpp Aug 24 07:33:55 Tofe: Hmmmz Aug 24 07:34:09 Well Chromium 56 is interest in the light of successor of Enyo 2 Aug 24 07:35:02 Herrie|Pre3: we'll have to re-add additional_features ourselves, as it is a key mechanism in Enyo Aug 24 07:35:58 Tofe: OK.. I guess that will go over my head in terms off C-code :P Aug 24 07:36:19 Probably :) I'll take care of that Aug 24 07:36:24 Currently seems that Angular or Web Components would be suitable as successor for Enyo 2 Aug 24 07:36:55 I.e. Polymer which has Custom Elements v1 which was added in Chromium 54 Aug 24 07:37:32 Tofe: Not sure you seen/followed the discussion? Aug 24 07:37:47 yes I saw the mails Aug 24 07:38:21 I'd say Polymer probably best fits the webOS mindset and vision. Also helps that there were plenty of key original Enyo devs working on it Aug 24 07:38:32 But I don't know much about these wed frameworks, so I'm just read-only :) Aug 24 07:38:36 web* Aug 24 07:38:55 Tofe: Me neither :P Aug 24 07:39:13 But I can click & play and tell what looks & feels good Aug 24 07:39:57 yes, me too :) Aug 24 07:45:24 So, how do I declare an array of string in their mojom syntax... Aug 24 07:47:42 Tofe: seems array> Aug 24 07:48:12 Or if we know the size array Aug 24 07:48:33 Let me send you link via email Aug 24 07:53:28 thanks! then it will be "array additional_features" :) Aug 24 07:54:45 gosh, that'll be another great adventure in chromium's code... Aug 24 07:59:16 hopefully the additional_features parsing has not moved yed in Chromium 56... Aug 24 08:00:33 Tofe: Not sure... Patches all seemed fine for the rest :P Aug 24 08:00:54 Just the last remaining bit I wasn't able to cover is how to enable the palmbridge Aug 24 08:04:41 We could actually just enable it by default since we're the only ones using it and adding it in by patch anyway Aug 24 08:05:03 No need to specifically enable it in QT really though it's cleaner for modularity Aug 24 08:05:28 Herrie|Pre3: that's true :) Aug 24 10:54:46 Tofe: I've poked some people @ Mer for the qpa bit and sledges picked it to a new branch in upstream and MR-ed it. I asked in #sailfishos-porters to confirm it's working with qt 5.6 so I guess it'll be merged soon :) Aug 24 10:59:16 Herrie|Pre3: thanks ! Aug 24 11:01:22 And it's good it build with Qt 5.6, I never tested it with that version :p Aug 24 11:01:47 Tofe: Well it should Aug 24 13:55:29 http://www.phoronix.com/scan.php?page=article&item=purism-phone-5&num=1 , why reuse the existing code, when you can throw your money in yet another derivative... Aug 24 14:08:58 but maybe I misunderstand they goal; they seem to want to propose a mainlined hardware on a mobile phone. In that case, well, why not, and good luck... Aug 24 15:24:45 Tofe: Yeah only advantage would probably be mainlined hardware. Aug 24 15:24:50 Curious if it'll fly Aug 24 15:24:53 I doubt it Aug 24 15:25:36 Herrie|Pre3: they won't really have mainline torvalds kernel Aug 24 15:25:49 pretty much sure it will frankestine kernel Aug 24 15:26:22 Like anyone else Aug 24 15:26:45 yeah.. maybe it will be latest enough Aug 24 15:26:52 It would be good to have something without Android blobs though Aug 24 15:26:58 Saves additional layer Aug 24 15:27:09 RaspberryPi is a nice platform too Aug 24 15:27:22 We had a working LuneOS port at some point :P Aug 24 16:49:41 Herrie|Pre3: in order to get your latest webengine/qt5.9 work, including your build error, what should I do ? Aug 24 16:56:54 well, I took meta-webos-ports:herrie/qt59 + meta-qt5:jansa/master-5.9-rebase , it should be ok I guess Aug 24 17:07:43 Tofe: yes, that should be enough Aug 24 17:08:38 JaMa: anyway, building qtwebengine will never be a quick thing :p Aug 24 17:10:26 true :/ Aug 24 17:25:26 Tofe: Sorry was in underground shopping mall without reception :P Aug 24 17:25:28 Yeah should do Aug 24 17:25:45 Might need a bump here or there. I think luna-next & sysmgr but yeah Aug 24 17:25:53 Webengine should have latest like that Aug 24 17:38:23 well, it's quite well on its way, qtwebengine should begin soon now Aug 24 17:38:53 I had the time to try a first implementation for additional_features, I have no idea if it will build Aug 24 17:41:30 gn build error Aug 24 17:42:10 "OSError: [Errno 8] Exec format error" ? What does that mean ? Aug 24 17:45:21 Herrie|Pre3: 'Syntax error: word unexpected (expecting ")")' <-- rings a bell ? Aug 24 17:51:51 mmh is it me, or the toolchain tries to execute a "gn" binary built for the target arch ? (arm elf32) Aug 24 17:53:57 yup, that's exactly that. "gn" was built for the target arch. Aug 24 17:54:05 JaMa: ^ you seen this before ? Aug 24 17:57:41 Herrie, JaMa: https://paste2.org/52OXknjg here is the log of the build that leads to a bad "gn" binary Aug 24 17:59:25 Did I forget a step somewhere ? It's weird that it works fine for you... Aug 24 18:03:58 are you sure you have latest jansa/master-5.9-rebase branch? Aug 24 18:04:24 I do think so, let me re-check, because all this is weird Aug 24 18:04:38 I was building it only for qemux86 so wouldn't fail for me if it built gn for x86 Aug 24 18:05:02 the "patch for long paths" is my latest commit here, should be ok yes Aug 24 18:05:51 yes, looks correct Aug 24 18:05:52 JaMa: ok, so if Herrie also built it for x86, I might be trying a new situation Aug 24 18:06:07 I think Herrie was building for hammerhead Aug 24 18:06:37 I did hammerhead & qemu Aug 24 18:06:42 Both failed with same I'd say Aug 24 18:08:13 I thought your builds were successful Aug 24 18:12:12 Herrie: so no "gn" issue with hammerhead like I just had ? Aug 24 18:16:07 Tofe: It actually rings a bell.... Aug 24 18:16:41 Herrie|TP: it would make more sense if we get the same error Aug 24 18:16:44 I think it was solved by cleansstating qtbase & qtwebengine :'( Aug 24 18:16:53 If I recall correctly Aug 24 18:17:02 Or only webengine Aug 24 18:17:11 I've seen it too for sure. Aug 24 18:17:40 You could try to build with all patches in our bbappend commented out to see if you get the same... Aug 24 18:17:46 I thought that it was fixed for Herrie by https://github.com/meta-qt5/meta-qt5/commit/c4c70e76c1ead05c32b6089e32c75eb93b42ae55 Aug 24 18:17:58 But cleansstate is just as quick :-P Aug 24 18:18:22 JaMa: that looks like the kind of fix I would expect, yes Aug 24 18:19:05 I'll double check that it has been applied Aug 24 18:20:46 yup, it's applied Aug 24 18:21:11 let's just try a cleansstate Aug 24 18:23:23 nope; same Aug 24 18:24:25 Tofe: Hmmmz I did you do qtbase cleansstate as well? Aug 24 18:24:41 Or maybe I even did a cleanall :s Aug 24 18:25:04 Herrie|TP: I don't want to rebuild qtbase... :p Aug 24 18:26:44 Tofe: Let me post my layers in a few mins Aug 24 18:26:49 ok Aug 24 18:27:45 Herrie: cleanall doesn't do anything useful Aug 24 18:27:55 Herrie: it just deletes the downloads Aug 24 18:28:27 https://bpaste.net/show/2a2e9d99b003 Aug 24 18:31:14 JaMa: mmh when I do "bb -e qtwebengine", in the result I can see HOST_ARCH="arm"... looks wrong, doesn't it ? Aug 24 18:35:43 yes Aug 24 18:36:00 it's like this for all my recipes, like "wayland" for instance Aug 24 18:36:17 How could i build a whole rootfs like this ? :) Aug 24 18:36:51 I don't know where this is computed Aug 24 18:38:51 documentation.conf:HOST_ARCH[doc] = "The name of the target architecture. Normally same as the TARGET_ARCH." <-- well, that's quite confusing here... Aug 24 18:40:27 ah, ok, usually we don't cross-build maybe Aug 24 18:41:20 yup Aug 24 18:41:22 env.qtwebengine.hammerhead:HOST_ARCH="arm" Aug 24 18:41:22 env.qtwebengine.qemux86:HOST_ARCH="i586" Aug 24 18:42:04 JaMa: but we *are* cross compiling, so is that correct ? Aug 24 18:43:53 Anyway, looks like a wrong lead here Aug 24 18:46:55 Tofe: It seems something in meta-qt5 layer somehow Aug 24 18:47:00 I got it working though eventually Aug 24 18:47:10 But was trial & error and seemed random Aug 24 18:47:14 Layers I posted worked for me Aug 24 18:47:44 Herrie: maybe you built for x86 first, and then for hammerhead without cleansstate, and it took the existing "gn" for the x86 architecture Aug 24 18:48:10 I have the same layers Aug 24 18:49:50 Tofe: You could try qemux86 :P Aug 24 18:49:58 But will rebuild qtbase Aug 24 18:50:00 But could be Aug 24 18:50:03 I did many tries Aug 24 18:50:07 Don't remmeber exact order Aug 24 18:50:10 Herrie: that would mean rebuild everything too :) Aug 24 18:52:54 Tofe: You coudl paste me a patch Aug 24 18:54:24 Herrie: cheers: https://paste2.org/cY1UD7VH Aug 24 19:10:15 Tofe: Building Aug 24 19:10:20 Seems I was doing qemux86 recently Aug 24 19:13:27 Tofe: it shouldn't use gn from different WORKDIR (when building hammerhead after qemux86), because gn isn't built in any -native recipe Aug 24 19:14:04 It might be easier for Tofe to build for qemux86 which is more tested Aug 24 19:14:14 I'll start hammerhead build over night Aug 24 19:14:32 ok I'll switch to that then Aug 24 19:15:06 JaMa: having a -native recipe for building gn might be necessary Aug 24 19:15:41 though I don't know how to stop the build there, and how to reuse the native gn binary afterwards... Aug 24 19:16:14 yes, we tried with mksnapshot and it's not easy with chromium build system Aug 24 19:16:53 I guess gn could be a bit easier as it probably isn't architecture specific, but still chromium build is ugly Aug 24 19:19:30 yup Aug 24 19:20:16 My build is running for a bit already Aug 24 19:20:28 OE hammerhead@luneos ~/build/owpb/webos-ports $ file tmp-glibc/work/i586-webos-linux/qtwebengine/5.9.2+gitAUTOINC+99f84ffd2c_21508b5b54-r0/build/src/3rdparty/chromium/tools/gn/out/Release/gn Aug 24 19:20:31 Compiling Aug 24 19:20:32 tmp-glibc/work/i586-webos-linux/qtwebengine/5.9.2+gitAUTOINC+99f84ffd2c_21508b5b54-r0/build/src/3rdparty/chromium/tools/gn/out/Release/gn: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, stripped Aug 24 19:20:38 it worked correctly for me Aug 24 19:21:30 Tofe: are you sure it was gn binary built incorrectly? not some other error hidden in that python exception? Aug 24 19:21:48 JaMa: Yeah I had some other error above I recall now Aug 24 19:21:53 But had to scroll quite a bit Aug 24 19:22:29 I'll check Aug 24 19:24:58 It's at 41% of big chunk now Aug 24 19:33:02 55 and going Aug 24 19:33:27 sorry, gtg, gl :) Aug 24 19:47:48 65% Aug 24 19:48:07 :) so fast! Aug 24 19:50:44 Herrie: of course, the build error will only happen at 96%.... Aug 24 20:03:52 Ehm earlier but that's because I forgot to save the update .bb with your patch :s Aug 24 20:04:12 I need another VNC client on windows Aug 24 20:04:16 TightVNC is a apin Aug 24 20:04:18 pain Aug 24 20:07:57 Well patch error, but now continues Aug 24 20:08:07 Needed to add a return at the end it seems Aug 24 20:12:12 Tofe: https://bpaste.net/show/c2a373770c87 Aug 24 20:12:19 Well it's alittle further it seems :P Aug 24 20:12:24 But that needs some fix Aug 24 20:27:33 * DougReeder waves hello Aug 24 20:28:18 DougReeder: Hi Aug 24 20:29:04 Thanks for the browser check. Aug 24 20:32:25 DougReeder: You're welcome, no problem. We should be soon able to run the same of LuneOS. I'd guess we're 90-95% there in terms of Chromium 53->56 migration. QT 5.9 is LTS version of QT so we can stay on that for a while. Aug 24 20:34:30 At some point we might move to 5.11 or 5.12 which might include Chromium 62 which will offer a lot of interesting API's like WebUSB, WebPayments etc. But 5.9 is bleeding edge in terms of QT for now so after this upgrade we'll focus on some real OS feature Aug 24 20:34:30 development again & proper bugfixing I guess. Infrastructure wise we should be pretty up to date everywhere :-) Aug 24 20:35:10 That's good. Since Custom Events v1 has stabilized, that should hold us for a long time. Aug 24 20:40:28 DougReeder: Yeah we needed to move the Yocto upgrade which caused some grief and headaches & regressions. Having newer QT & Chromium could eventually allow stuff like Flash & WideVine which in turn would allow Netflix and the likes to run :-) Aug 24 20:40:45 Not unimportant nowadays :-) Aug 24 20:40:52 At least on a tablet Aug 24 20:41:05 * DougReeder nods Aug 24 20:42:03 The Flash & WideVine will need some tweaking to get working but Chromium version at least supports it. Also some other stuff in terms of HTML5 like WebRTC support improved a lot. Aug 24 20:42:16 So overall beneficial in many areas. Aug 24 20:42:36 Just Chromium code changes quite a bit and therefore our custom bits too. Aug 24 20:43:22 Would be good to check with each Chromium release to update patches so when we move a couple Chromium releases at a time, upgrading isn't that hard. Aug 24 20:44:40 45 -> 53 was quite some work. 53 -> 56 seems a little less just they switched from GYP -> GN which complicates stuff. Aug 24 20:48:30 I'd suggest not to try to revive Flash, leave it dead for good Aug 24 20:49:42 pc-world: agree Aug 24 20:50:00 but cool to see that LuneOS is still being actively worked on (I'm kind of surprised by the patience of those involved) Aug 24 20:53:54 pc-world: It's not easy with little devs, but good thing is that a lot of things are now being reused by different projects Aug 24 20:54:02 I.e. Project Halium is interesting Aug 24 20:54:24 Also lots of ground has been covered by Mer/Sailfish/Jolla/Ubuntu/PlasmaMobile that we can use to a certain extend Aug 24 20:54:44 We're pretty much backwards compatible with 3.0.x and most things from 3.0.x work :) Aug 24 20:58:44 sounds good that you collaborate with other projects, I think I've read about it on pivotce Aug 24 20:59:25 https://halium.org/ Aug 24 20:59:36 you've outlived Firefox OS and Ubuntu Phone, I guess in that sense a small developer group + no commercial interest is a good thing Aug 24 21:00:11 It's interesting because basically Android basis and many other bits will be identical, just custom UI and other Linux + OS bits will vary. **** ENDING LOGGING AT Fri Aug 25 03:00:02 2017