[11:29] <Mirv> could I get a pre-ack for my qtbase sync from Debian (to wily) that adds a new binary package libqt5libqgtk2 for an existing file? see the first 1/5 of https://ci-train.ubuntu.com/job/ubuntu-landing-019-1-build/lastSuccessfulBuild/artifact/qtbase-opensource-src_packaging_changes.diff
[11:30] <Mirv> that drops GTK2 requirement from Qt 5 which we also want
[11:31] <Mirv> so that it's recommended only
[11:43] <mitya57> Mirv: unrelated to the NEW package, just FYI: the two patches you disabled can be still useful in case someone compiles an app using gcc5 against a gcc4-compiled Qt.
[11:43] <mitya57> was the case in i.e. debian #783127
[11:47] <mitya57> Also, it will be really nice to have a list of Ubuntu delta :)
[11:59] <Mirv> mitya57: oh, right
[12:02] <doko__> mitya57, Mirv, which are these gcc/4/gcc5 patches?
[12:03] <Mirv> doko__: require_fpic_instead_of_fpie.patch + make_qglobal_h_complain_if_you_use_fpie.patch
[12:03] <Mirv> in that url above
[12:03] <Mirv> my thinking was to wait for gcc5 to be default in Ubuntu, then enable those, remove that one ubuntu-only patch and add back reduce-relocations to Qt config
[12:04] <mitya57> http://code.qt.io/cgit/qt/qtbase.git/commit/?id=36d6eb721e7d5997ade75e289d4088dc48678d0d, http://code.qt.io/cgit/qt/qtbase.git/commit/?id=3eca75de67b3fd2c890715b30c7899cebc096fe9
[12:04] <mitya57> Those links have some clickable links to bugreports and discussions
[12:05] <doko__> ahh, thanks
[14:53] <slangasek> wgrant, infinity: so I have XS-Build-Indep-Architecture: amd64 set in the edk2 source, but this happened. https://launchpad.net/ubuntu/+source/edk2/0~20150106.5c2d456b-1
[14:54] <slangasek> wgrant, infinity: looks like LP isn't honoring it correctly, can we get that fixed?
[15:36] <infinity> slangasek: Ahh, that's probably hitting a corner case in the parser, because you have no amd64 binaries.  Seems like it should be fixable.
[15:38]  * infinity files a bug.
[20:16] <wgrant> slangasek: That's because gina doesn't import custom fields like Build-Indep-Architecture. That's a bug, but it'll work fine if you upload directly to anywhere in LP.
[20:16] <slangasek> wgrant: ok, thanks
[20:34] <slangasek> wgrant: well, now I get https://launchpad.net/ubuntu/+source/edk2/0~20150106.5c2d456b-1build1/+build/7441990 instead :)
[20:40] <wgrant> slangasek: Does modern sbuild cope with that case?
[21:00] <slangasek> wgrant: good question, I haven't tested that and it wouldn't have gone through sbuild for the Debian upload.  I'll give it a spin
[21:25] <wgrant> slangasek: If it works (or if it doesn't, but is easily fixable), the sbuild upgrade is ready from the LP end. Just waiting on scalingstack to be unbroken enough that we can do a test rebuild with it.
[23:21] <slangasek> wgrant: yeah looks like current sbuild doesn't cope either
[23:21] <slangasek> (wily)
[23:23] <wgrant> slangasek: Looking at the code in wily, it looks like -A should make it work.
[23:24] <wgrant>         if ($dscarchs ne "any" && !($valid_arch) &&
[23:24] <wgrant>             !($dscarchs =~ /\ball\b/ && $self->get_conf('BUILD_ARCH_ALL')) )  {
[23:24] <wgrant> So if -A is set and there's an all token in Architecture it is meant to permit it.
[23:28] <wgrant> Seems to work.
[23:28] <wgrant> So we just need the sbuild upgrade.
[23:30] <slangasek> oh?  didn't work here with the wily sbuild, not sure what I was doing wrong then
[23:31] <wgrant> You sure you gave it -A?
[23:31] <slangasek> yes
[23:31] <slangasek> oh it actually didn't fail out with skipping architecture
[23:32] <slangasek> so I just have some other problem with my sbuild setup
[23:32] <wgrant> Yeah
[23:32] <wgrant> Mine failed for other reasons too.
[23:32] <wgrant> Specifically, that my home directory went away because lol.
[23:32] <wgrant> But it failed after the arch check.