[02:37] can we get gnome-shell unblocked? [02:38] For Bug 1284496 [02:38] 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] sure, I'll let it through [02:52] Unfortunately stuck behind a security update of doom on powerpc. [02:53] Scored it up to see if it can get lucky. [03:02] thanks guys [03:39] 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] (I'll check on it later) [03:49] jdstrand: Shouldn't be necessary. Got gnome-shell built. === doko_ is now known as doko === jackson is now known as Guest46812 === Guest46812 is now known as Noskcaj [09:18] 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] the update fixes some segfault issues which are not hitting quite some users [09:21] seb128: Mostly up to stgraber. [09:22] infinity: have you seen http://people.canonical.com/~ubuntu-archive/livefs-build-logs/trusty/ubuntu-server-omap4/latest/livecd-armhf.out ? [09:22] Looks like component-mismatches to me [09:22] Laney: No. server-omap4 and server-omap just need love (or dropping) in general. [09:23] 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] I hear that [09:23] Every day I get a mail for the build failure. :) [09:23] Serves you right for signing up for livefs build failures. :) [09:24] It's often stuff that's fixable for me [09:26] But yeah. Trying to build images over and over which aren't going to work seems less than ideal. [09:28] Feel free to uncron them for now to reduce the noise. [09:28] But I need to either fix or drop them, this was a post-FF TODO item for me. [09:47] 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] (afaik trsalveti and diwic tested the binary on phone and desktop) [09:49] ogra: That's up to stgraber and the flavours doing beta. [09:50] ah, i thought you both do it [09:50] sorry then [09:50] Nah, I'm staying away from alphas and betas I'm not signed up for. [09:50] right, i'll just do a build without the fix then [10:52] Laney: hm. d-i components should always be frozen at milestones. I thought grub-installer was frozen, but it wasn't. [11:07] xnox: hmm, I guess [11:07] patches to generate-freeze-block welcome :) [11:13] can someone look at the trusty-proposed NBS packages from dolfin on arm64 please? [11:13] Laney: Sure. [11:14] Err, why only arm64, I wonder? [11:15] Weird. Maybe it never migrated. [11:15] Removing the NBS. [11:15] Yeah, dunno [11:15] ta [11:15] Fixed. [11:17] 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] infinity, (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#empathy) [11:19] seb128: It's out of date because it's out of date... [11:19] It used to build before its rdeps disappeared. [11:19] (In the previous archive, before the rebuild) [11:19] infinity, well, 3.8.6-0ubuntu4 had the same issue, how can it be a regression in the new revision? [11:19] seb128: I'll fix that up tomorrow. [11:19] infinity, thanks [11:20] Or, later today. [11:20] seb128: Also, I was going to yell at you for some recent upload with arch restrictions instead of build-dep hacks... [11:20] Which one was that? [11:21] https://lists.ubuntu.com/archives/trusty-changes/2014-February/010640.html [11:21] Oh, right, gnome-control-center-signon [11:21] I hate that package [11:21] "arm64 used to build but doesn't have qt5", that was the whole POINT of the build-dep hack. [11:21] shrug [11:21] To make it stop building on arches where it would subsequently be uninstallable. [11:22] well, that creates issue that I don't know how to resolve [11:22] Anyhow, most of this faff should go away (I hope) with qt5.2, we really need to get that in soon. [11:22] e.g britney was unhappy about empathy depending on libaccount-plugin-1.0-0 on arm64 [11:22] that wouldn't exist anymore [11:22] And we can stop having half our desktop arch-restricted. [11:22] I saw some requests for QA reports and all sorts of stuff for Qt 5.2 earlier on [11:22] right [11:22] So I'm not sure if that is close... [11:23] 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] Laney, Pat started pushing thing yesterday, let's see what happens next [11:23] Laney, (I hinted that they might miss trusty if they don't start making progresses soon) [11:23] Laney: We all need to push to make it closer, IMO. Anything anyone can do to help them fix things up. [11:24] infinity, right, so I should have deleted the empathy arm64 old binaries? [11:24] infinity, and I think empathy is not alone [11:24] tracking those issues down seems a waste, we just need to land qt5.2 as you said [11:24] meanwhile the g-c-c-signon arch restriction is the cheap and easy workaround [11:24] Pushing good, shifting sands bad [11:26] 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] seb128: Maybe I should try this in a PPA with PPC and arm64 enabled and see how bad/good the situation is. [11:27] right === psivaa is now known as psivaa-lunch === psivaa-lunch is now known as psivaa [16:01] Can you unblock qemu? it's mainly for bug #1284344 [16:01] Launchpad bug 1284344 in qemu (Ubuntu) "qemu-user-aarch64: dns is broken" [High,Confirmed] https://launchpad.net/bugs/1284344 [16:07] 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] qemu and pulseaudio unblocked [16:12] * ogra hugs stgraber [16:27] thanks stgraber :) [16:33] 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] 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] stgraber, having unity in could be nice as well, since that enable the scaling option for HiDPI [16:33] haha [16:34] Laney, what? ;-) [16:34] 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] stgraber, don't worry, it's only good code :p [16:35] 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] stgraber, fair enough, thanks [16:36] seb128: I just found listing all your uploads funny :P [16:36] Laney, "all", it was just a nicely selected set :p [16:37] 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] I'd have considered pulseaudio and datetime [16:37] 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] 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 === robru-is-dying is now known as robru [16:40] nod, that'd be my approach [16:40] cheers [16:52] 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] seb128: it would make more sense to "let new unity in, and respin ubuntu-desktop". [16:53] Laney: should upgrade not be on the iso testing site for beta 1? [16:54] Riddell: If you like, but don't ask me - I'm not involved with this beta. :) [16:54] You can put them up there if you know how [16:54] xnox: If you let it in, it affects the others if they need to respin for some unrelated reason [16:55] Laney: oh yes, sorry :) [16:55] 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] stgraber: should upgrade not be on the iso testing site for beta 1? [16:55] infinity: yeah, my point is without ubuntu-desktop partitipating, you /only ever/ affect others [16:55] Riddell: they probably should, let me add them [16:56] seb128: i think we can wait till tomorrow's freeze block lift. ;-) still should be faster than ci-train unblock =)))) [16:56] xnox, yeah, and build failed on ppc64el anyway, so need to fix that first [16:57] Riddell: there you go [16:58] 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] stgraber: you meanie, you just gave me hours of extra testing to do! [17:02] infinity, speaking of which, do we have a porter box? [17:03] 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] seb128: (And you get a powerpc porter box for free out of the deal) [17:04] cool === superm1_ is now known as superm1 === psivaa is now known as psivaa-afk === henrix_ is now known as henrix [20:00] 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] 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] slangasek: can you merge this? https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/no-rate-increase/+merge/208445 === robru is now known as robru-sick === hggdh_ is now known as hggdh === doko_ is now known as doko [21:13] Can someone please approve bug 1282937 [21:13] Launchpad bug 1282937 in xfburn (Ubuntu) "FFe: Please package xfburn 0.5.0" [Undecided,New] https://launchpad.net/bugs/1282937 === doko_ is now known as doko === doko is now known as stub === stub is now known as doko === smoser` is now known as smoser === seb128_ is now known as seb128 [23:32] bdmurray: merged [23:35] slangasek: thanks [23:45] 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] directhex: Is it actively breaking anything if it's allowed to build there? [23:46] 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] directhex: That didn't answer my question. [23:48] 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] is it actively breaking anything? no [23:48] 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] (Which I have people looking into) [23:49] if leaf packages fail to build on ppc64el then, well, there's not much i can do about it [23:49] directhex: Failing to build is fine. It's building incorrectly and needing a rebuild that's a mess to track down. [23:49] directhex: But as I understand mono, the latter shouldn't be the case. [23:49] infinity, yeah, most of the packages are arch:all [23:50] and the ones that are arch:any, only the C portion varies between arches [23:50] where, surprisingly enough, it's gcc's problem if it's screwy [23:51] 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] 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] Cause tearing out all the arch:any binaries for mono rdeps would mean reuploading all those sources when mono is fixed.