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