**** BEGIN LOGGING AT Tue Feb 21 03:00:00 2017 Feb 21 07:33:37 Morning Feb 21 08:40:56 morning Feb 21 08:41:22 Tofe: Mako stable build had an error, but on rebuild it was fine. Feb 21 08:41:39 Wasn't able to test Mako & Hammerhead yet but Maguro & TP seem fine. Feb 21 08:42:36 ok good Feb 21 08:43:12 Do we need something else before starting stable? Feb 21 08:45:24 Tofe: No I just rearranged the jobs so it builds 3, 3 and 2 images with the Pi2/Pi3 as last images. Feb 21 08:45:44 There's a Pre and Post-release to-do page on the wiki which describes the process. Feb 21 08:47:20 ok Feb 21 08:48:05 It's quite manual currently but for once a month it's fine. Longest takes putting changelog & writing article. Feb 21 08:48:34 :) Do you need some help on the latter? Feb 21 08:49:11 Tofe: Well I still need to write the article, should be able to do that today. But feel free to pitch in :P Feb 21 13:19:19 Tofe: the new pvrsrvkm recipe fails with newer Yocto http://errors.yoctoproject.org/Errors/Details/133827/ are you willing to fix it? Feb 21 13:24:25 JaMa: This is with Morty or even newer? Feb 21 13:40:50 JaMa: Is it normal that this recipe is used outside of a maguro build? Feb 21 13:41:48 (because it shouldn't, I've only added it to maguro's config, iirc) Feb 21 13:43:34 the tests are running with master, but most likely it will be reproducible with morty as well Feb 21 13:43:54 Tofe: these are "bitbake world" builds Feb 21 13:44:01 so it builds everything available Feb 21 13:44:16 we can restrict it with COMPATIBLE_MACHINE = "^maguro$" Feb 21 13:44:24 if it's meant to be used really only with maguro Feb 21 13:44:35 Yes, it's the GPU driver for maguro :) Feb 21 13:44:45 ok, will update it Feb 21 13:45:28 ok thanks :) If you want you can also remove the "strip" thing, which you didn't like much and seemed useless Feb 21 13:46:04 ( PACKAGE_STRIP = "no" at the end of the recipe ) Feb 21 13:46:54 ok Feb 21 13:47:06 also why did you install it manually? Doesn't modules.bbclass do that? Feb 21 13:47:33 and for modules-load.d there is mechanism in module.bbclass already, will need to check if the same is already available in krogoth Feb 21 13:47:37 but I think so Feb 21 13:47:46 it's kind of a weird one here, as it's a source code initially made for Android build system Feb 21 13:48:28 so there isn't any "modules_install" target Feb 21 13:49:26 maybe I missed an easier way of achieving the same result Feb 21 13:50:33 I'm especially not proud of the hardcoded binary path in my recipe... Feb 21 13:52:38 for modules-load.d I just copied memnotify recipe (which is quite old now), so it is very possible I missed the correct way to do this Feb 21 13:53:52 possible improvement (not tested) pushed to jansa/master branch Feb 21 14:09:54 ok thanks Feb 21 14:10:06 I'll test it on krogoth tonight Feb 21 14:47:11 JaMa: Tofe had some issues with some of the Mer parts on Krogoth which don't look to different from mine on when I last tested Morty. So when I get this release out of the way I'll be doing some Morty testing again. Feb 21 14:47:32 cool Feb 21 14:47:58 maybe we should switch Morty and go to Pyro directly Feb 21 14:48:07 the recipe-specific-sysroot is good feature Feb 21 14:49:39 JaMa: Yeah depends a bit. Usually 2 in 1 gives headaches, but can do Morty and shortly after Pyro. Or test Pyro right away. Feb 21 14:49:49 We still need to do the QT 5.7 migration as well. Feb 21 14:50:22 I will try Pyro soon and move Qt 5.7 after Pyro Feb 21 14:50:31 there is also 5.8 in meta-qt5/master now Feb 21 14:50:48 but there won't be 5.8.1 bugfix release and 5.7 also isn't so great Feb 21 14:51:04 so I think we can postpone Qt for a while Feb 21 14:51:43 the Morty-Pyro upgrade should be relatively pain-less (biggest change is RSS and most of the failures caused by that are just missing dependencies) Feb 21 14:56:59 JaMa: what do you mean by "5.7 isn't so great" ? Feb 21 14:59:54 Tofe: there is big flame on qt ML about bad issues with 5.7 and TQC not planing to do bugfix release soon Feb 21 15:00:10 and instead of bugfix release they want to do 5.9 first Feb 21 15:00:25 Oh. Weird quality process here. Feb 21 15:00:29 and they canceled 5.8.1 because of the same reasons Feb 21 15:00:42 lack of manpower for releases they say Feb 21 15:01:00 and I believe that, it's just bad for consumers (or customers) Feb 21 15:01:17 yes, exactly, it gives a bad image too Feb 21 15:01:54 so I wouldn't mind holding qt upgrade for now and then maybe jumping to 5.9 directly Feb 21 15:02:14 unless there are some new features in 5.7 or 5.8 which we really want for LuneOS Feb 21 15:02:24 JaMa: iirc, the main risk about 5.7 was the big rework for qtwayland Feb 21 15:02:34 yes, that's where I got stuck rebasing our changes Feb 21 15:02:39 and similarly in qtwebengine Feb 21 15:03:02 so now my master builds were just dropping qtwebengine and everything depending on it from the image Feb 21 15:03:13 well, 5.7 for me means QtQuickControls 2, mainly, with themes and so on; however there are also plenty of other areas to improve if that's not here yet Feb 21 15:03:44 I think I've managed to build qtwayland 4.7 in the end but probably with some changes missing Feb 21 15:03:47 5.7 brings WideVine support for Netflix :P Feb 21 15:04:13 does it work OOTB with opensource version? Feb 21 15:04:36 I thought that you need some special keys for WideVine to make it really useful for us Feb 21 15:04:37 JaMa: I never got PepperFlash to work with 5.6 :P Feb 21 15:05:54 Somehow I doubt widevine support for netflix is a current high priority for LuneOS Feb 21 15:06:00 JaMa: and what is recipe specific sysroot (RSS), by the way ? Feb 21 15:06:47 http://lists.openembedded.org/pipermail/openembedded-architecture/2016-November/000336.html Feb 21 15:06:59 thanks :) Feb 21 15:11:38 GodGinrai: It's a nice to have :P Feb 21 15:11:55 But we could use a newer Chromium for all the new features they added Feb 21 15:12:04 And that comes with a newer QT version Feb 21 15:12:14 Chromium 45 is already getting a little old Feb 21 15:18:34 RSS is pretty impressive. And complex. I agree with the guy that implies that the next step could be having our own FUSE fs ;) Feb 21 15:21:15 Herrie|Pre3: meh. I'll be excited when you tell me LuneOS has been abstracted to support any rendering engine. LuneOS w/ Gecko would be pretty cool Feb 21 15:22:21 Gecko = pretty much dead :P Feb 21 15:22:42 But the SFOS run Gecko, shouldn't be too hard to get working if somebody wanted... Feb 21 15:22:58 Herrie|Pre3: wow wow wow, let's calm down :p Feb 21 15:23:28 Or, let's say, I won't work on that one ;) Feb 21 15:23:42 Tofe: pssh, you're no fun Feb 21 15:23:56 There's little wrong with Chromium imho. Mozilla's been dropping the ball in a lot of areas lately. Feb 21 15:24:13 Tofe: I was not referring to you for a change :P Feb 21 15:24:26 That's why I said "somebody" :P Feb 21 15:24:33 I won't deny that Mozilla has been dropping the ball a lot Feb 21 15:24:57 but honestly, allowing a rendering engine monopoly to exist is the worst thing that can happen Feb 21 15:25:09 we've already seen what it did to mobile thanks to the iphone Feb 21 15:25:26 GodGinrai: And IE before that on the desktop :P Feb 21 15:25:31 yup Feb 21 15:26:00 Agreed Feb 21 15:28:24 The SFOS guys got this working with QT so if somebody really wants it shouldn't be rocket science. But it would be a standalone browser app different from built-in browser. Feb 21 15:29:04 I don't think GodGinrai was referring to a standalone app Feb 21 15:29:59 Tofe is correct. I was referring to replacing the default rendering engine for LuneOS. Granted, a standalone app is still a good idea, just not what I was suggesting. Feb 21 15:30:09 Tofe: Well then it would be a LOT more work :P Feb 21 15:30:24 Basically, make LuneOS be able to do what Kazehakase used to do Feb 21 15:30:34 Which would be somewhere near the bottom of an imaginary to-do and wish list :P Feb 21 15:33:34 Herrie|Pre3: yes, quite a lot of work... and indeed it would mean: 1. having a working QML component with other engine (is SFOS one opensource?), 2. patch it to extend it for LuneOS, 3. fix all the missing pieces I forgot Feb 21 15:34:25 Tofe: A 3 step process? Great! I'll assign you the ticket :P Feb 21 15:34:38 meh! Feb 21 15:35:47 GodGinrai: but it's not impossible to do, though. Just a lot of work. If someone gets passionate about it, he'll succeed. Feb 21 16:22:37 I've removed the bits for Qt 5.7 and Qt 5.8 from meta-webos-ports/master and moved them to master-qt5.8 branch Feb 21 17:32:51 JaMa: here's the result of the pvr module build, with your changes: https://bpaste.net/show/dd9282b84d23 Feb 21 17:33:03 looks good to me, but maybe you want to have a look Feb 21 17:33:29 the pvrsrvkm-sgx540-module package is now almost empty, does that look correct to you? Feb 21 17:34:33 more user-friendly view: https://bpaste.net/show/44b632254399 Feb 21 17:35:05 I'm running the build as well (with master) Feb 21 17:35:23 looks good, but if you have runtime dependency on pvrsrvkm-sgx540-module then it should be updated to kernel-module-pvrsrvkm-sgx540-120 Feb 21 17:35:44 I don't :) Feb 21 17:35:50 otherwise we're installing useless empty package just for runtime dependency (on all splitted modules which in this case is just one) Feb 21 17:36:35 oh, wait, I included it in tuna.inc, I should remove it from here Feb 21 17:37:16 (I've put both pvrsrvkm-sgx540-module and kernel-module-pvrsrvkm-sgx540-120) Feb 21 17:39:20 only the later is needed Feb 21 17:39:27 I'll change it in my commit Feb 21 17:39:38 if it works for you then I'll push it to krogoth as well Feb 21 17:39:52 now I need to fix qemu-native and android-tools to build :/ Feb 21 17:49:16 JaMa: ok thanks Feb 21 19:18:12 Tofe: I need this for Hammerhead right? cm-12.1-20150901-SNAPSHOT-YOG4PAO237-hammerhead.zip Feb 21 19:18:40 Seems it appeared on AndroidFileHost with some mirrors ;) https://www.androidfilehost.com/?fid=457095661767137275 Feb 21 19:21:51 Herrie: mine was slightly different, let me see Feb 21 19:22:14 ah no, it's the same, good :) Feb 21 19:22:21 It would have worked anyway Feb 21 19:23:02 TofE: OK Feb 21 19:23:04 Herrie: I realize something for the camera binary that I should have realized from the beginning Feb 21 19:23:12 Let me flash Hammerhead image then Feb 21 19:23:41 the camera_service is intended to replace mediaserver, and also be run in the lxc container Feb 21 19:24:15 therefore, it is a bit of a nonsense to build it against the patched bionic source tree Feb 21 19:27:02 Or, wait, maybe it doesn't actually matter much, as the hybris linker isn't involved Feb 21 19:27:31 Have to think again about it :) Feb 21 19:31:14 Tofe: I'm not sure :P Feb 21 19:31:24 This is all too low level kernel & hardware for my mind :P Feb 21 19:48:22 Tofe: My Hammerhead works ;) Feb 21 19:48:35 Just not very happy with our ClockWorkMod steps on the Wiki so trying to tweak them a bit Feb 21 19:48:41 They're generic but not valid for all devices Feb 21 19:55:14 ah, yes, could be -- I haven't looked at it for a long time Feb 21 20:05:53 Tofe: Yeah will just add a link to XDA for each target + supported CWM version since ClockWorkMod site doesn't have them anymore Feb 21 20:09:05 Herrie: can't we also a copy of the recovery images on our site, just in case? I want to be cautious, with most of CM images not around here anymore :p Feb 21 20:09:11 +host Feb 21 20:09:59 Tofe: Yeah I guess we could Feb 21 20:10:00 We have space Feb 21 20:10:08 Just not sure about copyright & stuff Feb 21 20:10:50 ah right, I don't know either Feb 21 20:39:55 OK wiki is finally behaving Feb 21 20:40:00 THese templates are confusing at times Feb 21 21:07:21 OK release images are published ;) Just need to finish the article and some PR, been a bit hectic today :P Feb 21 21:54:25 :) great **** ENDING LOGGING AT Wed Feb 22 03:00:01 2017