[14:19] <balloons> pitti, more questions about juju-core :-) Thanks for the response about access, I felt like it was open as I saw the proxy, but we weren't sure. Anyways, still looking for an autopkgtest run: http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#juju-core
[14:20] <balloons> you can see I removed 32-bit arches as we don't support them. This I think is holding the package?
[14:38] <pitti> balloons: right, they need to be removed from -release, not (just) -proposed
[14:39] <pitti> balloons: and their reverse dependencies too (conjure-up, charm, charm-tools)
[14:40] <pitti> balloons: i. e. this at least requires an upload of charm
[14:41] <pitti> balloons: but still, are you sure that's the right solution? nobody cares about powerpc, but i386 and armhf are quite important arches
[14:42] <balloons> pitti, well given the amount of work you are laying out, no. But if we hit build issues on arches we don't support (like the ppc issue that triggered this), we can get stuck it seems
[14:48] <balloons> so what would you suggest? even to remove powerpc it sounds like we'd have to change charm and charm tools
[15:37] <balloons> pitti, ^^ any thoughts? If we just leave it alone, is there any alternatives when a build breaks?
[16:51] <xnox> balloons, archive admins can remove binaries from the release pocket of development series. Thus a package with failing powerpc can migrate.
[16:51] <xnox> and continue migrate until next time powerpc manages to build again.
[16:51] <xnox> the problem is not in failing to build, the problem is in regression of previously building. Which can be tweaked.
[16:52] <xnox> not so much luck with released series. e.g. xenial. Because released pocket is frozen after release and never changed.
[16:54] <balloons> xnox, right. This affects both xenial and yakkety, and we want to SRU back to xenial where it also fails to build
[16:55] <balloons> xnox, so given that xenial is frozen actually, we have to fix the ppc build. There's really no way to land without doing that?
[16:55] <xnox> balloons, so imho just talk to slangasek. there shouldn't be a need to change packages.
[16:55] <xnox> let it continue to fail to build on powerpc
[16:55] <xnox> and one can fiddle on the archive things for it to migrate (in yakkety case)
[16:55] <xnox> and release sru (in xenial case)
[16:56] <xnox> however slangasek is afk atm, so email him.
[16:58] <pitti> balloons: the obvious alternative is to fix it :)
[16:59] <pitti> balloons: as the previous version builds, and we have porter boxes, doing a git bisect should be fairly straightforward to see what broke it?
[17:00] <balloons> pitti, is there a way for me to run a different build on a ppc box without uploading an entire new package?
[17:00] <balloons> I have an idea on what is breaking it
[17:01] <balloons> the bigger issue is that we may run into issues where we don't have an updated version of go or a dependency building on powerpc, and thus we could get stuck on releasing juju. So I was thinking of aligning the package with our intended client support
[17:01] <pitti> balloons: "ssh porter-powerpc.canonical.com"?
[17:02] <balloons> I've never worked with those boxes
[17:02]  * balloons tries
[17:02] <pitti> it has xenial and yakkety chroots
[17:03] <pitti> I'm afraid I don't have any other powerpc machine either; infinity might have some
[17:03] <pitti> balloons: anyway, for y at least it would be acceptable to remove the powerpc binaries of juju-core and its rdepends (which is just one AFAICS), so not insurmountable
[17:04] <pitti> but obviously we prefer to actually keep it working, especially if the breakage is very recent
[17:05] <pitti> is there no useful error message in https://launchpadlibrarian.net/279211511/buildlog_ubuntu-yakkety-powerpc.juju-core_2.0~beta15-0ubuntu1.16.10.1_BUILDING.txt.gz ?
[17:05]  * pitti can't see any, but then again I have 0 experience with go..
[17:05] <balloons> pitti, ack. I will make an effort to find out exactly what is broken and try and fix it. Given xenial is set, it seems like continuing to support 'all' arches is the easiest path, despite us not actively supporting those clients
[17:05]  * pitti back to dinner, bbl
[17:06] <balloons> pitti, it's abstract yes. But I believe it's an old dependency on ppc
[17:06] <balloons> pitti, night! ty