[02:37] <darkxst> can we get gnome-shell unblocked?
[02:38] <darkxst> For Bug 1284496
[02:38] <ubot2> Launchpad bug 1284496 in casper (Ubuntu) "Booting the Ubuntu GNOME live DE from the advanced boot menu results in a largely unusable DE" [Low,Confirmed] https://launchpad.net/bugs/1284496
[02:47] <stgraber> sure, I'll let it through
[02:52] <infinity> Unfortunately stuck behind a security update of doom on powerpc.
[02:53] <infinity> Scored it up to see if it can get lucky.
[03:02] <darkxst> thanks guys
[03:39] <jdstrand> infinity: if you want to kill the powerpc build on say saucy or quantal, feel free and we/I can restart it later
[03:40]  * jdstrand drifts off
[03:40] <jdstrand> (I'll check on it later)
[03:49] <infinity> jdstrand: Shouldn't be necessary.  Got gnome-shell built.
[09:18] <seb128> would it be possible to unblock indicator-datetime if there there are respins planned (not sure on what basis we unblock things nowadays ;-)
[09:18] <seb128> the update fixes some segfault issues which are not hitting quite some users
[09:21] <infinity> seb128: Mostly up to stgraber.
[09:22] <Laney> infinity: have you seen http://people.canonical.com/~ubuntu-archive/livefs-build-logs/trusty/ubuntu-server-omap4/latest/livecd-armhf.out ?
[09:22] <Laney> Looks like component-mismatches to me
[09:22] <infinity> Laney: No.  server-omap4 and server-omap just need love (or dropping) in general.
[09:23] <infinity> Laney: I need to see if anyone's actually still using those images (QA might be), and then decide which route to take.
[09:23] <Laney> I hear that
[09:23] <Laney> Every day I get a mail for the build failure. :)
[09:23] <infinity> Serves you right for signing up for livefs build failures. :)
[09:24] <Laney> It's often stuff that's fixable for me
[09:26] <Laney> But yeah. Trying to build images over and over which aren't going to work seems less than ideal.
[09:28] <infinity> Feel free to uncron them for now to reduce the noise.
[09:28] <infinity> But I need to either fix or drop them, this was a post-FF TODO item for me.
[09:47] <ogra> infinity, is there any chance we could get the pulseaudio from proposed into the archive (i need to build a new touch image and it fixes a CPU hog that makes a test fail)
[09:48] <ogra> (afaik trsalveti and diwic tested the binary on phone and desktop)
[09:49] <infinity> ogra: That's up to stgraber and the flavours doing beta.
[09:50] <ogra> ah, i thought you both do it
[09:50] <ogra> sorry then
[09:50] <infinity> Nah, I'm staying away from alphas and betas I'm not signed up for.
[09:50] <ogra> right, i'll just do a build without the fix then
[10:52] <xnox> Laney: hm. d-i components should always be frozen at milestones. I thought grub-installer was frozen, but it wasn't.
[11:07] <Laney> xnox: hmm, I guess
[11:07] <Laney> patches to generate-freeze-block welcome :)
[11:13] <Laney> can someone look at the trusty-proposed NBS packages from dolfin on arm64 please?
[11:13] <infinity> Laney: Sure.
[11:14] <infinity> Err, why only arm64, I wonder?
[11:15] <infinity> Weird.  Maybe it never migrated.
[11:15] <infinity> Removing the NBS.
[11:15] <Laney> Yeah, dunno
[11:15] <Laney> ta
[11:15] <infinity> Fixed.
[11:17] <seb128> infinity, do you know about "out of date on ppc64el: empathy, empathy-dbg, mcp-account-manager-goa, nautilus-sendto-empathy (from 3.8.6-0ubuntu4) "? where https://launchpad.net/ubuntu/+source/empathy/3.8.6-0ubuntu4 is not having a ppc64el build?
[11:17] <seb128> infinity, (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#empathy)
[11:19] <infinity> seb128: It's out of date because it's out of date...
[11:19] <infinity> It used to build before its rdeps disappeared.
[11:19] <infinity> (In the previous archive, before the rebuild)
[11:19] <seb128> infinity, well, 3.8.6-0ubuntu4 had the same issue, how can it be a regression in the new revision?
[11:19] <infinity> seb128: I'll fix that up tomorrow.
[11:19] <seb128> infinity, thanks
[11:20] <infinity> Or, later today.
[11:20] <infinity> seb128: Also, I was going to yell at you for some recent upload with arch restrictions instead of build-dep hacks...
[11:20] <infinity> Which one was that?
[11:21] <Laney> https://lists.ubuntu.com/archives/trusty-changes/2014-February/010640.html
[11:21] <infinity> Oh, right, gnome-control-center-signon
[11:21] <seb128> I hate that package
[11:21] <infinity> "arm64 used to build but doesn't have qt5", that was the whole POINT of the build-dep hack.
[11:21] <seb128> shrug
[11:21] <infinity> To make it stop building on arches where it would subsequently be uninstallable.
[11:22] <seb128> well, that creates issue that I don't know how to resolve
[11:22] <infinity> Anyhow, most of this faff should go away (I hope) with qt5.2, we really need to get that in soon.
[11:22] <seb128> e.g britney was unhappy about empathy depending on libaccount-plugin-1.0-0 on arm64
[11:22] <seb128> that wouldn't exist anymore
[11:22] <infinity> And we can stop having half our desktop arch-restricted.
[11:22] <Laney> I saw some requests for QA reports and all sorts of stuff for Qt 5.2 earlier on
[11:22] <seb128> right
[11:22] <Laney> So I'm not sure if that is close...
[11:23] <infinity> seb128: Right, empathy's deps there either should be arch-restricted, or it should just not exist on those arches (like it doesn't on ppc64el).
[11:23] <seb128> Laney, Pat started pushing thing yesterday, let's see what happens next
[11:23] <seb128> Laney, (I hinted that they might miss trusty if they don't start making progresses soon)
[11:23] <infinity> Laney: We all need to push to make it closer, IMO.  Anything anyone can do to help them fix things up.
[11:24] <seb128> infinity, right, so I should have deleted the empathy arm64 old binaries?
[11:24] <seb128> infinity, and I think empathy is not alone
[11:24] <seb128> tracking those issues down seems a waste, we just need to land qt5.2 as you said
[11:24] <seb128> meanwhile the g-c-c-signon arch restriction is the cheap and easy workaround
[11:24] <Laney> Pushing good, shifting sands bad
[11:26] <infinity> seb128: We get to rebuild all the qt5 rdeps for the armhf ABI break anyway, so that'd be a good time for people to go through and drop all the arch restrictions at the same time and see how well the new world order works.
[11:26] <infinity> seb128: Maybe I should try this in a PPA with PPC and arm64 enabled and see how bad/good the situation is.
[11:27] <seb128> right
[16:01] <mapreri> Can you unblock qemu? it's mainly for bug #1284344
[16:01] <ubot2> Launchpad bug 1284344 in qemu (Ubuntu) "qemu-user-aarch64: dns is broken" [High,Confirmed] https://launchpad.net/bugs/1284344
[16:07] <ogra> stgraber, any chance that we can get the pulseaudio fix in ? i belive diwic and rsalveti tested on phone and desktop before uploading
[16:12] <stgraber> qemu and pulseaudio unblocked
[16:12]  * ogra hugs stgraber 
[16:27] <mapreri> thanks stgraber :)
[16:33] <seb128> stgraber, what are the current rules/can we get packages in or does that mean respinning isos if we do? the indicator-datetime update in proposed fixes some common segfault
[16:33] <seb128> stgraber, unity-control-center has some changes that would be nice to push to users so they test that new version, but if that's after beta it's not the end of the world
[16:33] <seb128> stgraber, having unity in could be nice as well, since that enable the scaling option for HiDPI
[16:33] <Laney> haha
[16:34] <seb128> Laney, what? ;-)
[16:34] <stgraber> seb128: it doesn't mean respinning ISOs but it means that if anything breaks as a result of me letting the package in, I'll be very very unhappy ;)
[16:35] <seb128> stgraber, don't worry, it's only good code :p
[16:35] <stgraber> I'll look at indicator-datetime, the rest sounds like it can wait until after we lift the freeze
[16:35]  * seb128 crosses finger there are no bugs
[16:35] <seb128> stgraber, fair enough, thanks
[16:36] <Laney> seb128: I just found listing all your uploads funny :P
[16:36] <seb128> Laney, "all", it was just a nicely selected set :p
[16:37] <Laney> stgraber: I think everyone's been staying away from unblocking stuff in 'your' beta, but that seems like a quite conservative approach... would you have minded if others did some unblocks?
[16:37] <Laney> I'd have considered pulseaudio and datetime
[16:37] <seb128> it's a bit of a shame that we beta test an unity version which doesn't include HiDPI, that testing is not as useful as it could be, but I guess it's the unity's team fault for not landing it before the freeze
[16:38] <stgraber> Laney: I don't mind other members unblocking things so long as they actually look at the diffs and are 99.9% sure this won't cause changes/regressions
[16:40] <Laney> nod, that'd be my approach
[16:40] <Laney> cheers
[16:52] <xnox> seb128: ubuntu is not in a beta test, kylin/edubuntu are. Not sure it's nice to beta test unity in kylin/edubuntu milestones without ubuntu also participating.
[16:52] <xnox> seb128: it would make more sense to "let new unity in, and respin ubuntu-desktop".
[16:53] <Riddell> Laney: should upgrade not be on the iso testing site for beta 1?
[16:54] <Laney> Riddell: If you like, but don't ask me - I'm not involved with this beta. :)
[16:54] <Laney> You can put them up there if you know how
[16:54] <infinity> xnox: If you let it in, it affects the others if they need to respin for some unrelated reason
[16:55] <Riddell> Laney: oh yes, sorry :)
[16:55] <seb128> xnox, right, I know ubuntu isn't, meanwhile we run/test and unity version which is not the one we should be testing (we might hit bugs already fixed and not see bugs in the current version)
[16:55] <Riddell> stgraber: should upgrade not be on the iso testing site for beta 1?
[16:55] <xnox> infinity: yeah, my point is without ubuntu-desktop partitipating, you /only ever/ affect others
[16:55] <stgraber> Riddell: they probably should, let me add them
[16:56] <xnox> seb128: i think we can wait till tomorrow's freeze block lift. ;-) still should be faster than ci-train unblock =))))
[16:56] <seb128> xnox, yeah, and build failed on ppc64el anyway, so need to fix that first
[16:57] <stgraber> Riddell: there you go
[16:58] <infinity> seb128: Oh, probably about time to ask for all those pre-landing PPAs to get ppc64el enabled.  We're not resource constrained anymore.
[16:58] <Riddell> stgraber: you meanie, you just gave me hours of extra testing to do!
[17:02] <seb128> infinity, speaking of which, do we have a porter box?
[17:03] <infinity> seb128: That's in progress today.  I'm about to nap, but will hopefully get together with an APAC GSA later tonight to make it go.
[17:03] <infinity> seb128: (And you get a powerpc porter box for free out of the deal)
[17:04] <seb128> cool
[20:00] <directhex> so what's the quickest way to get mono ppc64el removed from the archive? it's a blocker for -proposed transition, and i *really* want that unblocked for FFe reasons
[20:00] <directhex> i recognise that critical test suite failures should cause package build aborts. i'm discussing the best way to do that with upstream
[20:04] <bdmurray> slangasek: can you merge this? https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/no-rate-increase/+merge/208445
[21:13] <Noskcaj> Can someone please approve bug 1282937
[21:13] <ubot2> Launchpad bug 1282937 in xfburn (Ubuntu) "FFe: Please package xfburn 0.5.0" [Undecided,New] https://launchpad.net/bugs/1282937
[23:32] <slangasek> bdmurray: merged
[23:35] <bdmurray> slangasek: thanks
[23:45] <infinity> directhex: So, would it hurt your feelings if I said the better option is that I'm having people looking into fixing mono on ppc64el?
[23:45] <infinity> directhex: Is it actively breaking anything if it's allowed to build there?
[23:46] <directhex> infinity, more working arches is fabulous. but upstream have never looked at ppc64el - the fact that it even builds is accidental more than anything else
[23:48] <infinity> directhex: That didn't answer my question.
[23:48] <infinity> directhex: Does having mono broken in the way it is *actively break* other packages (ie: in the sense that they'd need to be rebuilt after mono was fixed), or just cause some/many of them to fail at runtime?
[23:48] <directhex> is it actively breaking anything? no
[23:48] <infinity> directhex: If they're just failing at runtime and a fixed mono would fix the world, I say we just let it build and work on fixing it.
[23:49] <infinity> (Which I have people looking into)
[23:49] <directhex> if leaf packages fail to build on ppc64el then, well, there's not much i can do about it
[23:49] <infinity> directhex: Failing to build is fine.  It's building incorrectly and needing a rebuild that's a mess to track down.
[23:49] <infinity> directhex: But as I understand mono, the latter shouldn't be the case.
[23:49] <directhex> infinity, yeah, most of the packages are arch:all
[23:50] <directhex> and the ones that are arch:any, only the C portion varies between arches
[23:50] <directhex> where, surprisingly enough, it's gcc's problem if it's screwy
[23:51] <directhex> i guess technically there could be glue code which would need a rebuild... but i suspect the glue code is assuming the same size of C types as ppc64, which is correct
[23:51] <infinity> Kay.  It's the cleanup of the arch:any stuff that I'm trying to avoid here (though will revisit if I have to, if mono isn't fixed by release).
[23:51] <infinity> Cause tearing out all the arch:any binaries for mono rdeps would mean reuploading all those sources when mono is fixed.