**** BEGIN LOGGING AT Tue Sep 19 03:00:02 2017 Sep 19 06:30:29 Morning! Sep 19 06:30:56 Tofe: I've PR-ed updated Halium images build from Ports repos to meta-smartphone Sep 19 06:47:04 good Sep 19 07:35:29 Tofe: Had an initial look at the defconfig. Quite some changes actually. Seems the Halium one has quite some more options enabled. We only have a few they don't have it seems Sep 19 07:35:48 Good thing about the Halium kernel is that they have quite some stuff backported it seems from newer kernels Sep 19 07:37:02 Basically seems they have backported a lot of things from 3.5 to 4.2 ;) https://github.com/Halium/android_kernel_lge_hammerhead/tree/halium-5.1/backports Sep 19 07:38:01 Seems there are only a few flags that we have that they don't. Sep 19 07:49:26 In total we have 278 differences Sep 19 07:49:28 So quite some Sep 19 07:49:45 Though 41 are already for backports Sep 19 08:01:33 Herrie|Laptop: what flags do we have that they don't ? Sep 19 08:01:50 Tofe: Making a list Sep 19 08:01:58 ok thanks :) Sep 19 08:02:00 + their description ;) Sep 19 08:02:12 Doesn't look too trivial in general Sep 19 08:02:24 I guess we could try their kernel + our additional flags + patches to fix GCC Sep 19 08:02:40 Something like that Sep 19 08:03:06 Halium uses LXC too, but maybe older version of systemd Sep 19 08:06:12 They have the cgroup stuff Sep 19 08:08:37 I'm not really worried about what they activate, as our infrastructure is most likely more uptodate than theirs Sep 19 08:10:05 also.. if you have some additional changes upstream them if it makes sense <3 Sep 19 08:13:40 Morning! Sep 19 08:16:46 for curiosity I tried luneos-dev-emulator-qemux86.zip from last night on latest virtualbox - but it fails : no graphics Sep 19 08:19:45 bshah: well, yes, we have fixes for GCC 5 & 6 build Sep 19 08:20:02 MartinHov: morning! Sep 19 08:20:22 MartinHov: but it boots ? Sep 19 08:20:26 Tofe: I will be happy to merge them in Sep 19 08:20:45 I'll prepare the PR Sep 19 08:21:37 however, I don't think we recently tested the build with the good old android toolchain, I'll have to check that too Sep 19 08:22:15 or I can check once you PR ;) Sep 19 08:22:16 :p Sep 19 08:22:26 bshah: :) Sep 19 08:25:22 MartinHov: Yeah graphics still issues, however SSH/SCP should work again Sep 19 08:27:03 bshah: We're currently maintaining our own kernel due to the fact that we build with OE/Yocto with newer GCC Sep 19 08:27:16 If we could upstream and it doesn't break Android toolchain that would be great Sep 19 08:27:25 Saves maintaining kernel ourselves :P Sep 19 08:27:38 They're anyway largely identical I'd say Sep 19 08:28:18 best approch maybe would be to try halium kernel directly and see where it breaks Sep 19 08:29:53 Herrie: ok / thanks. then I wait for a next build that brings back the graphics to qemu Sep 19 08:30:12 MartinHov: We have some issues, it works with QT 5.8 but not with 5.9 again it seems :S Sep 19 08:30:24 bshah: We cannot due to the required GCC patches :P Sep 19 08:30:47 I'm comparing kernel configs now Sep 19 08:30:58 THere are quite some differences but nothing too shocking it seems Sep 19 08:32:04 Herrie|Laptop: that's the emulator stuff, isn't it ? Sep 19 08:32:48 Herrie|Laptop: we should just disable the build of that thing with a patch for qtbase Sep 19 08:43:04 Herrie|Laptop: thanks for explaining the QT issue. No worry - just continue your good work here. Sep 19 08:45:56 Tofe: Well even when it's not there it still doesn't really work probably Sep 19 10:07:46 JaMa: Qemux86 solved "itself" Sep 19 10:09:06 I did some cleanup jobs in Jenkins and then it build the bzImage again Sep 19 10:13:26 MartinHov: You might want to try to SSH/SCP into the VirtualBox, remove /usr/lib/qt5/plugins/egldeviceintegrations/ folder and then reboot VirtualBox Sep 19 10:13:33 For me that gives FirstUse now Sep 19 10:14:36 Herrie: thanks for the hints . Sep 19 10:15:37 MartinHov: I didn't have it working before, so might be random, but worth to give a try ;) Sep 19 10:33:20 Herrie|Laptop: it might be missing dependency on virtual/kernel.do_deploy somewhere Sep 19 10:33:44 Herrie|Laptop: or broken symlink when kernel is reused from sstate Sep 19 11:02:31 JaMa: I basically ran luneos-testing_workspace-cleanup Sep 19 11:03:50 JaMa for fixing qemu on 5.9 seems we need to disable building of https://github.com/qt/qtbase/blob/e4c39d5e1e7ee8c2bba273e6d613ec519b7fa9c2/src/plugins/platforms/eglfs/deviceintegration/eglfs_emu/eglfs_emu.pro Sep 19 11:03:54 In qtbase Sep 19 11:04:02 Not really sure how to do that? Sep 19 11:05:31 Herrie|Laptop: just commenting out https://github.com/qt/qtbase/blob/e4c39d5e1e7ee8c2bba273e6d613ec519b7fa9c2/src/plugins/platforms/eglfs/deviceintegration/deviceintegration.pro#L12 should do it Sep 19 11:06:33 Tofe: I think there should be a more elegant PACKAGECONFIG way in the qtbase .bbappend probably :P Sep 19 11:08:03 Herrie|Laptop: unfortunately, this subdir only depends on the "opengl" config, which we need to activate... So I don't see how a PACKAGECONFIG could solve that. Sep 19 11:09:32 Tofe: Maybe JaMa has some idea Sep 19 11:09:51 Tofe: On kernel for Hammerhead: These are things we have enabled, Halium hasn't: https://bpaste.net/show/4d73df2d2238 Sep 19 11:11:42 Tofe: Looking at https://github.com/qt/qtbase/commit/259adc5e77a40bc8f0b7e4c17f7a38bfc4ad511b I guess you're right ;) Sep 19 11:12:39 ah thanks ! Some of them are pretty surprising... Sep 19 11:12:52 CONFIG_DEVTMPFS_MOUNT we definitely need it Sep 19 11:13:12 Tofe: I will cross reference all these with Mako & Tenderloin Sep 19 11:13:21 Things we for sure need should be there too right ? Sep 19 11:13:34 right Sep 19 11:13:48 I think we need Inotify too Sep 19 11:13:53 and probably ACL Sep 19 11:15:27 Could be some just were inherited from our CM kernel for Hammerhead that are not strictly required Sep 19 11:15:36 inotify looks like a no brainer Sep 19 11:15:37 Herrie|Laptop: I'm still trying to upgrade mesa for qemux86 which might resolve this issue as well Sep 19 11:16:02 Tofe: I would expect things like mediaindexer to use it for example Sep 19 11:17:34 JaMa: but doesn't that mean you'd have to re-implement or re-import the fbegl output ? Sep 19 11:19:34 Tofe: I was hoping we'll find a way to use something else Sep 19 11:19:51 JaMa: like an egl fb renderer :p Sep 19 11:19:54 we cannot be the only one using mesa with qt Sep 19 11:20:12 so there should be alternative solution for that Sep 19 11:20:19 Right Sep 19 11:20:55 internally we're using newer mesa already + virglrenderer in qemu Sep 19 11:21:22 and the only issue I've noticed is that they needed to rework how qemu detects resolution for touchpad Sep 19 11:21:35 and they aren't using the touchpad plugin like we do Sep 19 11:23:17 well, using qemu could be a solution, yes; we could rewrite a touch plugin adapted for qemu, or something like that (usb-tablet didn't work on my computer when I tried) Sep 19 11:24:19 I'm not sure if qemu is actually the requirement Sep 19 11:24:36 vboxvideo should also provide some acceleration, but we're not using that Sep 19 11:24:39 only uvesafb Sep 19 11:24:58 and vboxvideo isn't as dead as it might seem as it was merged upstream recently Sep 19 11:25:21 JaMa: I know near to nothing about vboxvideo, I can browse a bit Sep 19 11:28:19 same here :) Sep 19 11:29:52 looks like it provides a Gallium/DRI driver, which might actually work with newer Mesa Sep 19 11:32:28 and unlike qemu we might get acceleration also with windows/mac hosts Sep 19 11:34:58 right, which is probably an important point Sep 19 11:36:01 I'll tinker a bit tonight: check the "3D Acceleration checkbox", disable uvesa, reintroduce vboxvideo... Sep 19 12:37:19 Tofe: Thnx Sep 19 12:37:32 Should I push this qtbase patch already or hold off for now? Sep 19 12:38:47 Herrie|Laptop: apart if JaMa sees a better idea, it should be fine to push it Sep 19 12:38:58 OK Sep 19 12:39:08 JaMa: Can you merge the meta-smartphone one? Sep 19 12:45:42 Herrie|Laptop: btw instead of this patch we can set QT_QPA_EGLFS_INTEGRATION=none Sep 19 12:47:45 nizovn: Can we? Sep 19 12:47:49 also setting QMLSCENE_DEVICE=softwarecontext may help on emu (it won't use mesa opengl i think) Sep 19 12:48:20 Herrie|Laptop: i think yes, i had the same issue when using qupzilla with eglfs plugin Sep 19 12:49:57 nizovn: Luneos != legacy webOS but worth a try ;) Sep 19 12:57:42 nizovn: we want Mesa, but the QT_QPA variable is a damn good idea :) Sep 19 12:58:07 nizovn: QT_QPA_EGLFS_INTEGRATION=none works :) Sep 19 12:58:19 Let me PR that Sep 19 12:58:43 Herrie|Laptop: you put it in environment.conf right? Sep 19 12:58:49 We'd still need something in longer run right? For newer Mesa Sep 19 12:58:52 Tofe: yup Sep 19 12:59:05 Just SCP-ed it over and rebooted Sep 19 12:59:16 Herrie|Laptop: for newer Mesa, I don't know yet Sep 19 12:59:29 But for now this should work Sep 19 13:00:51 yep Sep 19 13:02:04 Tofe: https://github.com/webOS-ports/meta-webos-ports/commit/ada3315b836fb4896637a1355c262b1cf8fca5ac Sep 19 13:02:21 Let's see if this brings back qemux86-64 too :P Sep 19 13:02:30 But I'll test that after a new build Sep 19 13:02:40 lgtm Sep 19 13:03:14 Kernel defconfig for Mako & Tenderloin show some surprises too :P Sep 19 13:03:20 Still working on comparison Sep 19 13:15:05 that's very possible; generally we stop touching it when it works well :p Sep 19 13:15:34 Tofe: You've seen https://archon-runtime.github.io/ ? Sep 19 13:15:40 Might be interesting ... ? Sep 19 13:15:58 nope, didn't see :) Sep 19 13:16:10 Not Chromium, though ? Sep 19 13:18:43 Ah seems pretty dead Sep 19 13:18:48 Latest update 2015 Sep 19 13:18:57 Anbox might be more interesting then Sep 19 13:19:49 Herrie|Laptop: yes, it looks more promising Sep 19 13:22:45 though I think we should somehow repackage it as an ipk, that'll be more simple than bringing the whole snap stuff in LuneOS Sep 19 13:23:01 but I may be wrong, I don't know this project well Sep 19 13:28:31 Herrie|Laptop: sorry was busy with other stuff, merging it now Sep 19 13:53:36 JaMa: Thnx Sep 19 13:56:09 OK new builds running Sep 19 14:03:03 gosh, why do guys answer in a 2-years-old thread on webnation ? :) Sep 19 14:23:12 Tofe: No clue :P Sep 19 14:26:11 JaMa: I noticed that the jenkins jobs workflow doesn't do auto rsync and cleanup anymore like before Sep 19 14:26:22 Is that due to the new plugin? Sep 19 14:28:40 checking Sep 19 14:29:36 luneos-testing_build-all-machines isn't using workflow Sep 19 14:31:08 JaMa: Yeah thats the one I use Sep 19 14:31:13 Should I be using something else? Sep 19 14:31:33 luneos-testing_build-supported-machines also doesn't use it Sep 19 14:31:51 Yeah these used before Sep 19 14:31:55 and neither of them seem to do rsync and cleanup even when looking on older version of them Sep 19 14:32:07 JaMa: Well they did before, I'm 100% sure :P Sep 19 14:33:08 Cleanup & rsync Sep 19 14:33:13 I never had to do those manually before Sep 19 14:36:53 should it call luneos-testing_update-manifest as well? Sep 19 14:38:30 I've created luneos-testing_build-all pipeline to replace it Sep 19 14:38:35 JaMa: Tbh I don't remember what it's being used for Sep 19 14:39:32 http://jenkins.nas-admin.org/view/luneos-testing/job/luneos-testing_build-all-machines/jobConfigHistory/ doesn't show anything about rsync or cleanup Sep 19 14:39:52 maybe it was added as after-build job for one of removed jobs like maguro Sep 19 14:41:03 Started by upstream project "luneos-stable_build" build number 34 Sep 19 14:41:03 originally caused by: Sep 19 14:41:03 Started by user herrie Sep 19 14:41:14 there was some different job before, maybe you were using that one? Sep 19 14:41:51 similarly e.g. http://jenkins.nas-admin.org/view/luneos-testing/job/luneos-testing_workspace-rsync/787/consoleFull Sep 19 14:41:58 Started by upstream project "luneos-testing_build" build number 379 Sep 19 14:41:58 originally caused by: Sep 19 14:41:59 Started by user herrie Sep 19 14:42:22 but there is no luneos-testing_build now... that might be the one which was using WorkFlow Sep 19 14:51:12 I'll also redirect luneos-unstable jobs to bonaire now as it has more disk space now and tahiti doesn't seem to be returning any time soon Sep 19 15:41:01 JaMa: Thnx Sep 19 15:54:40 FYI: I just grabed the latest (very recent) qemux86 testing bits. And these do not boot for me in virtualbox. .. Sep 19 16:27:40 MartinHov: Stuck @ boot menu? I guess same problem like last time. Will be fixed with next build. Sep 19 16:33:57 Herrie|Laptop: any idea what happened with luneos-testing_build-all? I've created it 2 hours ago and it's gone now Sep 19 16:35:01 2017-09-19_16-04-14luneos-testing_build-all_deleted_20170919_160414_392Deletedherrie Sep 19 16:35:09 http://jenkins.nas-admin.org/jobConfigHistory/?filter=deleted Sep 19 16:35:12 why did you delete it? Sep 19 16:36:22 16:40:59 <+JaMa> I've created luneos-testing_build-all pipeline to replace it Sep 19 16:38:45 and did you cancel all queued jobs as well? Sep 19 16:51:38 JaMa: Sorry was in a hurry and deleted it by mistake. I'll fix it when back. Relaunched the unstable Sep 19 17:06:59 Before I got out for dinner. Sep 19 17:09:00 Herrie: Yes - qemux86 stuck in boot menu (loops for ever). The same with qemux86-64 which I just tried too. I just wait for the next set of builds. Sep 19 17:21:19 Herrie|Pre3: ok, I've restored it now Sep 19 17:21:25 JaMa: Long story short, wanted to have testing rsync before unstable would build like forever :P So cancelled unstable, ran rsync. Wanted to start new testing with workflow but pressed wrong buttons :s I kicked off unstable again before leaving home. Sep 19 17:21:39 Sorry for that. Sep 19 17:22:19 But seems because the build that was running didn't do a clean workspace qemux86(-64) had missing bzImage again. With workflow should be OK I guess Sep 19 17:26:19 it's running now (testing) Sep 19 17:33:48 JaMa: Thnx Sep 19 18:49:41 JaMa: what was the problem with vboxvideo, again? Sep 19 18:50:17 if we add "video=1024x768" to the kernel options, it works pretty well (with old Mesa at least) Sep 19 19:00:27 Tofe: conflict with uvesafb Sep 19 19:00:56 Tofe: if vboxvideo initialized the fb first, then uvesafb failed to initialize and the selected resolution wasn't used Sep 19 19:01:04 JaMa: yes, I disabled uvesafb, agreed :) Sep 19 19:01:11 sometimes creating fbdev for both Sep 19 19:01:23 s/creating/breaking/ Sep 19 19:01:40 but I mean vboxvideo seems to work quite as well as uvesafb Sep 19 19:02:00 Herrie|Laptop: I'll submit couple fixes for http://jenkins.nas-admin.org/view/luneos-testing/job/luneos-testing_workspace-compare-signatures/11/console please check them, bunch of them were caused by your fixes for QA issues (adding bash to RDEPENDS) Sep 19 19:02:24 Tofe: yes, it might work at least as good Sep 19 19:02:47 JaMa: with newer mesa, we have a Gallium pipe by default, maybe ? Sep 19 19:04:15 Tofe: 2_17.1.7-r0/temp/log.do_configure http://bpaste.net/show/5223214a7b4d Sep 19 19:04:35 not by default Sep 19 19:04:41 this is from qemux86-64 build with master Sep 19 19:05:34 ok, but we have dri2, so maybe it could work Sep 19 19:06:30 on my end I have "[drm] Initialized vboxvideo 1.0.0 20130823 for 0000:00:02.0 on minor 0", though no reference to DRI **** ENDING LOGGING AT Wed Sep 20 03:00:02 2017