[04:37] <arges> bdmurray: I know this is much later, but just accepted that package.
[05:11] <chiluk> hey infinity, or really any other release folks, can we get https://launchpad.net/ubuntu/+source/ceph/0.80.11-0ubuntu1.14.04.1  pushed to -proposed?  It failed to build earlier due to memory constraints on arm64, but it's building now.
[05:11] <chiluk> rather is built now.
[05:12] <chiluk> wgrant since you are up do you mind pushing the above package to -proposed?
[05:14] <wgrant> chiluk: I'm not on the SRU team. You'd be best to wait for a member of that team.
[05:18] <slangasek> chiluk: not sure what you mean; it's built /in/ -proposed.  Do you mean pushed to updates?
[05:19] <slangasek> it also looks a bit like the binaries for the archs were built once but have been removed from trusty; hrm
[05:20] <slangasek> wgrant: this may be a question for you after all, I have no idea what happened here to the binary packages ;)
[05:20] <wgrant> slangasek: They were removed by pitti as NBS a couple of weeks ago.
[05:20] <wgrant> I guess the source was too, then it was revived.
[05:20] <wgrant> I think?
[05:20] <slangasek> ah?
[05:20] <slangasek> so why was the source revived
[05:21] <wgrant> slangasek: It FTBFS on arm64 until today.
[05:21] <wgrant> I don't know what fixed it.
[05:21] <slangasek> so the build caused the source to autorevivify?
[05:22] <wgrant> Hm, the source was never deleted.
[05:22] <wgrant> Then why were the binaries deleted as NBS?
[05:22] <slangasek> good question
[05:22] <wgrant> https://launchpad.net/ubuntu/+source/ceph/0.80.11-0ubuntu1.14.04.1/+publishinghistory vs https://launchpad.net/ubuntu/trusty/amd64/ceph
[05:22] <slangasek> is there a magic wand to re-publish those, or should I ask for a fresh build?
[05:23] <wgrant> A normal copy-package should work to revive them.
[05:23] <slangasek> s/build/upload/
[05:23] <wgrant> copy-package --from=ubuntu --to=ubuntu --from-suite=trusty-proposed --to-suite=trusty-proposed ceph -b --force-same-destination
[05:23] <wgrant> ish
[05:25] <slangasek> wgrant: the only binaries that shows me for non-arm64 are the arch: all ones
[05:25] <slangasek> chiluk: ok, so I see there's a ceph/0.80.11-0ubuntu1.14.04.2 in the queue. is that the one you're actually after?
[05:26] <wgrant> slangasek: I think that's a lie and it will actually work.
[05:26] <slangasek> wgrant: really? because it shows me *only* arm64 binaries being copied, and I'm used to that output being correct
[05:26] <slangasek> well
[05:26] <slangasek> I'm used to trusting that output, anyway
[05:27] <wgrant> Do you often deal with reviving deletions?
[05:27] <slangasek> I've done it more than once, and the output looked correct to me then :)
[05:27] <wgrant> There are some inconsistencies with copy-package's output.
[05:27] <wgrant> Hmm.
[05:27] <slangasek> ok
[05:28] <wgrant> Anyway, copying too little isn't a fatal problem.
[05:28] <wgrant> So I'd do it anyway and see what it copies :)
[05:28] <slangasek> ok, let's see what happens
[05:30] <slangasek> oh srsly
[05:30] <slangasek> alias copy-package='copy-package --auto-approve && rm -rf'
[05:30] <wgrant> Heh
[05:31] <wgrant> It lives.
[05:31] <wgrant> So indeed, copy-package lied.
[05:31] <slangasek> heh, alrighty
[05:31] <slangasek> chiluk: so... turns out we don't need that second upload? :)
[05:31] <chiluk> slangasek ... man you know about as much as me... apparently a ram upgrade on the builders revived the failing arm64 builds.
[05:31] <chiluk> I see arm64 made it to -proposed.
[05:32] <chiluk> but the rest seem to be awol..
[05:32] <wgrant> It'll all be publishing to -proposed in the next run.
[05:32] <slangasek> chiluk: right, was that a ram upgrade called 'scalingstack'?
[05:32] <slangasek> or something else
[05:32] <wgrant> We upped scalingstack arm64 and ppc64el RAM from 4GiB to 8GiB a few hours ago.
[05:32] <slangasek> ok
[05:33] <chiluk> slangasek: i have no idea.. cjwatson just mentioned that some of the arm builders got memory upgrades, and the failure looks like a OOM killer gone awry
[05:33] <slangasek> is amd64 the same?
[05:33] <wgrant> The mustangs have enough RAM, but I guess the ceph build landed on a scalingstack pretending to be non-virt.
[05:33] <wgrant> slangasek: We may need to get the amd64 compute nodes upgraded a bit, so it's still 4GiB for the moment.
[05:34] <chiluk> wgrant this ceph build failed a few weeks ago iiuc.. I just started needing it today, so that's when I started looking at it.
[05:34] <wgrant> chiluk: Right, first failed two weeks ago.
[05:34] <wgrant> And we only upgraded the RAM a handful of hours ago
[05:34] <chiluk> snazzy.. to a whole 8gb.. oh my what are we going to do with all those bits!
[05:34] <slangasek> expand to fill them, duh
[05:35] <chiluk> sometimes my sarcasm doesn't come accross fully on irc.
[05:35] <slangasek> me, I'm doing my part by running livefs builds over and over again
[05:35] <wgrant> slangasek: My poor loopback devices.
[05:35] <slangasek> wgrant: the archive is fixed, so any hosts that are out of loop devices (like kishi12 was) just need a firm kick
[05:35] <wgrant> Ah good.
[05:36] <slangasek> mind you, as I say this I realize that the livecd-rootfs hook scripts do not have any sort of cleanup handler that copes if I have a script that exits non-zero ;)
[05:36] <slangasek> so I'll try to do that less
[05:37] <chiluk> wgrant the arm64 build finished a good 5 hours ago, and is in -proposed.. are you sure the rest are going to be pulled in with out some sort of kick?
[05:37] <wgrant> chiluk: See above, slangasek kicked them.
[05:37] <slangasek> chiluk: yes, that was the side discussion between me and wgrant
[05:37] <wgrant> They were deleted, probably because the arm64 build failed, and we just undeleted them.
[05:38] <slangasek> I ran 'launchpad cp foo foo -f' and counterintuitively, this works
[05:38] <chiluk> I'm assuming that was the copy-package command I now notice in backscroll
[05:38] <wgrant> Yup
[05:38] <chiluk> alright thanks guys.. our collective paychecks thank you..
[10:23] <tseliot> can an admin approve nvidia-graphics-drivers-361 and nvidia-graphics-drivers-361-updates in xenial NEW, please?
[10:43] <tseliot> arges: ^^
[11:09] <cjwatson> chiluk,slangasek,wgrant: what actually happened was that the retry happened just before we did the RAM upgrade on scalingstack, and was lucky enough to land on a mustang.  then I complained because it would have been a nice test case for scalingstack. :-)
[11:10] <wgrant> Ah heh
[13:15] <doko> old binaries left on powerpc: lldb (from 0.33ubuntu1)
[13:16] <doko> but it is already removed?
[13:18] <cjwatson> NBS in -proposed, needs manual handling.  I'll clean it up
[13:19] <cjwatson> done
[14:33] <doko> llvm-defaults (0.33 to 0.33ubuntu2)
[14:33] <doko> Invalidated by dependency
[14:33] <doko> Not considered
[14:33] <doko> Depends: llvm-defaults llvm-toolchain-snapshot (not considered)
[14:34] <doko> can we override this? these binaries are now built by llvm-toolchain-3.8. or just remove it?
[14:34] <cjwatson> wait
[14:34] <cjwatson> that never needs to be overridden, I expect something is subtly wrong
[14:43] <cjwatson> doko: http://paste.ubuntu.com/15016381/ - clang-modernize depends on clang-modernize-3.8, only built by -snapshot
[14:44] <doko> ok, looking
[14:45] <doko>   * clang-modernize has been removed. Long live to clang-tidy, its
[14:45] <doko>     replacement
[14:47] <cjwatson> ok, so the metapackage should be removed then?
[14:48] <doko> yes, and building clang-tidy, merging from experimental
[14:49] <cjwatson> it builds clang-tidy already
[14:51] <doko> hmm, then no merging needed
[15:45] <coreycb> hello, can an archive admin please promote python3-glanceclient to main? this will help get some of our openstack packages out of dependency waits.
[15:54] <doko> coreycb, done
[15:54] <coreycb> doko, thanks
[17:06] <coreycb> can an archive admin please promote python3-cinderclient to main?  this is needed to get some openstack packages out of dependency waits.
[18:03] <wxl> flocculant: i filled out https://wiki.ubuntu.com/XenialXerus/ReleaseTaskSignup to make it clear what the Official Release Team™ is responsible for so that community members don't go clamoring to try to help, but i thought i might remind you that it's not clear who is supporting you on Beta 1
[18:05] <flocculant> yea I know that - no rush - trusty first :p
[18:05] <wxl> right right
[18:05] <wxl> just don't want any surprises for you, buddy XD
[18:08] <flocculant> :)
[18:08] <flocculant> I'll find out in enough time to get them to stop builds :)
[18:08] <bdmurray> Should vivid still be on the sru-report?
[18:24] <dannf> arges: would you mind rejecting the go-md2man trusty sru from 2016-02-05? my build-dep versioning didn't take into account epochs, and i've uploaded a fix just now
[18:25] <arges> dannf: sure
[18:25] <dannf> arges: thx!
[18:26] <arges> dannf: done
[18:29] <dannf> arges: sorry, i meant the other one :( can you reject that one, and i'll wait to upload till after
[18:30] <arges> dannf: ok
[18:30] <arges> done
[18:31] <dannf> arges: ta!
[18:44] <cyphermox> bdmurray: arges: could one of you please review multipath-tools in trusty queue? it would fix a regression that was found in one of the patches. where loopmounted image files don't get the loopback nodes removed when the map is deleted.
[18:51] <bdmurray> cyphermox: I'll have a look.
[19:06] <slangasek> cyphermox: should the new multipath-tools SRU require full reverification, or just regression testing?
[19:06] <cyphermox> just regression testing
[19:07] <cyphermox> it won't affect anything else than kpartx -d in the issue we've noticed earlier on s390x, for instance.
[19:22] <bdmurray> jamespage: you want your ceph upload to trusty rejected?
[19:45] <jamespage> bdmurray, yes please
[19:50] <jamespage> bdmurray, please could the neutron in the trusty unapproved queue be rejected as well; we have another fix to go in alongside that one.
[19:51] <bdmurray> jamespage: I don't see that in the queue
[19:51] <jamespage> hmm
[19:52] <jamespage> bdmurray, maybe someone already rejected it for coreycb
[19:52] <jamespage> apologies
[19:52] <bdmurray> no problem
[19:53] <coreycb> bdmurray, jamespage, arges already rejected neutron
[19:58] <jamespage> coreycb, ack - I just uploaded a revised version with my extra cherry pick
[19:58] <jamespage> coreycb, we'll need to pick the fix for kilo UCA as well - raised tasks on https://bugs.launchpad.net/cloud-archive/+bug/1460164
[19:58] <ubot5`> Launchpad bug 1460164 in neutron (Ubuntu Wily) "restart of openvswitch-switch causes instance network down when l2population enabled" [High,In progress]
[19:59] <jamespage> coreycb, ^^ that one :-)
[20:00] <coreycb> jamespage, ack thanks!