[06:14] <pitti> stgraber: that worked fine, thanks
[07:44] <tsimonq2> o/ pitti, how are you? :)
[08:09] <tjaalton> did someone use MST with intel? I hear unity doesn't work right with it
[08:24] <brendand> there seems to be an issue with qemu-img on yakkety - is anyone aware of this: http://paste.ubuntu.com/19876087/
[08:25] <brendand> ah wait - maybe i don't have that image created#
[08:33] <brendand> yeah, nm
[09:45] <mwhudson> ogra_: aaaaaaaaaaaaaaaaaaaaa
[09:45] <mwhudson> ogra_: at least some of my problems were because i wasn't running snapcraft to make ubuntu-core as root
[09:53] <infinity> tinoco: Was anyone ever going to verify the SRUs for LP: #1529815 ?
[10:21] <Odd_Bloke> infinity: You were going to upgrade the kernel on the one powerpc builder that was still old (sagari?).  Has that happened?
[10:23] <infinity> Odd_Bloke: Nein.
[10:25] <Odd_Bloke> infinity: Ack; I'll leave our workaround in place then. :p
[11:43] <ogra_> mwhudson, ah, ouch ...
[12:03] <juliank> The python-apt uploaded triggered some regressions in ubuntu-make and click autopkgtests, but did not seem to cause them, AFAICT.
[12:03]  * juliank is not sure what exactly is going on and does not have the time to investigate that
[12:23] <Mirv> xnox: hi! any ideas about s390x https://launchpadlibrarian.net/273695893/buildlog_ubuntu-yakkety-s390x.qtbase-opensource-src_5.6.1+dfsg-3ubuntu1~1_BUILDING.txt.gz ? (search for "alignment 128")
[12:30] <xnox> Mirv, how is Q_DECL_ALIGN actually implemented? with c++ alignas stuff?
[12:33] <Mirv> xnox: lots of lots of ifdef, but yes maybe http://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/global/qcompilerdetection.h?h=5.6.1
[12:33] <Mirv> if __has_feature(cxx_alignas) -> yes
[12:33] <xnox> Mirv, smells like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70066 to me
[12:34] <Mirv> xnox: as a data point it did compile on Debian
[12:36] <xnox> Mirv, fails on armhf too with same error so not s390x specific
[12:37] <xnox> Mirv, reading the bug report... setting "CXX=c++" might change behaviour and succeed.
[12:37] <xnox> Mirv, would be interesting to see if it builds in debian experimental with gcc6
[12:37] <xnox> worth opening a bug report on launchpad about it, and then start forwarding to qt upstream and gcc upstream.
[12:38] <xnox> doko is still away i'm gueesing?!
[12:38] <xnox> or could you look into ^
[12:38]  * xnox ponders to create minimal example from above
[13:19] <Mirv> xnox: thanks for looking into it! it did fail similarly on xenial too. and it did succeed in debian experimental before it was uploaded to unstable. bug #1603991
[13:52] <michael-vb> sladen, mitya57: https://bugs.launchpad.net/ubuntu/+source/libdbusmenu-qt/+bug/1604009
[17:37] <nacc> slangasek: fyi, i think jquery-goodies is stuck in yakket-proposed becuse it was mismerged (the build-dep on yui-compressor was dropped, but the rules change to use it wasn't). In any case, I just filed a sync request (LP: #1604095)
[17:40] <slangasek> nacc: hmm, I noticed the build failure but didn't think it was a mismerge, I would've expected my merge process to catch that.  If the new version has the PHP7 compat fix, I'll happily sync that and wash my hands of it ;)
[17:47] <nacc> slangasek: it seems like the change from "  * Use yui-compressor instead of uglifyjs (universe)." was only half-carried forward (specifically not s/node-uglify/yui-compressor/ in debian/control. But yeah, the sync will just fix it fine
[18:23] <tinoco> infinity: i'll verify #1529815 by the end of this week. will reprovision the IB lab so I can make sure its good.
[18:29] <slangasek> tinoco: note that "By the end of this week" means it will miss 16.04.1; the point release is this week, and image mastering is happening ASAP for validation for a Thursday release
[18:30] <slangasek> tinoco: so there's probably no possibility of it being done in time for 16.04.1 if there's lab reprovisioning required first - just want to make sure you understood (and 16.04.1 was the reason for infinity's ping)
[18:31] <sarnold> tinoco: hmm, pitti mentioned a verification-failed on a different bug, which appeared to get an automated validation-failed tag by a bot... my instinct is that the filed bug has nothing to do with the apparmor profile fiddling
[18:32] <tinoco> sarnold: i think both SRUs were together and the other one failed, right ?
[18:32] <sarnold> tinoco: .. the error in the log is "invoke-rc.d: initscript isc-dhcp-server, action "start" failed." but the apparmor profile that was modified was for /sbin/dhclient
[18:32] <sarnold> tinoco: "failed" in that some random guy filed a bug with that version number
[18:32] <sarnold> tinoco: not in the sense of "I tested it and it didn't fix my problem"
[18:33] <tinoco> oo damn
[18:35] <tinoco> so whats the best move here ?
[18:35] <tinoco> i can verify 1529815 by tomorrow
[18:36] <tinoco> just asked for IB machines and I was given access to 2 (which i can use to verify this)
[18:40] <sarnold> tinoco: bdmurray already removed the verification-failed flag from 1568485 and added bot-stop-nagging to 1574226 ... I don't know if The Process would still allow 1529815 through but I think pitti's reason for rejecting it a month ago wasn't correct
[18:41] <tinoco> yep.. if it allows i can verify lp1529815 by tomorrow
[18:41] <tinoco> if not, i can propose a new patch for trusty and we can re-start sru
[19:02] <rbasak> !dmb-ping
[19:38] <infinity> tinoco: So, worth noting that version of dhclient is already built into d-i, because it was built with -proposed on...
[19:38] <infinity> tinoco: Would likely be ideal to get your verification done ASAP tomorrow and I can respin images to match.
[19:39] <infinity> tinoco: (Just xenial is all I care about right now)
[19:49] <tinoco> infinity: will do first thing tomorrow. will ping you when done. tku!!
[19:50] <infinity> tinoco: Ta.
[21:32] <infinity> roaksoax: If you want that maas fix on 16.04.1 media, verify the bug ASAP once it's built.
[22:50] <roaksoax> infinity: verified
[23:01] <slangasek> roaksoax: thanks, I'll publish it shortly