[02:08] <duflu> RAOF: Is the other IRC server down?
[02:08] <RAOF> I was just about to ask.
[02:08] <RAOF> I think the answer is yes :)
[02:09] <RAOF> I noticed IS was fiddling with firewalls recently. They may not have been as successful as they hoped :)
[05:56] <alf_> duflu: Hi! Just FYI there was no need to explicitly add a new changelog entry for 0.24 no change rebuild, ci-train automatically adds one using the MP commit message. Plus now we need to rebuild the silo...
[05:58] <alf_> RAOF: duflu: internal IRC is back on-line
[06:36] <duflu> alf_: Never mind. Only need to learn that once. I'm still concerned about the assertion that changing headers in order to product different binaries is "no change"
[06:37] <alf_> duflu: no change doesn't mean no test
[06:37] <duflu> alf_: No but it does mean the binaries are changing. That's the point. So it carries risk still
[06:37] <RAOF> “no change rebuild” is the term of art used in distro.
[06:39] <alf_> duflu: RAOF: Plus something changes in the binary output of the process otherwise we wouldn't need the rebuild. The "no change" is just for our source, and people are familiar with the implications I think
[06:40] <duflu> It's sufficiently risky and insufficiently expressed that it's worth mentioning, and now we have...
[06:40] <RAOF> That reminds me. We should check if the Mir build is reproducible...
[06:40] <duflu> RAOF: I've been doing that for the past day and this morning. Final workaround landing soon
[06:41] <duflu> Oh, you mean something different
[06:41] <duflu> Yeah that too
[06:41] <RAOF> duflu: Sorry, another term of art. By “reproducible” I mean “produces binary identical output each build”.
[06:54]  * duflu always assumes there is entropy instead of such proof that there shouldn't be...
[06:54] <duflu> Cosmic rays...
[06:57] <duflu> alf_: It should also be mentioned to the powers that be that such non-ABI breaking changes shouldn't need be in a silo. We have proposed for that.
[07:40] <duflu> Hmm, 1 hour for CI and an additional 2+ hours for autolanding?
[07:40] <duflu> Is something new broken?
[07:42] <RAOF> Or just oversubscribed?
[07:59] <duflu> RAOF: Yep. And guess what? CI now passes but autolanding fails for new reasons
[07:59] <RAOF> Huzzah!
[07:59] <duflu> So what's different about autolanding's build environment?
[08:00] <duflu> Different to CI
[08:28] <duflu> alf_: Any idea why autolanding would fail to build but CI passes?... https://bugs.launchpad.net/mir/+bug/1616291
[08:30] <duflu> Google says that error is a depenendcy on some lib built with a different C++ compiler/version
[08:30] <alf_> duflu: one main difference between autolanding and CI is LTO
[08:30] <duflu> Hmm
[08:32] <alf_> duflu: but also optimizations in general
[08:32] <alf_> duflu: CI builds are built with 'noopt' debflag
[08:32] <duflu> alf_: Cool. So plausible reasons exist. Unfortunately we're at a stage where CI is passing and only autolanding fails
[08:32] <duflu> .. to build
[09:10] <bneo99> getting error when doing mir_proving_server --hwc-report log
[09:10] <bneo99> http://pastebin.com/HCZSLSG3
[09:11] <bneo99> logcat http://pastebin.com/nibGtxV2
[09:15] <duflu> bneo99: You might have to wait for kdub to come online (USA central time?)
[09:15] <bneo99> ok
[09:55] <sil2100> Hey!
[09:55] <sil2100> duflu, alf_: https://requests.ci-train.ubuntu.com/#/ticket/1846 <- this doesn't look to be needed
[09:56] <sil2100> I poked here about a manual no-change rebuild already, no need to do the same twice ;)
[09:56] <sil2100> (especially that we only needed a rebuild on xenial)
[09:56] <sil2100> duflu, alf_: are there other reasons for this no-change rebuild?
[10:06] <duflu> sil2100: Sorry, preparing food :) ... Yeah we don't need any more builds than you need
[10:07] <duflu> sil2100: I just thought some accuracy in changelogs would be nice. Our robots always do a terrible job of writing documentation
[10:08] <duflu> And back to the kitchen
[10:24] <alf_> sil2100: Was the xenial upload to rebuild with the updated android-headers?
[10:53] <sil2100> alf_: yes
[10:54] <sil2100> alf_: a no change rebuild here: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+sourcepub/6828563/+listing-archive-extra
[10:55] <alf_> sil2100: thanks, had a chat with vicamo (in phablet channel) and have abandoned the silo
[10:55] <greyback> alan_g: would you mind giving this a quick glance, just to fully sign it off: https://code.launchpad.net/~gerboland/qtmir/use-mir-test-dev/+merge/303537 (build issue fixed)
[10:56] <alan_g> greyback: sure
[10:56] <greyback> thanks
[11:30] <bneo99> @kdub getting error when doing mir_proving_server --hwc-report log
[11:30] <bneo99> http://pastebin.com/HCZSLSG3
[11:30] <bneo99> logcat http://pastebin.com/nibGtxV2
[11:37] <kdub> i'd guess "E/ti_hwc  (    0): Post2 error" means that the fb module posting is perhaps returning an error rc
[11:47] <bneo99> how about the egl errors before
[11:47] <bneo99> E/libEGL  (    0): validate_display:262 error 3008 (EGL_BAD_DISPLAY)
[11:56] <kdub> eh, yeah, might be a pixel format selection problem perhaps
[12:10] <greyback> alan_g: a warning in case you hit it: some Qt apps like to create one or several transparent 640x480 surfaces under the main window
[12:10]  * greyback discovered the reason why his window raise stuff wasn't working with some Qt apps
[12:58] <alan_g> greyback: that's just weird
[12:58] <anpok> greyback: qtubuntu question - If I need a mir connection inside a qt plugin..
[12:59] <anpok> but there is not QGuiApllication yet..
[12:59] <anpok> or might never have one..
[12:59] <greyback> alan_g: yep. I had the misfortune to choose QT_QPA_PLATFORM=ubuntumirclient /usr/lib/x86_64-linux-gnu/qt5/examples/widgets/mainwindows/application/application as a test Qt app (from qtbase5-examples)
[13:00] <alan_g> better to find these corners now than later
[13:02] <greyback> anpok: good question, am reading code to see
[13:04] <anpok> hm I do wonder if thats a valid scenario.. stumbled over that issue in the qtsysteminfo plugin
[13:12] <greyback> afaics qt only loads the platform plugin for a QGuiApplication
[13:12] <greyback> as the assumption was only GUI apps would want to talk to mir
[13:12] <greyback> ofc you can create a QGuiApp, and just not create a qwindow
[13:12] <greyback> so it can be command line, but still have a mir connection
[13:33] <anpok> greyback: and not pass any argc/argv to it... is this a bad thing for a plugin to do *conditionally*?
[13:34] <greyback> anpok: please rephrase, I'm not following you
[13:36] <anpok> greyback: creating a QGuiApplication object to obtain a nativeinterface/MirConnection when none is available because the calling application is not a gui application
[13:37] <anpok> or better fail.. in a friendly way.
[13:38] <greyback> anpok: plugin should not create QApplication instance, just to get the mir connection
[13:39] <greyback> unfortunately Qt not really designed to do what you ask, talking to mir without having a GUI isn't a typical use-case for an app author
[13:39] <greyback> you'll have to create the mir connection yourself
[14:40] <TheKit> is there any test that would use OpenGL ES on Android to render to buffer instead of HWC backend?
[14:43] <TheKit> mir_android_diagnostics --gtest_filter="AndroidMirDiagnostics.client_can_draw_with_gpu" should be this one according to the description
[14:46] <kdub> TheKit, yes, that should be one
[14:47] <kdub> the thing is, you have to go with HWC to post to framebuffer with OpenGL on hwc 1.1 or later