**** BEGIN LOGGING AT Mon Feb 29 02:59:59 2016 Feb 29 08:06:26 Morning Feb 29 08:13:14 morning Feb 29 08:15:53 Tofe: I'll dig in logs a bit first but seems I was having issues building a component locally :s Feb 29 08:16:08 Seems instructions on Wiki aren't all that good Feb 29 08:18:21 Wanted to test the qtwayland changes by iscgar for the password delay mask Feb 29 08:20:08 I followed these instructions: http://webos-ports.org/wiki/Building_a_component_in_OE Feb 29 08:24:23 Herrie|Veer: what issues are you running into? Feb 29 08:27:19 Tofe: I tried to replace the git uri in qtwayland.bbappend with the one from iscgar but it seems it tries to fetch stuff from webos-ports GH still with iscgar branch name, really odd stuff. Feb 29 08:28:00 When I clone the component locally and edit local.conf as per instructions on wiki it doesn't seem to build local qtwayland but webos-ports one (with original recipe that is) Feb 29 08:28:55 Herrie|Veer: when the recipe inherits webos-ports-repo (or something like that), it automagically points to our repo Feb 29 08:29:56 But using S_pn should have worked, there must be something in the recipe that prevents it somehow Feb 29 08:30:01 Tofe: I removed the inherit :P Feb 29 08:30:08 Still didn't work... Feb 29 08:30:32 I'll dig a bit in the logs... This was early morning so maybe it was just coffeine lack :P Feb 29 10:21:21 KyleMaas: It wouldn't run for me (i.e. wouldn't render, indefinite spinner). I added some of the missing files from pdf.js to the lib and now it seems to be behaving better. See the branch I created y'day. Feb 29 12:48:17 Herrie: Ah, I wonder if I forgot to commit them to git. Feb 29 13:19:19 KyleMaas: Could be. It looks pretty OK already, just the large PDF has issues rendering pages 3-13. 1, 2 and 14 are OK. Feb 29 13:22:00 Herrie|Veer: Did rendering of those pages work correctly on the older version? I mean, they still use the same rendering engine internally, so I don't know what would be different. Feb 29 13:23:36 KyleMaas: Quite sure they did work on device, not sure in Chrome. Feb 29 13:26:53 Tested it: It worked before :P Feb 29 13:28:47 Huh. Interesting. Feb 29 13:29:13 Oh, and I forgot: page rotation doesn't work yet, either, although that'll be an easy one to add back in. Feb 29 13:29:15 It could be the background rendering going awol somehow Feb 29 13:30:15 * KyleMaas shrugs Feb 29 13:30:26 Could be a lot of things. As I noted in the commit, it's still very buggy. :) Feb 29 13:31:33 Yup :) But it's nice to see. It seems significantly faster though :) Feb 29 15:24:17 Herrie|Veer: http://www.theverge.com/2016/2/29/11122950/raspberry-pi-3-announced-price-specs-release-date Feb 29 15:26:02 Andolamin: Saw that's a really nice device! Feb 29 15:26:22 Porting should be fairly easy right? Seeing similarities with Pi2? Feb 29 15:28:57 I'll need to look. It's moving to a 64 bit processor so the GPU might have changed, so the building qt might need some changes. Feb 29 15:29:36 Then, it all depends on how long before meta-raspberrypi supports the Pi3 Feb 29 15:30:23 Well that's up to community and you can PR stuff there :) Feb 29 15:33:07 GPU is still the same, it seems Feb 29 15:34:36 KyleMaas: I'll add rotate & zoom shortly, is easy indeed :) Feb 29 15:38:31 Herrie|Veer: Zoom's probably going to be a bit more difficult, since IIRC Enyo catches the gestures and it looked rather difficult to just let them fall through to the viewer's default handler. But I don't know Enyo that well, either. Feb 29 15:38:38 Rotate will be a piece of cake to add. Feb 29 15:41:15 Tofe: May not need much work, then. Probably just need to add the config files. I guess we'll see when mine comes in. Feb 29 15:41:24 KyleMaas: Yeah I just used PDFViewerApplication.rotatePages (90/-90) and zoomIn/zoomOut on the +/- buttons for now :) Feb 29 15:41:34 Does the job OK it seems on browser Feb 29 15:41:44 Didn't test this on device with pinching etc yet Feb 29 15:41:52 That might be a different story :P Feb 29 15:42:16 Oh, sure. Yeah. That's what I meant. That doesn't work at all right now, and that's the difficult part. Feb 29 15:42:33 My laptop (where I usually work on it) has a touchscreen, which allows me to test pinch-to-zoom in the browser. Feb 29 15:44:25 Mine doesn't but do have my Ubuntu VM ready now for proper build stuffs :) Feb 29 17:40:23 Herrie: I'm planning to switch to the Pi3 for LuneOS as soon as mine comes in. Also working on resolving JaMa's concerns so we can do official Pi builds. Feb 29 17:41:31 Should I stop worrying about the Pi2 or do you think that's still a worthwhile build target? Feb 29 18:06:17 Andolamin: I think you'll have similar issues for the Pi3, so if you sort them for the 2, it will be easier for the 3 as well Feb 29 18:10:04 And we'll have 2 targets :) Feb 29 18:10:14 You got 95% of the 2 port ready anyway already :) Feb 29 18:10:24 So would be a pity to let that go "to waste" ? Feb 29 18:15:54 Herrie: The layers *should* be identical with the exception of a couple of config files for the Cortex-A53 in the Pi 3 Feb 29 18:18:21 But - because RPi would be MACHINE_ARCH, as I understand it there would be minimal build overlap between the Pi 2 and the Pi 3, so build times would be a concern. If you guys are fine running two builds, I'll continue to verify on the Pi 2 as well as the Pi 3. Feb 29 18:19:51 JaMA: ^ Feb 29 18:47:37 Andolamin: Pi3 will be ARMv8 right? Feb 29 19:02:34 Herrie: Yes, Cortex-A53 Feb 29 19:05:14 Andolamin: That means that if we want to optimally use it, we cannot reuse our current ARMv7 I think, but we'd need to have a ARMv8 optimized build for each component. Not a big issue in general, just initial build takes 1,5 hrs on our build machine. Any subsequent ones will be 20-30 mins Feb 29 19:05:23 Herrie: 1.2GHz 64bit quad-core Feb 29 19:06:00 Herrie: Yeah - I expected that much. Feb 29 19:06:20 Andolamin: Our current targets take between 18 and 25 mins to build it seems when incremental. We should make sure that we're not rebuilding QtWebEngine every time, that's the most important. Feb 29 19:06:33 See http://jenkins.nas-admin.org/ for our build times for luneos-testing Feb 29 19:07:17 Initial build is usually 1,5 hrs for 1st ARMv7 and for QEMU. Subsequent builds are a lot faster due to minimal components to build. Usually between 20 and 30 mins :) Feb 29 19:07:26 Herrie: Yeah - because Qt is MACHINE_ARCH on Raspberry Pi, any Qt rebuild there *should* be isolated to the Pi builds. Feb 29 19:07:28 Not sure if we have chance for beefier hardware Feb 29 19:07:52 Andolamin: I though that MACHINE_ARCH would be sorted with 5.6? Feb 29 19:07:59 Herrie: Not likely Feb 29 19:08:14 ka6sox: ^ What's our current builder spec for Bonaire? Feb 29 19:08:57 Herrie: MACHINE_ARCH won't be sorted until wayland-egl is available for Pi. I can theoretically get wayland-egl to build, but it requires other modifications to qt recipes, so still MACHINE_ARCH there. Feb 29 19:09:17 MACHINE_ARCH issue likely won't be solved until the new VC4/mesa driver set is production ready. Feb 29 19:12:00 Herrie, let me look..iirc it has 12 cores and 128GB of RAM Feb 29 19:21:44 Herrie, ka6sox, 8 cores 100gb ram Feb 29 19:26:52 we could bump its ram up, but its physical host is out of cores Feb 29 19:28:43 Fundraiser for new/second host! (Slightly kidding, that would be expensive) Feb 29 19:34:58 well..we have options... Feb 29 19:35:08 let me think about how to solve this. Feb 29 19:35:39 ka6sox: Not sure we're actually to that point... Feb 29 19:36:00 Herrie: Assuming we add another 30-45 minutes per build for two additional targets, where would that put us? Feb 29 19:38:59 Tofe: ping Feb 29 19:40:21 Andolamin: That should be fine, we usually only do a couple of builds a week. The machine is idling 90% of time :P Feb 29 19:41:11 Herrie: Fair enough Feb 29 19:49:02 Andolamin: I think the biggest issue we have (currently) due to MACHINE_ARCH is that the Pi2 shares ARMv7 with TP, Mako, Maguro & Grouper so having to rebuild QtWebEngine is a problem, unless we can somehow have it build it separately so it doesn't interf Feb 29 19:49:03 ere with our other builds. The Pi3 should be a different story since it's ARMv8 and we'd need to specially build for it anyway already (we cou, Feb 29 19:49:27 ld theoretically do v7 on it but that wouldn't make too much sense imho. Feb 29 19:50:00 Herrie|2: Right. I'm running a test build now, but theoretically I think I can solve that. It will build once for Pi2, once again for all the other ARMv7 targets, then once for Pi3. Feb 29 19:50:28 In the future, if we add more ARMv8 targets it will likely be similar, once for Pi3, then once again for all the other ARMv8 targets Feb 29 19:50:56 The Pi3 would be our only v8 target for now, things get complicated when we would support other v8 targets I guess, but by that time the Pi issue might be solved already :-) Feb 29 19:52:13 Herrie|2: Very likely Feb 29 19:54:38 Even the Fairphone 2, which I would like to do a port for, would be ARMv7. Feb 29 19:54:54 And the VC4/mesa drivers should be ready in a matter of months. Feb 29 19:56:06 Andolamin: And we're OK with bleeding edge stuff in our builds :-P Feb 29 19:56:21 Advantage of a small project :-) Feb 29 19:56:35 Herrie|2: Yeah - if I could get even the bleeding edge stuff working ATM I would be moving over to that Feb 29 19:56:50 BTW, http://terminal.alanstice.com/ and http://terminal.alanstice.com/#dark Feb 29 19:57:02 Opinions on the drop shadows for #dark? Feb 29 19:58:40 IMO right now it's too hard to see the panel edges Feb 29 20:02:08 Where's HaDAk when you need him LOL :-P Feb 29 20:11:53 heh Feb 29 20:12:19 Andolamin; Yeah drop shadows aren't that visible on dark one Feb 29 20:14:09 Hmm. Keep the dark drop shadow but put a 1px light edge highlight next to it, to emphasize the border? Feb 29 20:15:17 Andolamin: I'm not sure.... Not a graphics guy that much Feb 29 20:15:56 No problem - I'll play with it Feb 29 20:22:04 Tofe/nizovn: When you have some time to review and give any comments you need ;) https://github.com/webOS-ports/pmcertificatemgr/pull/1 Feb 29 20:26:47 Herrie: I think the edge highlight did the trick. Much easier to see the division now http://terminal.alanstice.com/#dark Feb 29 20:31:29 Yeah that's a lot better visible Feb 29 21:02:34 Andolamin: Since you seem to know bitbake a bit.... Feb 29 21:02:52 I'm stuck with something very basic :S Not sure what I'm doing wrong Feb 29 21:11:22 Herrie: I'm learning as I go along with this RPi stuff. What's the issue? Feb 29 21:12:27 I have our build environemnt clones as per instructions. I have 1 component local; qtwayland with code from https://github.com/iscgar/qtwayland/commit/ce60662a10bbd28701f1811c91050031fdeae7f1 Feb 29 21:12:31 Just I cannot get it to build. Feb 29 21:12:44 I added it to local.conf, it pulls from webos-ports repo still Feb 29 21:12:58 Same when I change the qtwayland.bbappend to point to the repo from iscgar :S Feb 29 21:13:53 Can you post your bbappend and/or your local.conf? Feb 29 21:15:33 This is my bbappend: https://bpaste.net/show/3936338fbfae Feb 29 21:16:19 In my local.conf I added: S_pn-qtwayland = "/home/herrie/qtwayland" Feb 29 21:18:21 Not sure what's wrong with your bbappend. Looks fine to me, assuming it's actually getting pulled in. Feb 29 21:20:32 Yeah it's probably something small and silly somewhere :S Feb 29 21:21:03 For local.conf, you might also need to add SRC_URI_pn-qtwayland = "file:///dev/null" to force it to skip the download Feb 29 21:21:41 Ah Feb 29 21:21:43 I might try that Feb 29 21:22:13 Ultimately I can also just copy fido branch of meta-webos-ports, make the change in recipe there and then update my layers.txt to point to it Feb 29 21:26:13 Trying 2nd option now ;P Feb 29 21:27:34 Hope it works. If it doesn't, I'm at a loss. Feb 29 21:31:09 No it doesn't ;S Feb 29 21:31:18 Seems it just takes qtwayland and not the append somehow :S Feb 29 21:31:57 Beats me, then. Feb 29 21:32:10 Andolamin; Yeah me too ;S Feb 29 21:32:19 I'll just for meta-qt5 and will adjust there ;P Feb 29 21:43:58 I'm lost too :P Feb 29 21:57:21 Tofe: Whelp.... Feb 29 21:59:12 Herrie: in your meta-webos-ports commit the qtwayland's branch is "add_password_mask_dela" Feb 29 22:00:28 nizovn: Yeah, but it seems to use meta-qt5 instead Feb 29 22:00:33 And ignore the whole bbappend :S Feb 29 22:05:57 Herrie: If I build mako locally, then build maguro, sstate reuse should be quite high, correct? Feb 29 22:06:37 Herrie: And more importantly, qtbase/qtwebengine/etc shouldn't be rebuilt. Feb 29 22:11:55 Andolamin: Yeah I think so Feb 29 22:12:06 But it could be you need to disable the remote SSTATE Feb 29 22:12:25 Ah local.conf has: SSTATE_MIRRORS ?= "file://.* http://build.webos-ports.org/webos-ports/sstate-cache/PATH" Feb 29 22:12:30 So that should be OK I guess Feb 29 22:12:36 Herrie: are you sure that bbappend is in it's place, after changing meta-webos-ports branch? Feb 29 22:12:45 Then it should get it locally first before checking remote? Feb 29 22:13:04 nizovn_: Yeah I tried everything I could think of, just i'm a bitbake n00b Mar 01 01:21:39 JaMa: ping Mar 01 02:12:47 Andolamin, I generally don't see him around at these times Mar 01 02:13:59 ka6sox: np, saw him in the user list, so figured it was worth a shot **** ENDING LOGGING AT Tue Mar 01 02:59:58 2016