[09:01] <jamespage> Laney, gah - looking
[09:08] <jamespage> Laney, swift re-uploaded with out of VCS changes re-instated - nice catch!
[09:14] <Laney> jamespage: thanks
[09:23] <mlankhorst> can someone accept mesa-lts-trusty? mesa in trusty already has that version in -proposed
[10:41] <jamespage> Laney, can you see reject reasons that the release team made?  I'm trying to sweep up the last rc for openstack (ceilometer) but I see it was rejected last week and neither zul or coreycb are up yet
[10:42] <Laney> jamespage: nope, they only get emailed to the uploader
[10:42] <jamespage> Laney, gah!
[10:42] <jamespage> :-(
[10:43] <Laney> jamespage: however that might have been me asking for FFe for the IPMI agent
[10:44] <Laney> bug #1377218
[10:44] <ubot2> bug 1377218 in ceilometer (Ubuntu) "[FFe] ceilometer 2014.2.rc1" [Undecided,Invalid] https://launchpad.net/bugs/1377218
[10:44] <Laney> I didn't get to review that yet
[10:44] <jamespage> Laney, I thought it might have been
[10:44] <jamespage> Laney, let me complete that
[10:45] <jamespage> Laney, there was some confusion last week - that's prob my fault
[10:45] <jamespage> (no-one actually told me the release team asked for a FFe so I got coreycb to drop it)
[10:46] <Laney> no harm done
[10:46] <Laney> Will poke today if I'm not beaten
[10:46] <jamespage> Laney, thanks - just reading it now
[13:35] <jamespage> ^^ that point release is needed for the horizon
[14:25] <dbarth> for note: signon and accounts-qml-module above have a packaging change ^^
[15:07] <barry> Laney: btw i think you're on the release team.  could you have a quick look at LP: #1376736
[15:07] <ubot2> Launchpad bug 1376736 in pycurl (Ubuntu) "[FFe] update to pycurl 7.19.5" [High,New] https://launchpad.net/bugs/1376736
[15:07] <Laney> barry: in a bit, doing a couple of uploads first
[15:07] <barry> Laney: np, and thanks!
[15:14] <infinity> barry: I'd recommend soliciting ScottK's input, as he's more in touch with pythony things in general.
[15:14] <infinity> (unless the FFe is a no-brainer slam dunk that any monkey could process with minimal fuss, I haven't looked)
[15:15] <barry> infinity: it's probably just a bit more than obvious, so ScottK would be a good second set of eys
[15:15] <barry> *eyes
[15:15] <infinity> ScottK: ^-- Care to have a poke at barry's FFe above, if you have time?
[17:04] <pfsmorigo> cjwatson, infinity: hi, we find an problem in the installer. it seems that if you format the disk before install ubuntu in it, grub-install will fail
[17:04] <pfsmorigo> https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1376973
[17:04] <ubot2> Launchpad bug 1376973 in debian-installer (Ubuntu) "ppc64el: The 'grub-ieee1275' package failed to install" [Undecided,New]
[17:04] <pfsmorigo> *a problem
[17:05] <pfsmorigo> like  do a "mkfs.ext4 -F disk1.raw" before install ubuntu
[17:06] <pfsmorigo> (I know that this command doens't make sense but cause the bug)
[17:06] <cjwatson> Thanks, I'll look at that
[17:18] <pfsmorigo> cjwatson: I just got a report that installing ubuntu on a powervm are having a similar problem. maybe it's the same cause
[17:20] <cjwatson> pfsmorigo: no need for further information, have fixed
[17:21] <pfsmorigo> cjwatson: what was the cause?
[17:21] <cjwatson> pfsmorigo: wiping the bootdev needs to be done earlier now that grub-ieee1275.postinst runs grub-install
[17:22] <cjwatson> oh, hm, my fix is buggy though now I think of it.  anyway leave it with me.  OT for this channel anyhow :)
[17:23] <pfsmorigo> cjwatson: ok
[17:36] <smb> repeating myself from ubuntu-devel: Can someone check the xen package in Utopic. Somehow the publishing history claims it should be moved to release but its not there (xen-4.4.0-0ubuntu8)
[17:38] <cjwatson> the copy failed, probably because of a librarian snafr
[17:38] <cjwatson> snafu
[17:38] <cjwatson> this isn't the first, so rather than me fixing it straight away I'm going to see if I can scan for it
[17:39] <smb> cjwatson, Ok. I suppose as I still have the source of that, it will be ok to base another upload on that and proceed from there
[17:40] <cjwatson> cjwatson@carob:/srv/launchpad.net-logs/production/ackee/launchpad$ zcat celeryd-production_launchpad_job.log-20141002.gz | grep --count OOPS
[17:40] <cjwatson> 13
[17:40] <cjwatson> smb: can you let me fix it first just in case of confusion?
[17:41] <smb> yeah, sure.... it is beer time anyway, so I can wait
[17:41] <cjwatson> I shouldn't expect it'll take me too long
[17:41] <cjwatson> But happy beering
[17:41] <smb> cheers
[17:41] <smb> :)
[17:57] <cjwatson> smb: OK, fixed.  Five of the seven affected copies (python-oslo.vmware utopic-proposed -> utopic, lucid-{,meta-}ec2 PPA -> lucid-proposed, lucid-{,meta-}lowlatency PPA -> precise-proposed) had already been retried and had succeeded.  I've just retried the remaining two (pythonmagick/ppc64el utopic-proposed -> utopic, xen utopic-proposed -> utopic) and they've succeeded.
[17:57] <cjwatson> The remaining six OOPSes from the log were merge review e-mails which I'm going to continue happily ignoring.
[17:58] <smb> cjwatson, Heh ok, I can happily live with that :) thanks
[21:14] <dobey> anyone can approve the FFe for https://bugs.launchpad.net/ubuntu/+source/unity-scope-click/+bug/1368252 please?
[21:14] <ubot2> Launchpad bug 1368252 in unity-scope-click (Ubuntu) "[FFe] Repetitious language during uninstallation of Apps" [High,In progress]
[21:17] <hallyn> ok so back to the FFE for bug 1374617 - wahtever solution we come up with for qemu/libvirt (for precise->trusty migration) we'll need this.  AFAIK there's no other route we'd want to take.  Can we start with the FFE for that and then go back to qemu? (libvirt patch being only for trusty so an sru not ffe matter)
[21:17] <ubot2> bug 1374617 in Ubuntu Trusty "[FFE] New package: ipxe-precise" [High,Confirmed] https://launchpad.net/bugs/1374617
[21:32] <infinity> hallyn: Did we ever discuss how long we'd have to carry this ipxe-precise?
[21:32] <infinity> hallyn: Like, at what point do we say "sucks to be you" and stop supporting pc-1.0-precise?
[21:33] <infinity> hallyn: I would have assumed that point would be "post-trusty", which makes this not an FFe issue at all.
[21:34] <hallyn> infinity: i would think the 'at some point' would be after precise is EOL.  (or never)  now, we *could* be harsher and say "you must migrate to trusty,and then you must change the machine type"
[21:34] <hallyn> i find it rather hard to believe someone would need their machine to be around un-rebooted from 12.04 .. 16.04...  but ppl are whacky
[21:35] <hallyn> but, if we were to not have it in utopic, then we wouldn't need the pc-1.0-qemu-kvm machine type in utopic either (that is, we *could* not have it as it requires the roms)
[21:35] <hallyn> so then we don't need ffe for any of this, just SRU
[21:35] <infinity> dobey: I'm not sure I agree with the departure from other UI bits to use Confirm/Cancel instead of Yes/No just because of the preference for verbs, but it seems a no-brainer otherwise.
[21:36] <infinity> hallyn: Right, that's what I was driving at.  We don't support upgrades that skip LTSes.
[21:36] <hallyn> infinity: but no this wouldn't e skipping LTSes
[21:37] <infinity> hallyn: So, if we don't plan to support pc-1.0-precise $forever, we should draw the line earlier than later, IMO.
[21:38] <dobey> infinity: i've yet to actually see a yes/no anywhere, and it's a time-tested bad practice of UI to do that (so not sure why anything else would use it, but i don't want to spend rest of my life trying to convince a designer of anything)
[21:38] <hallyn> after you migrate pc-1.0 from p->t, it remains pc-1.0;  so you'd still need pc-1.0 in 16.04 if you're going to migrate it, unless you shut it down, convert the xml, and restart it as a new mt (potentially losing driver support)
[21:38] <infinity> dobey: I was just going by the bug comments, to be fair, not an specific experience.
[21:38] <infinity> s/an/any/
[21:39] <hallyn> infinity: but i do like the idea of saying "after trusty you're out of luck"
[21:39] <dobey> infinity: yeah, i gathered as much. :)
[21:39] <infinity> dobey: Anyhow, FFe seems sane and reasonable, go for it.  Will this be translated to any meaningful degree by release?
[21:39] <dobey> and whee, now lp is not bing responsive
[21:39] <dobey> infinity: yes, should already be translated as it's landed into rtm already
[21:40] <infinity> dobey: Shiny.
[21:41] <dobey> just waiting to get the +1 comment on the bug from one of you release teamers, so i can poke the CI train machinery to get it merged to utopic
[21:41] <infinity> dobey: Oh man, I have to comment myself now, you can't copy and paste and let me be lazy? :)
[21:42] <infinity> dobey: Done.
[21:42] <dobey> thanks :)
[21:49] <hallyn> infinity: ok, gonna think a bit longer about downsides, but i sure like the idea of dropping the FFE and just doing this only for trusty
[21:50] <infinity> Well, the obvious downside is that people would need to actually migrate after upgrading to trusty.  But I don't think it's reasonable to carry an old version of a package forever to avoid that.
[21:51] <infinity> hallyn: The other way out of this mess is to have some clever upgrade scripts copy the old ipxe binaries to /var/lib/qemu/randomjunk and treat them as payload data for eternity.
[21:51] <infinity> hallyn: But that doesn't help people who upgraded from precise to trusty and are currently broken. :/
[21:52] <infinity> (Though, I assume those people have already found a manual way out)
[21:53] <hallyn> infinity: of course one OTHER possibility (which i don't like) is to say "ppa:serge-hallyn/qemu-migration can be used to migrate p->t;  otherwise, unsupported"
[21:54] <infinity> hallyn: I'm not fond of any out-of-archive solution to upgrade problems.
[21:55] <infinity> hallyn: But I do also wonder how many people with this problem haven't already upgraded.
[21:55] <infinity> hallyn: As in, are we trying to fix something that 99% of those affected have already worked around?
[21:55] <hallyn> infinity: i actually don't think so;  i suspect there are plenty of ppl who have not yet updated (or at leas tnot yet completed update) to 14.04;  they're waiting for 14.04.2 or whatever so they can feel safer
[21:56] <infinity> hallyn: 14.04.1 is our usual "safe upgrade" point.
[21:56] <infinity> hallyn: But sure, there are always the people who wait a year or two.
[21:56] <infinity> hallyn: Just wonder how those people intersect with people who migrate VMs.
[21:57] <infinity> Since VMy people are usually all cutting edge ra ra, latest tech, etc.
[21:59] <infinity> hallyn: Anyhow, probably not worth playing the what-if game, if it's trivial to sihp the binary in trusty and just be done with it.
[21:59] <infinity> hallyn: But I don't think it's a solution we want to support into post-trusty releases.
[22:00] <hallyn> ok.  How do I mark that in the bugs (for qemu and ipxe-precise), mark it wontfix for utopic and seek SRU?
[22:00] <infinity> hallyn: People already need to do manual things to make this work, so if the documentation for those manual things also says "and you can't migrate past trusty without ditching the pc-1.0-precise machine type", that's not a big deal, IMO.
[22:00] <infinity> hallyn: If this was all automatic, I might be looking for more clever here, but since it's all manual ANYWAY, supporting it for post-trusty is just creating work we don't need.
[22:00] <hallyn> are there release notdes for point releases (or whatever '14.04.2' is called)?
[22:01] <infinity> hallyn: Yeah, there are point release release notes.  I'm not convinced anyone reads them, but we write them.
[22:01] <hallyn> hah.  more popular than manpages
[22:01] <infinity> hallyn: The trusty release notes are a living document anyway, if you get this stuff in, you can amend the release notes as they are now, no need to wait for .2
[22:03] <hallyn> infinity: ok, thanks.
[22:03] <infinity> hallyn: And yeah, for the bug(s), summarize this discussion to some extent and mark utopic wontfix.
[22:04] <infinity> hallyn: As for the SRUs, I don't think there's anything to "seek approval for" here, we've discussed it ad nauseum, upload something to get it reviewed.
[22:05] <infinity> hallyn: This all needs to be redundantly documented all over the effin' place, so I expect some decent README in /usr/share/doc, or maybe even a NEWS.Debian that apt-listchanges helpfully displays, plus release notes, plus blog vomit when it lands in updates, etc.
[22:05] <infinity> hallyn: Cause if people don't know about it, you've wasted your time implementing something no one will use.
[22:06] <gaughen> slangasek, infinity - could I get one of you to give some love to the maas related ffes - https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1370628 and https://bugs.launchpad.net/ubuntu/+source/psycopg2/+bug/1366104  pretty please?
[22:06] <ubot2> Launchpad bug 1370628 in maas (Ubuntu) "[FFe] MAAS New 1.7 Upstream Release" [Undecided,New]
[22:06] <ubot2> Launchpad bug 1366104 in psycopg2 (Ubuntu) "[FFe] OperationError when large object greater than 2gb" [Wishlist,New]
[22:07] <infinity> gaughen: Oh, Steve and I had a talk this morning and decided to remove MaaS from the archive.  I thought you knew?
[22:09] <gaughen> infinity, I can believe that you two possibly talked about it. I'm hoping that slangasek thought he just being funny.
[22:09] <gaughen> sorry, please insert the missing "was"
[22:09] <infinity> gaughen: Yeah, so we didn't actually discuss that at all.
[22:09] <gaughen> infinity, it was just a discussion in your own head?
[22:09] <infinity> gaughen: That said, ScottK had some serious concerns about the psycopg2 FFe.
[22:09] <infinity> gaughen: And none of that seems addressed.
[22:10] <infinity> gaughen: This also flies in the face of the "no requirements for features not in trusty" thing that was promised by the MaaS team to stgraber and I.
[22:10]  * gaughen hangs head in shame. 
[22:10] <infinity> gaughen: Which was part of the commitment to make MaaS SRUable to trusty without altering deps.
[22:10] <gaughen> I should have read that psycopg2 one first