[00:18] <RAOF> coreycb: Would you like to roll in the neutron 1:2014.1.4-0ubuntu3 that's still waiting in the trusty-unapproved queue? That's the fix for lp: #1463844
[04:41] <wgrant> RAOF: The SRU from https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1324391 has made python-pip uninstallable.
[04:42] <wgrant> python-pip -> python-pip-whl -> python-requests-whl
[04:42] <wgrant> And python-requests-whl is only in trusty-proposed.
[04:42] <wgrant> So python-pip from trusty-updates is uninstallable.
[04:42] <wgrant> setuptools and six also seem to be missing their -whl in -updates.
[04:52] <RAOF> wgrant: Balls.
[04:53] <wgrant> RAOF: Quite.
[04:53] <wgrant> RAOF: I'm tempted to roll back -updated to -1ubuntu1, unless the other three SRUs are ready.
[04:54] <wgrant> Though I don't know how the phased updater deals with the currently phased version vanishing.
[04:54] <wgrant> infinity: ^^
[04:55] <RAOF> Requests is ready, modulo an autopkgtest regression for neutron which may or may not be its fault.
[04:55] <RAOF> As is six.
[05:07] <RAOF> Hm. I'm tempted to let requests and six through; the neutron autopkgtest that they fail has never passed in trusty-updates, and there's a neutron SRU in unapproved that needs touching before acceptance and should get whatever autopkgtest fixes are necessary.
[05:08] <wgrant> You don't think the new requests will break existing neutron deployments?
[05:10] <RAOF> It doesn't appear to; the neutron autopkgtests pass until they die in apparently the same way they've been dying since Feb.
[05:10] <RAOF> That said, killing -1ubuntu3 from updates seems like a good idea.
[05:11] <wgrant> The phased updater successfully makes things disappear due to Soyuz bugs, so I suspect it will stop phasing something if it goes away.
[05:11] <wgrant> So it's probably safe to delete -1ubuntu3 and restore -1ubuntu1 in its place.
[05:16]  * RAOF would like it if his laptop didn't mysteriously hang and then no longer see the bluetooth device, but he.
[05:16] <wgrant> Heh
[05:17] <RAOF> Also: wtf? Where has my ipv4 gone?
[05:17] <wgrant> Do you want me to do the remove-package + copy-package?
[05:17] <RAOF> wgrant: Yes please.
[05:18] <RAOF> wgrant: I can't reach launchpad for some reason.
[05:18] <wgrant> That's a bit weird.
[05:38] <RAOF> So, it would be nice if my laptop didn't choose this particular moment to become really flaky.
[05:38] <wgrant> Picky.
[05:39] <RAOF> I think *this* boot I have both bluetooth *and* ipv4 internet!
[05:39] <RAOF> Have you done the remove+copy?
[05:39] <wgrant> Yup, -1ubuntu1 is back in place.
[05:40] <wgrant> Published, in fact.
[05:56] <infinity> wgrant: The phased updater is bdmurray's baby, not mine, but if you're rolling back to a previously known-good version, just phase it to 100% out of the gate, and life should be fine.
[05:57] <wgrant> infinity: My concern was that it might decide that 10% was good, so it would bump to 20% and supersede the old version.
[05:58] <wgrant> But it hasn't done that yet, and the fact that it doesn't revive binaries after Soyuz eats them suggests that it isn't going to.
[05:59] <infinity> wgrant: Yeah, I've never looked at the code, but it might be sort of smarter than that.  Or, as you hint, so dumb that it appears smart in this case.
[05:59] <infinity> I should fix the eating binaries bug, though.
[05:59] <infinity> I mean, not on the soyuz side, that's your mess.
[06:00] <wgrant> I looked at the code once but didn't get past about line 50.
[06:00] <infinity> But by getting around to triggering the world.
[06:00] <wgrant> Because I died of XSS.
[06:00] <infinity> <= One run per publisher pretty much guarantees avoiding the override bug.
[06:00] <wgrant> Indeed.
[06:01] <infinity> Well, until an AA overrides something in the same run as the phased updater does. :P
[06:01] <infinity> But if an AA is overriding things in -updates, they've already messed up, and should be prepared to deal with the fallout.
[08:02] <cjwatson> infinity: Looks like the Haskell transition got close enough to some relevant tipping point that it traded things off and disentangled itself from the nettle transition.  So, um, win?
[08:03] <cjwatson> I suspect it was because the new GHC has GHCi on all Ubuntu architectures and so made various odds and ends installable on three more architectures, enough to balance out the incomplete transition.
[08:08] <infinity> cjwatson: GHCi on all 6 arches?  Ooo.
[08:08] <wgrant> We'd best add some more.
[10:08] <cjwatson> OMG openstack python3ness
[10:08] <cjwatson> presumably a long way to go ...
[10:16] <sil2100> infinity: hey! I'm looking for someone with ubuntu-cdimage knowledge, as I don't know the code - both our touch images for vivid and wily failed building yesterday due to some qatracker milestone issues
[10:16] <sil2100> infinity: could you help out?
[10:21] <infinity> sil2100: The person you want for isotracker stuff is stgraber.  But lemme have a quick look before I go to bed.
[10:22] <sil2100> infinity: thanks! The logs have some info: vivid/daily-preinstalled-20150624.log and wily/daily-preinstalled-20150624.log
[10:22] <infinity> sil2100: Which project?
[10:22] <sil2100> ubuntu-touch
[10:23] <sil2100> Tried looking at the code, but it would probably take much longer for me to trace back to where it's getting all the milestone information from
[10:23] <sil2100> And where it's used
[10:23] <infinity> sil2100: So, that doesn't look like a failure... Just a failure to post to the tracker.
[10:24] <sil2100> infinity: oh, is that normal?
[10:24] <infinity> sil2100: I certainly see images here: http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20150624/
[10:24] <sil2100> Yeah, the rootfs built correctly, but I thought it failed later in the build image steps
[10:24] <infinity> sil2100: No, it's not normal for it to fail to post, but it's also not fatal.  And I assume you don't use the ISO tracker anyway.
[10:24] <sil2100> infinity: ah, ok, thanks :)
[10:25] <sil2100> Nevermind then!
[10:25] <infinity> sil2100: Anyhow, you can probably bug stgraber to figure out why the tracker integration is breaking, but it shouldn't be harming you any, I wouldn't think, unless your tools rely on the tracker instead of hitting cdimage directly.
[12:32] <cjwatson> component-mismatches-proposed fixed
[12:32] <cjwatson> https://git.launchpad.net/germinate if you want the gory details
[12:48] <coreycb> RAOF, yes, I'll roll in the neutron 1:2014.1.4-0ubuntu3 trusty updates, thanks!
[13:36] <Riddell> anyone know why "marble,calligra,libkgeomap" won't transition? I can't work it out from http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
[13:49] <cjwatson> Riddell: Given that the same packages are mentioned in transition groups further up, I think they're tangled in a larger transition
[13:50] <cjwatson> Riddell: You can see them mentioned in the one starting "abiword,libwps,..."
[13:50] <cjwatson> Riddell: micahg mentioned some status on that on #ubuntu-devel earlier today
[13:58] <Riddell> mm thanks
[14:18] <utlemming> infinity, stgraber: pitti's upload for udev (https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1468091) is confirmed to fix Cloud Images. If we can this promoted, I can trigger a new set of builds.
[15:06] <Laney> cjwatson: if you've some time, can you maybe help execute his proposed solution?
[15:06] <cjwatson> Laney: I don't
[15:06] <cjwatson> (sorry)
[15:06] <Laney> 'k
[15:14] <coreycb> RAOF, arges: we have a new neutron 1:2014.1.5-0ubuntu1 in the trusty upload queue that includes the updates from neutron 1:2014.1.4-0ubuntu3.  can you review the most recent neutron 1:2014.1.5-0ubuntu1 and reject the other two that are in the unapproved queue?
[15:14] <arges> coreycb: looking
[15:15] <arges> coreycb: done
[15:17] <coreycb> arges, thanks
[18:10] <stgraber> sil2100: I'll take a look at the posting failure for touch
[18:16] <mdeslaur> arges: the gtksourceview2 control file is automatically regenerated from control.in during build, the change wasn't a manual one
[18:16] <mdeslaur> arges: can I re-upload them as-is?
[18:16] <arges> mdeslaur: Yea makes sense, seems wierd it was dropping a name.
[18:16] <mdeslaur> arges: yeah, it's odd
[18:17] <mdeslaur> arges: do I have to re-upload them, or are they still available for you to release?
[18:17]  * mdeslaur uploads them
[18:19] <arges> mdeslaur: I can review from the Rejected queue... but re-uploading (As you've already done) is fine
[18:19] <mdeslaur> thanks
[18:19] <arges> sorry about the noise
[19:18] <sil2100> stgraber: thanks! It's not anything serious though, I thought it is a real error by mistake
[19:19] <stgraber> oh, that's one odd error
[19:19]  * stgraber looks at tracker
[19:21] <sil2100> Well, it's a real error, but not anything actually breaking image builds - that's what I meant
[19:23] <stgraber> sil2100: so looks like somebody actually did disable those products on the tracker...
[19:23] <stgraber> sil2100: but the log has since rotated so I can't see who
[19:25] <stgraber> anyway, re-enabled
[19:29] <sil2100> stgraber: oh, thanks o/