[00:03] <slangasek> xnox: "rendering Ubuntu uninstallable in most of Quebec"?  is that an easy fix?
[00:04] <slangasek> lamont: hmm, pretty sure that's our responsibility to fix via lp:ubuntu-geonames... (see xnox's last comment on the bug)
[00:08] <stgraber> so I'm still looking at possibly unblocking rails-4.0. Looks like we need at least a new ruby-tzinfo for that.
[00:09] <stgraber> I've confirmed that the current package from Debian builds fine on saucy, it's unseeded and doesn't have a lot of rdepends
[00:09] <stgraber> Debian changelog and upstream changelogs are here: http://paste.ubuntu.com/6243106/
[00:11] <stgraber> hmm, actually let's forget about that, looking at the other missing depends, two of those aren't even in Debian
[00:13] <stgraber> I'll just remove it from proposed pocket for now since there's no chance we can possibly fix that by release and we'll just get the next version from Debian once they've sorted it there
[00:34] <wgrant> stgraber: I have sdl-{mixer,image}1.2 arm64 fixes. They're apparently on the edubuntu DVD. Thoughts?
[00:34] <stgraber> wgrant: upload, I'll let them into -proposed at least
[00:35] <wgrant> Thanks, doing
[00:41] <wgrant> thanks
[00:43] <stgraber> np
[00:51] <slangasek> stgraber: why "at least"?  We shouldn't be encouraging uploads to -proposed at this point that aren't either a) targeted to release or b) fit for SRU
[00:56] <stgraber> slangasek: we've had a couple others like that that infinity let in today. Probably with the plan that we'll either have a reason to respin tomorrow or will just move those straight to -updates.
[00:58] <slangasek> I don't think it's justifiable to push an SRU to -updates that only fixes an arm64 build
[00:59] <slangasek> but, well, maybe we wind up copying them to T instead of -updates
[01:00] <stgraber> that works too
[01:01] <stgraber> anyway, they don't really hurt being in -proposed at this point, if we need to respin we can get them in the release pocket, if we don't we can move them to T when we release
[01:03] <slangasek> yeah
[01:49] <lamont> slangasek: which website is the afflicted one?
[02:33] <slangasek> lamont: geoip.ubuntu.com, no?
[02:35] <lamont> slangasek: that one uses the geoip package, which I've updated wth the fix in -cat
[02:36] <slangasek> lamont: that's the 'geoip' source package?
[02:36] <mdeslaur> slangasek, lamont: I confirm, the server is fixed now
[02:37] <slangasek> hmm, ok then!
[02:38] <lamont> slangasek: yes, I updated the bug to also apply to the geoip package
[02:39] <lamont> which, you know, the current lts should see sometime
[02:39] <lamont> :D
[02:39] <lamont> in other news, my conversing here was prematurely interrupted by my laptop locking up.
[02:44] <wgrant> ^^ supported only, arm64 fix
[03:37] <wgrant> That's another supported-only
[03:45] <stgraber> wgrant: hmm, looks like Launchpad got quite confused by that one ;)
[03:45]  * stgraber diffs manually
[03:46] <StevenK> wgrant: That's moar arm64 fixes?
[03:48] <wgrant> stgraber: Huh, weird
[03:48] <wgrant> But thanks
[03:49] <stgraber> anyway, enough queue reviews for today. The queue currently contains 4 source packages all of which are bugfixes that are probably fine to get for release if we do end up respinning. I'll let the UK folks decide whether to accept into -proposed or keep those in the queue so that any actual critical fix can be accepted without getting those bugfixes mixed up.
[03:49] <stgraber> (they all look fine for SRU, though I didn't check if they did the paperwork or not)
[04:24] <slangasek> gnome-control-center is not a high-priority fix, it should go to SRU and the paperwork's not filed
[04:24] <ScottK> stgraber, infinity: I think lightdm can be an SRU.
[04:24] <ScottK> slangasek: ^^^
[04:25] <ScottK> Same thing with nm-applet.
[04:27] <wgrant> x264 could do with a one-liner for arm64. It's on edubuntu, kubuntu, mythbuntu, ubuntustudio.
[04:27] <ScottK> So far, I don't see anything going on that would merit a respin for Kubuntu.  I'd rather not.
[04:27] <wgrant> Sure :)
[04:28] <slangasek> ScottK: the lightdm bug is marked 'critical', I'm trying to understand the impact - lightdm will crash under some circumstances, but is this only when there are other X servers on the system that aren't managed by lightdm?
[04:31] <ScottK> That seems to be the implication.
[04:31] <ScottK> That seems rather unlikely on install though.
[04:31] <ScottK> Which is why I think it's OK for SRU.
[04:32] <slangasek> right; probably fine for a 0-day SRU to cover the upgrade case
[04:32] <ScottK> If we respin for something else, I think it's fine, but neither that nor the nm-applet fix merit a respin, IMO.
[04:33]  * slangasek nods
[05:08] <cjwatson> stgraber: I must have missed following up on ruby-arel.  Thanks.
[07:04] <wgrant> argh, sorry, didn't notice that was on edubuntu
[07:15] <doko_> if somebody wants to unblock ots, that's needed for abiword
[08:14] <infinity> cking: Are you coming in to the office to play?  Or are you here, and I just can't see you?
[08:14] <cking> infinity, sorry, I have a dr appointment that I can't avoid
[08:14] <infinity> cking: Ahh.  Fine, go worry about your health and such.  See if I care.
[08:14] <cking> heh
[08:15] <cking> is apw in  the office today?
[08:16] <apw> cking, i am in transit as they say
[08:27] <apw> is it me or is network-manager a bag of lemons the last day or so
[08:30] <jamespage> rc3's for cinder and keystone uploaded - see bug 1240254 for details
[08:30] <ubot2> Launchpad bug 1240254 in cinder (Ubuntu Saucy) "Havana rc3 tracker" [Critical,Triaged] https://launchpad.net/bugs/1240254
[08:30] <jamespage> cinder specifically is important as it addresses some upgrade issues
[08:41] <wgrant> infinity: Can I leave a couple of libs (ftgl, x264) in the queue, to be accepted if there end up being respins?
[09:06] <xnox> infinity: ^ re-fix whoopsie
[09:11] <infinity> Laney: How tested is this gnome-settings-daemon upload?
[09:13] <Laney> infinity: I tested it and two other people said it works on the bug
[09:13] <Laney> I was expecting it to be SRU though
[09:15] <Daviey> jamespage: any other saucy server uploads expected?
[09:56] <jamespage> Daviey, there maybe another maas upload - roaksoax is working towards that
[09:57] <infinity> jamespage: Pretty sure it won't make the next respin, but you can argue pretty hard for it not being forced to SRU if it's critical.  We'll see.
[09:59] <psivaa> infinity: xnox: will there be any respin for desktop with fix to bug #947107 ?
[09:59] <ubot2> Launchpad bug 947107 in ubiquity (Ubuntu Precise) "No partition labels in the resize widgets" [High,Triaged] https://launchpad.net/bugs/947107
[09:59] <xnox> psivaa: yes, among with many other things.
[09:59] <xnox> psivaa: see saucy-changes@ mailing for all the stuff recently accepted / uploaded.
[10:00] <jamespage> infinity, Daviey: looking at the maas bugs now
[10:00] <cjwatson> and I forgot to accept ubiquity ... done
[10:01] <psivaa> xnox: ack.. was not sure what required a respin
[10:03] <infinity> psivaa: Everything. :P
[10:03] <psivaa> infinity: yea i realise :)
[10:05] <Laney> If you're doing that, then you could consider g-s-d
[10:08] <Daviey> jamespage: assuming there aren't any bugs which are install or first-use critical ?
[10:12] <infinity> Laney: I'm considering it, I already asked you to tell me how well-tested it was.
[10:13] <infinity> Laney: Oh, and you answeed.
[10:13] <infinity> r
[10:21] <jamespage> Daviey, so I have a bug that is impacting juju+MAAS usage for multi-tenant maas installes
[10:21] <jamespage> bug 1239488
[10:21] <ubot2> Launchpad bug 1239488 in maas (Ubuntu Saucy) "Juju api client cannot distinguish between environments" [High,Triaged] https://launchpad.net/bugs/1239488
[10:21] <jamespage> one issue with lldp during commissioning - bug 1228085
[10:22] <ubot2> Launchpad bug 1228085 in maas (Ubuntu) "The commissioning script 00-maas-03-install-lldpd outputs to stderr." [Undecided,New] https://launchpad.net/bugs/1228085
[10:22] <jamespage> and the associated fix for bug 1229275
[10:22] <ubot2> Launchpad bug 1229275 in juju-core "[maas] juju destroy-environment also destroys nodes that are not controlled by juju" [Critical,In progress] https://launchpad.net/bugs/1229275
[10:22] <jamespage> which is the juju-core bit for bug 1239488
[10:22] <ubot2> Launchpad bug 1239488 in maas (Ubuntu Saucy) "Juju api client cannot distinguish between environments" [High,Triaged] https://launchpad.net/bugs/1239488
[10:22] <jamespage> but thats not on the ISO
[10:29] <Daviey> jamespage: So, 1) if you have more than one maas env there is an issue with juju getting confused.  2) some lldp data is potentially dropped on the floor.  They seem favourable things to have in the release iso, but not a release blocker... do you agree?
[10:30] <jamespage> Daviey, agreed
[10:31] <Daviey> jamespage: Probably a good idea to prepare an upload with these two issues cherry-picked and get it in the queue at least.
[10:31] <jamespage> Daviey, roaksoax will be up shortly; don't want to step on his toes as he's been handling maas
[10:31] <Daviey> oh yes, ok
[10:32] <jamespage> Daviey, I'll stuff the juju-core fix into the queue as soon as upstream backport it to 1.16.0
[10:32] <cjwatson> r-base must be build-dep chain for kubuntu or something, it's not actually on images
[10:33] <Daviey> jamespage: sounds good.
[10:45] <xnox> jamespage: what's up with bug https://bugs.launchpad.net/ubuntu/+bug/1216980 ?
[10:45] <ubot2> Launchpad bug 1216980 in Ubuntu "Switch cloud image signing key" [Medium,Confirmed]
[10:46] <mlankhorst> hm, s-lts-backports is going to be a bit trickier, it needs more packages for backporting. :S
[10:46] <jamespage> xnox, I'll have to ask utlemming
[10:48] <mlankhorst> llvm-toolchain-3.3 depends on cloog and isl which were not in main for precise. A new libdrm is needed again (probably copied back to saucy, raring, quantal too), a new pixman, x11proto-input and a new libxi/libxfixes.
[10:50] <ogra_> can someone let lxc-android-config^^^ into proposed please
[10:50] <mlankhorst> and the unity/unity-2d fixes for the new pointer barriers, the only user of the libxi/libxfixes changes. :P
[10:51] <ogra_> thanks !
[11:14] <doko> mlankhorst, are you serious about updating cloog and isl for precise?
[11:15] <mlankhorst> I have no idea what part of llvm needs it
[11:17] <mlankhorst> hm hm actually it seems both packages bumped sonames between the precise version and the one I copied over
[11:18] <mlankhorst> so not renaming them could work
[11:19] <cjwatson> You'd have to rename the sources
[11:20] <mlankhorst> I guess
[11:20] <mlankhorst> maybe the -dev package too, and have conflict on unrenamed
[11:20] <doko> not maybe, but defintely
[11:21] <Laney> You could probably use versioned paths
[11:23] <mlankhorst> ok so that's llvm, libdrm, cloog, isl solved. x11proto-input is just a fix to add the new pointer barrier types, should be easy too. libxfixes is a small change, libxi depends on whether we want to use the upstream version or only import the fixes, but since libxi is almost only fixes..
[11:23] <mlankhorst> that leaves pixman
[11:26] <mlankhorst> I fear renaming that is going to be awful because it's tied to libcairo2.
[11:34] <didrocks> cjwatson: do you handle the hint or should I?
[11:34] <cjwatson> I will
[11:34] <didrocks> thanks
[11:35] <infinity> I already did.
[11:35] <cjwatson> ok
[12:01] <ScottK> So why did the packages that we discussed holding for 0 day NM (lightdm and n-m-applet specifically) end up getting in?  Is there something that's going to cause everything to respin anyway?
[12:03] <cjwatson> ubiquity
[12:03] <ScottK> Ah.  That'll do it.
[12:03] <infinity> ScottK: New ubiquity causes world respin, yeah.
[12:04] <cjwatson> I think we may have forgotten that the fix there didn't affect the KDE frontend and could have gone into -updates
[12:04] <cjwatson> Sorry :-(
[12:04] <infinity> ScottK: World respin will be in the nest hour or so, when I've verified everything's just so, archive/proposed-wise.
[12:04] <infinity> s/nest/next/
[12:08] <ScottK> cjwatson: Oh well, we pick up a few other fixes that are nice to have and avoid having to mess with getting an zero day SRU right.
[12:26] <mlankhorst> can someone accept mesa-lts-raring to precise-proposed?
[12:28] <mlankhorst> and then probably accept the binaries again separately, it seems to go through NEW if there is no old package in precise or -proposed, -updates is not checked. :P
[12:36] <wgrant> xmlrpc-c isn't on any images
[12:42] <wgrant> thanks
[12:53] <didrocks> cjwatson: so, indicator-datetime here for -updates ^
[12:54] <didrocks> the 3 commits (2 bugs) have been tested in both desktop and touch (and follow the SRU process)
[12:54] <didrocks> and the commit without bug change an icon reference, but only for touch (thostr confirmed it)
[13:23] <lool> cjwatson: so autopkgtests will at least partially fail for system-image; adt-run works locally for jibel and I've tested the package myself
[13:24] <cjwatson> it can be forced given that they've never passed
[13:24] <lool> cjwatson: I would like to release ubuntu-download-manager and system-image from -proposed to saucy release if that's still possible; I guess I need a special hint to ignore the autopkgtest though?
[13:24] <cjwatson> didrocks: ok, just waiting for desktop to spin
[13:24] <didrocks> cjwatson: thanks
[13:24] <cjwatson> lool: Yeah, one you don't have permission for - I can do it
[13:24] <cjwatson> lool: What's the version number?
[13:24] <jibel> lool, and there is just a restriction to add to the test control file to make it pass on i386, still looking at amd64
[13:24] <lool> cjwatson: system-image/1.9.1-0ubuntu1
[13:24] <lool> cjwatson: ubuntu-download-manager/0.2+13.10.20131016.1-0ubuntu1
[13:26] <cjwatson> lool: I'll leave the unblocks to you
[13:26] <cjwatson> lool: I've done "force-badtest system-image/1.9.1-0ubuntu1"
[13:26] <lool> thanks
[13:32] <ScottK> I guess if Mark doesn't pick a name by tomorrow, the tech board will have to do it.
[13:32] <ScottK> Oh.  Wait ....
[13:32] <infinity> I've bugged him several times.
[13:33] <infinity> I say we call it tenacious techboard.
[13:33] <ScottK> I like toxic tuna better.
[13:34] <infinity> cking had a winner yesterday...
[13:35] <infinity> Ahh, yes.  Tactile Tapeworm.
[13:35] <cking> i guess now that is public it counts it out
[13:36] <infinity> cking: Pretty sure that wasn't the only reason to discount it.
[13:36] <utlemming> xnox: in regards to bug 1216980, I am waiting on IS to upload a signed public key
[13:36] <ubot2> Launchpad bug 1216980 in Ubuntu "Switch cloud image signing key" [Medium,Confirmed] https://launchpad.net/bugs/1216980
[13:36] <cjwatson> they have the signed material, certainly
[13:37] <cjwatson> specifically elmo has a USB stick with it on
[13:37] <cjwatson> but I thought that had been delivered to you ages ago
[13:38] <utlemming> cjwatson: elmo wanted to verify the purpouse, I did, but it just hasn't been uploaded yet.
[13:46] <cjwatson> utlemming: have prodded in person
[13:46] <wgrant> Could someone please exempt fatrat, protobuf-c, xmlrpc-c from the freeze block? All built, unseeded, build-deps for arm64 stuff in release.
[13:46] <utlemming> cjwatson: :) thank you kindly
[13:47] <jcastro> hey so I noticed the juju section of the release notes are skeletonish, someone mind if I fill them in?
[13:47] <cjwatson> jcastro: goferit
[13:54] <infinity> jcastro: Please do.
[13:54] <infinity> jcastro: If you have things to say about any other part of the release, fill those in too. :)
[14:08] <ScottK> So how to I test upgrades at the moment using do-release-upgrade?  There is neither a new non-devel release nor a devel release apparently.
[14:09] <smartboyhw> ScottK, you are testing from 13.04?
[14:09] <ScottK> Yes
[14:09] <ScottK> Both -d and not -d claim there's no new release available.
[14:10] <infinity> wgrant: On it.
[14:11] <wgrant> infinity: Thanks
[14:14] <jpds> ScottK: 'update-manager -d' worked for me yesterday.
[14:14] <ScottK> Worked for me over the weekend too.
[14:17] <infinity> I don't see any reason why it wouldn't work...
[14:17] <infinity> meta-release-development looks sane.
[14:17] <infinity> And not recently changed.
[14:18] <ScottK> I think I figured it out.
[14:18] <infinity> Something we need to worry about?
[14:18] <ScottK> Nope.
[14:18] <ScottK> Funky local setup from a test I did last cycle and forgot about.
[14:18] <ScottK> Sorry for the noise.
[14:18] <infinity> (Also, don't panic, but we'll need another set of respins on top of the ones currently happening, that ubiquity upload has a regression we're hunting right now)
[14:18] <ScottK> Sigh.
[14:19] <infinity> Still, do test and let us know if you find any other show-stoppers.
[14:19] <infinity> The bug should only affect side-by-side installs, everything else should be fine.
[14:19] <ScottK> Is it in the Ubuntu front end or a back end issue?
[14:19] <psivaa> xnox: i dont see 'Install Now' being enabled on the side-by-side setup
[14:19] <infinity> Probably just the GTK frontend.
[14:20] <infinity> psivaa: That's the bug I just referred to, we're working on it.
[14:20] <ScottK> If it's just the front end, can it go to updates?
[14:20] <psivaa> infinity: ack
[14:20] <infinity> ScottK: I'd really prefer not to have ubiquity/oem-config out of sync on different images.  If you test the current one thoroughly, a smoketest of the next should be enough.
[14:20] <cjwatson> It is just the front end
[14:21] <cjwatson> (This is https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1240532)
[14:21] <ubot2> Launchpad bug 1240532 in ubiquity (Ubuntu) "side by side install mode had disable back and install buttons" [Critical,Confirmed]
[14:21] <infinity> I've never grasped the idea that people feel they need to end-to-end re-test for every small change.
[14:22] <ScottK> We got through all the tests yesterday, so if we're going to retest, I'd rather it be the final.
[14:23] <infinity> ScottK: Well, you could do light/no testing on the current image and wait for us to fix this, then.  We're hunting quickly.
[14:23] <infinity> ScottK: And I can rebuild kubuntu first.
[14:24] <infinity> (Yes, we COULD do the updates thing, but it just seems like a bit of a hack/lie for very little real benefit, when one can just re-test the bits they know/suspect have changed)
[14:25] <ScottK> infinity: OK.  Let me know when it's getting close.  I'm checking with the rest of the team to see if there's anything that popped up in testing we can/should fix.
[14:26] <infinity> ScottK: *nod*... Colin's applying his giant brain to the problem, shouldn't be too long, I hope.
[14:27] <cjwatson> I'm rather hoping xnox will beat me to figuring it out ...
[14:27] <cjwatson> I'm mostly being a bisect-monkey
[14:36] <xnox> cjwatson: infinity: apw: http://paste.ubuntu.com/6245933/
[14:38] <plars> xnox: I still hit bug #1154345 and bug #1231091 with the screenreader tests
[14:38] <ubot2> Launchpad bug 1154345 in ubiquity (Ubuntu) "Orca announces status of each steps' progress dot" [Low,Confirmed] https://launchpad.net/bugs/1154345
[14:38] <ubot2> Launchpad bug 1231091 in ubiquity (Ubuntu) "Screenreader starts, but quits working in live session on install" [Undecided,New] https://launchpad.net/bugs/1231091
[14:38] <didrocks> cjwatson: maybe if another respin is coming, we can get indicator-datetime in?
[14:38] <didrocks> (just backlogging)
[14:38] <infinity> didrocks: Probably, yes.
[14:38] <infinity> didrocks: I'll assess that when we're ready.
[14:39] <didrocks> sure, as long as it's either in the release pocket or -update by tomorrow morning (EU time), I'm fine :)
[14:39] <infinity> plars: Those probably can't be fixed before release at this point. :/
[14:39] <didrocks> thanks
[14:40] <plars> infinity: they are probably release notable, the screen reader not working at all in ubiquity is pretty bad and the more critical one but can be worked around by selecting screen reader from the f5 menu on boot
[14:40] <mlankhorst> can someone accept mesa-lts-raring?
[14:40] <infinity> plars: Feel free to add things to the release notes, it's a wiki for a reason.
[14:40] <plars> infinity: this would require sighted help most likely though, whereas the ctrl-s option on boot could probably be done pretty easily without
[14:41] <infinity> plars: Yeah, I'm not arguing that it's not a pretty crap bug, just that we've run out of time to sort it out, I think, given the relative potential complexity.
[14:41] <plars> infinity: I know
[14:46] <ScottK> Sigh.  do-release-upgrade -d still not working here.  There isn't a cache somewhere is there?
[14:47] <ScottK> Yes.  There is.
[14:47] <ScottK> Now I think I got it.
[14:54] <cjwatson> there is muted swearing coming from the war room
[14:54] <infinity> didrocks: Err, dude.  No.  This indicator-datetime adds a Recommends on click, which pulls it into ubuntu-desktop.
[14:55] <didrocks> infinity: urgh, really? I don't remember I was pinged with the packaging diff before sil2100 published
[14:55] <didrocks> (so assumed no packaging diff)
[14:56] <infinity> didrocks: Rejected.
[14:56] <infinity> didrocks: If you get me a fresh upload ASAP, I can try to get it in the next spin.
[14:56] <infinity> didrocks: If not, well.  Not so much. ;)
[14:57]  * didrocks checked his backlog
[14:57] <didrocks> sil2100: so, please, pay real attention before publishing a stack with the .diff files when there are packaging diff
[14:57] <didrocks> they are there for a reason (and blocking the automated publisher as well)
[14:57] <didrocks> infinity: fixing it
[14:57] <infinity> didrocks: Thanks.
[14:58] <sil2100> I was sure there was no packaging diff after doing the before-force-release
[14:58] <infinity> sil2100: This was your diff: http://paste.ubuntu.com/6246038/
[14:58] <sil2100> infinity: damn, then probably I didn't have the cu2d page properly refreshed or something
[14:59] <sil2100> infinity: sorry about that
[15:00] <stgraber> note that adding click as a recommends really really doesn't make any sense since touch doesn't install recommends anyway ;)
[15:03] <stgraber> I'm diffing those 3 syncs in the queue (to save anyone else the trouble)
[15:03] <stgraber> all 3 are seeded by all flavours based on ubuntu-desktop
[15:04] <kenvandine> stgraber, the signon ones?
[15:04] <kenvandine> i was about to ping cjwatson about those
[15:04] <stgraber> signon-ui, libaccounts-glib and libaccounts-qt
[15:04] <kenvandine> it's an important fix for touch, but some overlap with desktop
[15:04] <stgraber> right, which means we'd have to respin desktop for it
[15:04] <kenvandine> just for -updates
[15:04] <kenvandine> not critical to get it in the desktop image
[15:05] <kenvandine> but an SRU
[15:05] <infinity> We have a desktop respin coming anyway, if we decide this is low-impact enough to allow it.
[15:05] <kenvandine> fine with me :)
[15:05] <stgraber> then you'll need the SRU paperwork done for those
[15:05] <kenvandine> we just need it for touch
[15:05] <doko> kenvandine, does signon-ui have the arm64 fix?
[15:05] <stgraber> though we may still have a respin coming, from what i got from backlog
[15:05] <stgraber> right, I'll check how scary they are
[15:05] <infinity> Also, the "just put it in updates" thing isn't as catch-all as people think it is, as we have to DELETE it from updates if we want to respin desktop without it. :P
[15:05] <kenvandine> doko, arm64 fix?
[15:05] <cjwatson> kenvandine: don't ping me right now, I'm dealing with ubiquity
[15:05] <cjwatson> incomprehensible gtk weirdness
[15:05] <kenvandine> cjwatson, i won't then :)
[15:06] <kenvandine> stgraber, bug 1234282
[15:06] <ubot2> Launchpad bug 1234282 in ubuntuone-credentials (Ubuntu) "It's possible to add more than one U1 account from system settings on the phone" [Undecided,New] https://launchpad.net/bugs/1234282
[15:06] <stgraber> cjwatson: I'm dealing with kenvandine's request
[15:06] <doko> kenvandine, https://bugs.launchpad.net/ubuntu/+source/signon-ui/+bug/1239743
[15:06] <ubot2> Launchpad bug 1239743 in signon-ui (Ubuntu T-series) "don't limit the architecture to a fixed set" [High,Confirmed]
[15:07] <kenvandine> ah, we can fix that now
[15:07] <kenvandine> but i guess not important for 13.10
[15:07] <kenvandine> doko, i'll propose a fix to trunk though
[15:07] <doko> thanks
[15:07] <cjwatson> you can certainly do that since qtdeclarative5-dev is unavailable on powerpc, so signon-ui will already not build there with no problem
[15:07] <kenvandine> stgraber, ubuntuone-credentials goes with those too
[15:08] <stgraber> kenvandine: so I have a hard time seeing the relation between signon-ui and that bug ;)
[15:08] <kenvandine> and ubuntu-system-settings-online-accounts
[15:08] <kenvandine> haha
[15:08] <kenvandine> yeah, i thought that fix had already landed
[15:08] <stgraber> kenvandine: the diff is: http://paste.ubuntu.com/6246080/
[15:08] <kenvandine> so you can reject signon-ui if you like... but it only affects touch
[15:08] <kenvandine> that code doesn't even run on the desktop
[15:08] <kenvandine> at least not the qml bits
[15:09] <stgraber> yeah, I'll let it in and we'll grab it with the next respin
[15:09] <kenvandine> although, i would like that fix for touch
[15:09] <kenvandine> thanks
[15:09] <stgraber> the fact that we don't use the code on desktop doesn't matter. We don't release with out of date packages on the media
[15:09] <kenvandine> understand
[15:09] <stgraber> so any change to a seeded package in the releaes pocket means a rebuild whether it's a visible change or not
[15:10] <kenvandine> just risk is low
[15:10]  * infinity nods.
[15:10] <infinity> I like low risk.
[15:10] <kenvandine> indeed :)
[15:10] <stgraber> infinity: do you keep a list of things to include in the respin somewhere or should I just push an unblock hint now and hope we'll wait long enough?
[15:17] <stgraber> kenvandine: hmm, those two libaccounts changes are technically feature additions...
[15:17] <kenvandine> well, adds some API to allow that bug to be fixed
[15:18] <kenvandine> without that, they couldn't limit the U1 accounts
[15:18] <kenvandine> and U1 doesn't support multiple accounts
[15:18] <stgraber> what's the actual user visible effect of --disable-wal?
[15:18] <infinity> stgraber: Leave them in proposed, and I'll unblock everything we want in the same cycle as the new ubiquity.  Much easier to keep track when the list is "what's in proposed".
[15:19] <infinity> stgraber: It also means that we can still change our mind.  Once something is promoted, we're committed.
[15:20] <stgraber> infinity: ok
[15:20] <kenvandine> infinity, i don't think there is any user visible affect, but i think it fixes a bug on the read-only images
[15:20] <kenvandine> or potential bug
[15:21] <stgraber> hmm, ok. Let's hope you're right. Accepting those two.
[15:21] <kenvandine> stgraber, we've been testing that for at least a week out of the daily builds ppa :)
[15:22] <stgraber> wgrant: double upload?
[15:22] <kenvandine> stgraber, actually, i think use --disable-wal means it's no change for us... but more of a friendly upstream change so other platform can use it
[15:22] <wgrant> stgraber: Yeah, oops. Can you reject the remaining one?
[15:22] <kenvandine> we fixed something in that area, and intel or someone wasn't happy
[15:22] <kenvandine> s/wasn't happy/affected by/
[15:23] <stgraber> wgrant: yep, done. That caused the auto-accept script to crash, I'll have to make it deal with the can't accept case :)
[15:23] <kenvandine> stgraber, thanks!
[15:24] <wgrant> stgraber: Heh. Sorry.
[15:28] <stgraber> infinity: what happened to curtin? just noticed the saucy-changes e-mail showing ubuntu/saucy instead of saucy-proposed and no changes available :)
[15:31] <infinity> stgraber: Double-override incident, lost half the binaries. :P
[15:31] <stgraber> ok :)
[15:31] <infinity> stgraber: So had to copy it back over itself.
[15:32] <stgraber> hmm, what happened with epiphany-browser... we didn't have that one on c-m yesterday...
[15:32] <cjwatson> it's arm64 not having a better www-browser provider
[15:32] <cjwatson> ignore it for now
[15:33] <infinity> stgraber: Yeah, ignore it.
[15:33] <stgraber> ok
[15:33] <doko> infinity, openmpi1.6 built, please unblock
[15:33] <infinity> doko: You're not planning to transition mpi-defaults, I hope?
[15:34] <doko> infinity, did you count the rdeps?
[15:34] <infinity> doko: Cause I don't think that's even remotely sane.
[15:34] <doko> na, will prepare for to open the t-series
[15:34] <doko> coffe ...
[15:35] <infinity> Kay, that's slightly more sane. :)
[15:35] <infinity> doko: Want to stage some of that in a PPA?  I can give you arm64 on one of the toolchain-r PPAs.
[15:36] <doko> infinity, let's use the buildds for other builds for now
[15:36]  * infinity nods.
[15:36] <doko> both lam and openmpi are untested
[15:36] <infinity> Untested hasn't stopped us so far with this port!
[15:37]  * infinity does one last refresh of xubuntu-meta to squeeze in before the last respin.
[15:37] <wgrant> I tested varnish!
[15:37] <wgrant> It failed, but still. Thought counts.
[15:38] <doko> infinity, will this include a browser?
[15:40] <infinity> doko: No.  Who needs one of those?
[15:40] <stgraber> lool, didrocks: we have a bunch of touch packages stuck in proposed: accounts-qml-module, mediaplayer-app, ofono, ubuntu-system-settings-online-accounts, ubuntuone-credentials and unity-mir
[15:40] <infinity> doko: It'll be missing exactly the same packages that are missing on ubuntu-desktop (thunderbird, firefox, and transmission)
[15:41] <ogra_> stgraber, i jjust hinted ofono
[15:41] <didrocks> stgraber: I'm doing unity-mir
[15:41] <didrocks> mediaplayer done 10 minutes ago
[15:41] <stgraber> ok
[15:41] <didrocks> for the u1 thing, I pinged kenvandine twice :)
[15:41] <lool> didrocks: what's with ofono?
[15:42] <lool> didrocks: and accounts-qml-module?
[15:42] <didrocks> lool: ogra talked about ofono
[15:42] <didrocks> that he hinted it
[15:42] <didrocks> please look ^
[15:42] <didrocks> lool: the rest is on ken's plate
[15:43] <ogra_> lool, ofono is the GPRS fix, landing 254
[15:49] <lool> ah right missed that line
[15:50] <lool> hinted location-service in; just a respawn added to upstart job
[15:52] <lool> why does this have kubuntu packageset?
[15:52] <lool> or ubuntu-desktop
[15:52] <lool> I forgot the branch that cjwatson patched last time
[15:52] <lool> cjwatson: Mind checking the origin of the packagesets for this one?
[15:53] <cjwatson> lool: later please
[15:54] <kenvandine> stgraber, i hinted the touch only packages, are you looking at the SRU bug for libaccounts-glib and libaccounts-qt?
[15:54] <infinity> lool: libubuntu-application-api1
[15:54] <lool> infinity: Would you mind reviewing it?
[15:55] <infinity> Looking.
[15:55] <stgraber> kenvandine: we'll probably just take those in with the next respin but we're keeping them into -proposed until then
[15:55] <kenvandine> stgraber, thanks
[15:57] <stgraber> ah, sorry, didn't see infinity was already on it, I accepted location-service
[15:57] <infinity> stgraber: So did I...
[15:58] <stgraber> well, at least we agree :)
[15:58] <lool> stgraber: thanks
[16:17] <didrocks> infinity: here we go ^
[16:20] <infinity> didrocks: To be fair, I'm not sure why that would even be a suggests, but it's harmless, I guess.
[16:20] <infinity> didrocks: Having packages depend/recommend/suggest a package manager is just strange.
[16:20] <didrocks> infinity: upstream has strong feeling, I just gave up on that battle
[16:21] <infinity> didrocks: Upstream's feeling is wrong, according to the click author.  Just sayin'. :P
[16:23] <didrocks> infinity: would it be the first time? ;)
[16:23] <ogra_> for click most likely
[16:23] <ogra_> :)
[16:28] <bdmurray> infinity: I'm going to release the gnome-settings-daemon in precise-proposed (fixing bug 1236752) early as it just removes the patch from the previous SRU.  Sound good?
[16:28] <ubot2> Launchpad bug 1236752 in gnome-settings-daemon (Ubuntu Precise) "gnome-settings-daemon (3.4.2-0ubuntu0.6.3) breaks nvidia multi-monitor-config" [Critical,Fix committed] https://launchpad.net/bugs/1236752
[16:29] <infinity> bdmurray: Seems reasonable.
[16:29] <Laney> Good stuff
[16:29] <Laney> They came back with a revised patch for the original SRU
[16:29] <seb128> Laney, thanks for dealing with that buggy SRU
[16:30] <Laney> np
[16:35] <ScottK> Should the Saucy Daily milestone be disabled in the tracker?
[16:37] <Laney> Nope, that's where the images are publishing to in addition to Final
[16:40] <xnox> cjwatson: apw: infinity: http://paste.ubuntu.com/6246499/
[16:42] <plars> infinity: what's the ETA on the respins?
[16:44] <infinity> plars: We have a fix we're testing right now, so "soon".
[16:44] <plars> infinity: and server too?
[16:45] <infinity> plars: Server will need respinning too, so the oem-config version matches.
[16:45] <infinity> plars: (And some other bits)
[16:53] <cjwatson> god, what a day
[16:55] <ogra_> yeah, feels like a day before release
[17:01] <stgraber> infinity: what the current fix? (I'm still poking at the code here)
[17:06] <plars> yeah, it's like 6 months ago all over again
[17:08] <infinity> stgraber: http://paste.ubuntu.com/6246499/
[17:08] <infinity> stgraber: Oh, or the thing that just hit the queue.
[17:08] <cjwatson> plars: and it was going so well
[17:10] <stgraber> infinity: do you have anyone reviewing this on your end or should I take care of the queue review?
[17:10] <cjwatson> stgraber: infinity's doing it
[17:10] <stgraber> ok
[17:10] <infinity> stgraber: My review is pending one more test here.
[17:13] <stgraber> infinity: in case you wanted one more confirmation, I just tried the fix here and it seems to work fine (ubiquity is now resizing my previous install)
[17:14] <infinity> stgraber: Which flavour did you test?
[17:14] <stgraber> infinity: standard ubuntu 64bit
[17:14] <zul> can someone unblock keystone please and thanks
[17:14] <infinity> zul: Already done.
[17:14] <zul> thanks
[17:17] <xnox> apw: http://github.com/lwfinger/rtl8723au
[17:18] <stgraber> hmm, just had a post-install problem here...
[17:18] <stgraber> that system had 12.04.3 installed (clean install done an hour ago), then installed saucy alongside it
[17:19] <stgraber> rebooted post-install and I get a grub shell
[17:23] <xnox> apw: cjwatson: http://paste.ubuntu.com/6246735/
[17:28] <cjwatson> stgraber: bios/uefi?
[17:28] <stgraber> cjwatson: bios
[17:28] <cjwatson> kind of running out of steam here, any diagnosis you could do would be helpful
[17:28] <cjwatson> xnox beat me to the fix but we've both been staring at that code for several hours
[17:29]  * cjwatson lets his current test install run to completion to see what it does
[17:30] <stgraber> cjwatson: so from the grub shell, sourcing /boot/grub/grub.cfg doesn't do anything (trying source + normal), however doing the same thing with the existing 12.04 config works...
[17:30] <stgraber> rebooting now to check exactly what version of grub I'm booting
[17:31] <stgraber> hmm, it's 2.00-19ubuntu2... so that should be fine
[17:31] <cjwatson> sort of thing that could happen with mismatched kernel/modules/config
[17:31] <cjwatson> check prefix
[17:31] <stgraber> (hd0,msdos6)/boot/grub so that's the /boot of the saucy system
[17:31] <stgraber> what I don't get is that "load (hd0,msdos6)/boot/grub/grub.cfg" doesn't appear to do anything...
[17:32] <stgraber> *source
[17:32] <cjwatson> load is not a grub command I'm familiar with
[17:32] <cjwatson> ah
[17:32] <cjwatson> try configfile
[17:32] <stgraber> same result as source, doesn't do any of the usual change (the most visible one would be the background color changing) and calling "normal" doesn't get me a menu or anything
[17:33] <stgraber> hmm, hold on a sec, now that's weird
[17:33] <stgraber> cat (hd0,msdos6)/boot/grub/grub.cfg brings a whole lot of <0> on a grey background which I suspect is a rather bad sign.
[17:33] <stgraber> doing the same on (hd0,msdos0) (precise system) gives me the expected grub.cfg content
[17:33]  * stgraber boots to triple-check that grub.cfg isn't corrupted somehow
[17:34] <cjwatson> could be a strange edge case in a filesystem module
[17:35] <stgraber> reading the file from the booted OS is fine
[17:37] <kenvandine> stgraber, do you think we cat get libaccounts-glib, libaccounts-qt and signon-ui in the release pocket (or maybe -updates) by 00 UTC?  We need them to get picked up in ogra_'s next touch image spin
[17:37] <stgraber> fsck -f didn't find anything wrong with the filesystem, so that seems to confirm it'd be grub related
[17:37] <stgraber> kenvandine: we seem reasonably close to a respin, so that's probable
[17:38] <kenvandine> great, thanks
[17:39] <stgraber> cjwatson: want me to save you a copy of that VM?
[17:39] <slangasek> stgraber: if you reboot to grub after having booted, do you get the same result still?
[17:39] <stgraber> slangasek: yep
[17:39] <cjwatson> stgraber: mm, yeah, maybe
[17:39] <slangasek> ok, so it's not like booting cleared the journal or something and made grub happy
[17:40] <stgraber> I'll save the VM, make a very compressed version of it and do another identical install see if it's easily reproducible (shouldn't be...)
[17:41] <cjwatson> jamespage: can you confirm that the server team knows that their images no longer fit on CDs (this is the first release that's the case for !armhf) and that this is OK?
[17:43] <ogra_> stgraber, was that a "yes put it in the release pocket"
[17:43] <stgraber> ogra_: no
[17:43]  * ogra_ has no clue if touch builds actually work from -updates
[17:43] <cjwatson> They do.
[17:43] <ogra_> afaik we never tested that before
[17:43] <ogra_> ok
[17:43] <cjwatson> You can see in the livefs logs that they're configured to fetch from it.
[17:44] <stgraber> ogra_: that was a, infinity will very likely move it to the release before the respin
[17:44] <stgraber> *them
[17:44] <cjwatson> (I checked a couple of weeks ago.)
[17:44] <ogra_> oh, so i dont even need to do anythign ?
[17:44] <ogra_> wow
[17:44] <cjwatson> Should Just Work
[17:44] <ogra_> you rock !
[17:44] <cjwatson> Not sure I did anything either :)
[17:46] <cjwatson> smoser: ^- Maybe you can answer my question to jamespage above about image sizing?
[17:47] <smoser> hm.. i didn't know that. maybe jamespage did.
[17:47] <smoser> that seems less than ideal.
[17:48] <cjwatson> Nobody from the server team is on the server image failure notification list, otherwise you'd have been being mailed about this for some time
[17:49] <stgraber> cjwatson, xnox: It doesn't appear to be possible to exit Ubiquity... (The Quit button is clickable but doesn't do anything)
[17:49] <cjwatson> I'd say that's file-a-bug but not respin-worthy
[17:50] <cjwatson> my Lubuntu install test with xnox's ubiquity patches booted fine FWIW
[17:50] <smoser> cjwatson, well, what options do we have here.
[17:50] <cjwatson> I think you have another respin, you could rip ~30MB worth of stuff out real quick if you can find it
[17:51] <cjwatson> Do you need ipxe?  That's 48MB
[17:52] <cjwatson> You could drop the openssl and openvpn blacklists from the security advisory five years ago
[17:52] <cjwatson> That would gain about 14MB
[17:53] <smoser> k. i'll dig a bit
[17:54] <cjwatson> I think I might drop the blacklists anyway - those seem like obvious wins
[17:54] <cjwatson> if you're fine with that?
[17:54] <cjwatson> jdstrand: ^-
[17:55] <smoser> cjwatson, am i reading this wrong?
[17:55] <smoser> oh.
[17:55] <cjwatson> I don't know, are you? :)
[17:55] <smoser> you did openssh-blacklist-extra not openssl-blacklist-extra (ssh versus ssl)
[17:55] <cjwatson> yeah
[17:55] <smoser> i was reading it wrong
[17:56] <smoser> i love verbose commit messages
[17:56] <smoser> message:
[17:56] <smoser>   Add ipxe
[17:57] <stgraber> cjwatson: hmm, that's really quite worrying... I just did another similar install (12.04.3 then 13.10 with resize) and this time I get into grub rescue with a failure to read /boot/grub/i386-pc/normal.mod
[17:57] <cjwatson> wtf
[17:57] <cjwatson> in a vm?
[17:57] <stgraber> yep
[17:57] <cjwatson> i386 or amd64?
[17:57] <stgraber> amd64
[17:57] <cjwatson> both?
[17:58] <stgraber> yep
[17:58] <cjwatson> and both server, or desktop?
[17:58] <stgraber> both desktop
[17:58] <jdstrand> cjwatson: you are talking about server-ship and dropping openssl-blacklist-extra?
[17:58] <stgraber> 6d7cba5726392c2fe16588fac3ebfcde  Desktop/saucy-desktop-amd64.iso
[17:58] <stgraber> e2da0d5ac2ab8bedaa246869e30deb71  Desktop/ubuntu-12.04.3-desktop-amd64.iso
[17:59] <cjwatson> jdstrand: yes, and openvpn-blacklist
[17:59] <stgraber> cjwatson: the only non-standard features of that VM is the use of a virtual SATA drive (instead of virtio) and having two network cards (both e1000 so also not virtio)
[17:59] <cjwatson> (and openssl-blacklist, by dependency)
[17:59] <infinity> stgraber: How did you get that saucy one to install side-by-side at all?  That page in ubiquity is broken...
[17:59] <cjwatson> network card unlikely to matter.  so if I just use qemu -hda t.img?
[17:59] <jdstrand> cjwatson: I definitely don't have a problem with openssl-blacklist-extra. let me look at openvpn real quick
[18:00] <stgraber> infinity: applying your pastebin
[18:01] <stgraber> cjwatson: that was under libvirt so it had a ton of fancy parameters, let me try to reproduce with a minimal kvm command line
[18:02] <cjwatson> I'll try with my usual kvm setup
[18:02] <smoser> cjwatson, ok. so https://bugs.launchpad.net/ubuntu/+source/ipxe/+bug/800340 is reported as to why ipxe is in server-ship.
[18:02] <ubot2> Launchpad bug 800340 in ipxe (Ubuntu) "[MIR] ipxe" [Undecided,Fix released]
[18:02]  * nlsthzn loves to type in random channel names and then find they actually exist :)
[18:02] <jdstrand> cjwatson: yes, openvpn-blacklist is fine too
[18:02] <smoser> i dont have a reason as to why we'd want it on the cd itself.
[18:02] <cjwatson> smoser: that's a reasonable argument for main, but no argument at all for server-ship
[18:02] <cjwatson> smoser: in fact it didn't need to be explicitly seeded at all if it's a build-dep
[18:03] <smoser> cjwatson, agreed.
[18:03] <smoser> so i think drop it. and if that is a magic bullet, then whoohooo
[18:03] <cjwatson> smoser: though xen just b-ds on ipxe-qemu not ipxe
[18:04] <smoser> is that specifically relevant here ?
[18:04] <cjwatson> smoser: so you should probably move ipxe to supported just because I don't want to change that at this point
[18:04] <cjwatson> otherwise the ipxe binary will fall out of main
[18:04] <smoser> ah.
[18:04] <smoser> ok. yeah. agreed.
[18:04] <cjwatson> I'll drop the blacklists as well, may as well have headroom
[18:05] <smoser> you handle ipxe or you want me to
[18:05] <smoser> thank you
[18:06] <cjwatson> In fact if we do both I think that gets even powerpc undersize too
[18:07] <cjwatson> smoser: If you could, that'd be great
[18:08] <smoser> should i laev the  [!powerpc]
[18:08] <smoser> ?
[18:08] <smoser> i suspect so
[18:09] <infinity> smoser: For ipxe?
[18:09] <cjwatson> smoser: makes no difference, drop it
[18:09] <cjwatson> that was just for CD sizing
[18:10] <cjwatson> it'd be clearer to lose it
[18:10] <cjwatson> yeah, if ipxe wasn't on powerpc it's not going to get powerpc undersize :)
[18:10] <cjwatson> but whatever
[18:10] <smoser> pushed
[18:13] <stgraber> cjwatson: failed to reproduce under standard kvm
[18:15] <xnox> stgraber: and the libvirt host is saucy?
[18:15] <cjwatson> I think we won't block respins for it then
[18:15] <xnox> stgraber: or precise?
[18:15] <stgraber> xnox: saucy
[18:16] <xnox> ok.
[18:16] <stgraber> cjwatson: booting that same VM in libvirt gets me into a grub shell though...
[18:16] <cjwatson> uh
[18:17] <cjwatson> "blame libvirt" doesn't scan to "blame Canada"
[18:17] <stgraber> so I just need to figure out what parameters to pass kvm so that it does sata instead of ide and see if that fails too
[18:17] <cjwatson> -drive file=blah,if=scsi ?
[18:18] <cjwatson> however I don't recall whether that lets you boot
[18:18] <stgraber> if=sd I think but yeah, something along those lines
[18:18] <xnox> stgraber: did you somehow modify the libvirts bootloader, like redirect to tianocore by any chance?
[18:18] <xnox> (as per sb / vm testing?)
[18:18] <stgraber> xnox: nope, that's my bios vm, not my uefi vm
[18:18] <xnox> stgraber: well that's not normal libvirt now is it, if it supports uefi boots as well.
[18:19] <slangasek> cjwatson: it doesn't scan, but thanks for getting that song stuck in my head ;)
[18:19] <cjwatson> yw
[18:19] <cjwatson> also: ring ring ring ring ring ring ring, BANANAPHONE
[18:20] <cjwatson> Possibly I should eat something
[18:20] <stgraber> cjwatson: that does the trick here: kvm -device ahci,id=ahci0,bus=pci.0,addr=0x4 -drive file=/home/stgraber/data/vm/test.img,if=none,id=drive-sata0-0-0,format=raw -device ide-hd,bus=ahci0.0,drive=drive-sata0-0-0,id=sata0-0-0
[18:21] <davmor2> cjwatson: You're not that far away I'm sure I can tie you to a chair and play beiber at you ;)
[18:21] <cjwatson> So maybe kvm isn't implementing the usual BIOS disk access methods in which case you may or may not lose
[18:21] <stgraber> cjwatson: exact same thing testing on all 3 disk images I have, (hd0,msdos1)/boot/grub/grub.cfg is readable, (hd0,msdos1)/boot/grub/grub.cfg isn't
[18:22] <stgraber> well, how would that explain the grub.cfg from precise being readable while the one from saucy isn't?
[18:22] <cjwatson> I assume the second is (hd0,msdos6)
[18:22] <cjwatson> Maybe it goes over some limit like the CHS one?
[18:22] <stgraber> gah, yeah, msdos6
[18:22] <davmor2> cjwatson: what we should of had was http://www.youtube.com/watch?v=ykwqXuMPsoc
[18:22] <cjwatson> Bet if you do the installs the other way round you get the same thing
[18:23] <cjwatson> davmor2: I'll pass :)
[18:23] <stgraber> would have to test that. If it goes over a limit, it must be by just a tiny bit since it can still load its modules and I can read random files from /boot, just not grub.cfg
[18:23] <cjwatson> grub.cfg will be generated much later - it won't be near the modules
[18:23] <cjwatson> well, maybe
[18:24] <stgraber> the kernel config is readable but /var doesn't appear to be, so yeah, looks like you're right
[18:24] <cjwatson> how big is the disk?
[18:24] <stgraber> 50GB
[18:25] <cjwatson> what sector is grub.cfg at?
[18:25] <cjwatson> There's a grub command for this if I can remember it
[18:25] <cjwatson> blocklist (hd0,msdos6)/boot/grub/grub.cfg
[18:27] <stgraber> 34368104+18,34368122[0-65]
[18:27] <cjwatson> damn that's offset relative to the start of the partition
[18:28] <stgraber> data/vm/test.img6        55640064   100665343    22512640   83  Linux
[18:28] <cjwatson> "ls" should print the offsets
[18:28] <cjwatson> I'd like it from GRUB just to make sure the units match up
[18:28] <stgraber> Partition start at 55640064 - Total size 45025280 sectors
[18:31] <cjwatson> stgraber: you said "it can still load its modules", but earlier you cited a failure to load /boot/grub/i386-pc/normal.mod
[18:31] <cjwatson> stgraber: can you get the blocklist of a module file that is readable?
[18:32] <stgraber> cjwatson: I only had the failure to read normal.mod happen once so far, failure to read grub.cfg seems very consistent (happened on 5 installs)
[18:33] <stgraber> cjwatson: normal.mod is at 8884240+215,8884455[0-144]
[18:33] <cjwatson> the most plausible of the traditional limits here is the 33.8GB limit
[18:34] <cjwatson> i.e. >65535 cyls
[18:34] <cjwatson> maybe libvirt is using a really crappy ancient bios
[18:34] <cjwatson> or kvm or whatever
[18:34] <cjwatson> your normal.mod blocklist is under that, grub.cfg well over
[18:39] <stgraber> cjwatson: ok, good, so not a critical issue. Looking around any path I expect to be touched late during install is missing (all of /var is)
[18:42] <cjwatson> Yeah, it's probably not new despite initial presentation
[18:42] <stgraber> my VMs are usually 10GB large, and I think I was using SATA on that one instead of virtio because I tried to run freebsd at some point
[19:04] <kanor> a
[19:42] <kanor> I not understand how the directories EFI, pics, install… and the files wubi.exe, autorun.inf in the release ISO  file is generated.
[19:42] <kanor> explication, thank
[19:53] <stgraber> infinity, cjwatson: so are we still blocked on something before rebuilding for ubiquity?
[20:09] <plars> psivaa, xnox: bug #1240683 is the bug I hit with ubuntu one login in ubiquity
[20:09] <ubot2> Launchpad bug 1240683 in ubiquity (Ubuntu) "Ubuntu one login during install hangs" [Undecided,New] https://launchpad.net/bugs/1240683
[20:25] <cc11rocks> I know that a time won't be said on the release of Ubuntu Desktop, but approximately how many hours will it be before it is released (I can use it tomorrow if it is ready in a certain amount of hours)?
[20:26] <stgraber> we still have quite a bit to do, so it may still be a while (and no, I won't get into any more details)
[20:27] <cc11rocks> Okay, thanks stgraber. Hopefully, it's done by the time I have to leave :)
[21:10] <infinity> stgraber: Those Ubuntu builds above where you asked are already with the new ubiquity.
[21:12] <stgraber> infinity: yeah, I figured as much when I saw a bunch more stuff show up. I did have a quick look at nusakan before I asked but must have missed the build command (since the python rewrite, the ps output is so short, it's hard to figure out something's going on ;))
[21:12] <infinity> How did that neutron migrate to release without britney claiming it could?
[21:12] <stgraber> my reading of saucy-changes suggests someone manually copied it over
[21:13] <cjwatson> !
[21:13] <stgraber> [ubuntu/saucy] neutron 1:2013.2~rc3-0ubuntu1 (Accepted)   Dave Walker
[21:13] <Daviey> o/
[21:13] <stgraber> note the ubuntu/saucy instead of saucy-proposed
[21:13] <infinity> Daviey: Uhm, dude.  WTF?
[21:13] <Daviey> It isn't on an image?
[21:13] <cjwatson> I'm going to revoke ~ubuntu-archive from anyone who does that again.
[21:13] <cjwatson> Do not bypass proposed-migration.
[21:13] <infinity> Daviey: We have tooling around all of this for a reason.
[21:14] <cjwatson> I made this very clear when we introduced proposed-migration.
[21:14] <Daviey> Apologies.
[21:15] <infinity> Daviey: It failed its autopkgtests to boot.
[21:16] <Daviey> wtf, i'm looking
[21:16] <infinity> Daviey: Anyhow, either way, one should NEVER accept or copy into a release pocket.
[21:16] <cjwatson> There's one excuse: when binaries have got lost due to an override accident, so you need to copy it over itself to recover them.
[21:17] <cjwatson> For anything else, manipulating proposed-migration to do the right thing is always better.
[21:19] <Daviey> Ok, i understand.
[21:25] <bdmurray> Daviey: is there a reason the SRU for bug 1233486 was released early? it acutally introduced a regression.
[21:25] <ubot2> Launchpad bug 1233486 in software-properties (Ubuntu Precise) "[FFe] add support for 'cloud-archive:' like 'ppa:' but for cloud archive" [Medium,Fix released] https://launchpad.net/bugs/1233486
[21:26] <Daviey> bdmurray: What regression ?
[21:27] <bdmurray> bug 1239893
[21:27] <ubot2> Launchpad bug 1239893 in software-properties (Ubuntu Saucy) "PPAs added using GUI Software and Updates have an extra space added to repository line" [High,Triaged] https://launchpad.net/bugs/1239893
[21:28] <cjwatson> Does pending-sru warn about those?
[21:28] <smoser> bdmurray, are you sure it regressed?
[21:29] <bdmurray> smoser: I haven't specifically checked precise yet
[21:29] <smoser> the backport was more careful.
[21:29] <Daviey> I didn't release it through pending-sru, i used sru-accept.. after waiting 5 days, for something that was marked verified to coincide with -release
[21:30] <smoser> bdmurray, the patch changes looked like this in precise:
[21:30] <smoser> http://paste.ubuntu.com/6247862/
[21:31] <Daviey> infinity: te adt failure is a racey test with neutron (bug 1240712) .. (not that I will do it again anyway)
[21:31] <ubot2> Launchpad bug 1240712 in neutron (Ubuntu T-series) "neutron-lbaas-agent DEP-8 test sometimes fails" [Medium,New] https://launchpad.net/bugs/1240712
[21:31] <cjwatson> pending-sru isn't a releasing tool; it's a report
[21:31] <cjwatson> Looks like neutron passed its autopkgtests on a rerun
[21:32] <jamespage> it did :-)
[21:32] <smoser> it basically only takes a different path if 'line.startswith("cloud-archive")'
[21:32] <bdmurray> smoser: ah, yeah it looks good
[21:33] <bdmurray> Daviey: the waiting period is documented as 7 days
[21:34] <Daviey> bdmurray: Yes, but did we not discuss this at UDS and it was determined that this was an arbitrary figure.. and if it made sense, it was accepted to be faster?
[21:34] <smoser> i requested it be pushed through. we'd like to use this functionality to document how to use the cloud archive for havana.
[21:34] <infinity> SRU team people have some leeway there to fasttrack well-tested and obviously-sane (and/or urgent) fixes.
[21:35] <Daviey> (note, in that discussion i was a advocate for 7 days hard.. but there was strong support otherwise)
[21:36] <smoser> infinity, i'd argue that this was "well tested", and is very clearly (see patch) low impact.
[21:36] <Daviey> It's not as if it was an overnight acceptance.. I thought 5 days was a reasonable bake period for this.  Perhaps in retrospect I should have raised it here.
[21:37] <infinity> Daviey: Yeah, I have no issues with early promotions if they're sane.  But that's no surprise, that was my argument back then too. :)
[21:41] <slangasek> bdmurray: so I guess bug #1233486 should've been marked 'verification-failed' to record that there was a (suspected) regression?  Otherwise, there's no telling that this would've been noticed two days from now either...
[21:41] <ubot2> Launchpad bug 1233486 in software-properties (Ubuntu Precise) "[FFe] add support for 'cloud-archive:' like 'ppa:' but for cloud archive" [Medium,Fix released] https://launchpad.net/bugs/1233486
[21:42] <slangasek> Daviey, smoser: could one of you please check whether bug #1239893 applies to the version in precise-updates?
[21:42] <ubot2> Launchpad bug 1239893 in software-properties (Ubuntu Saucy) "PPAs added using GUI Software and Updates have an extra space added to repository line" [High,Triaged] https://launchpad.net/bugs/1239893
[21:42] <bdmurray> slangasek: yes, that's true.
[21:42] <Daviey> smoser: Are you able to verify that?
[21:43] <smoser> desktops suck
[21:43] <slangasek> smoser: please test it from your phone then ;)
[21:43] <bdmurray> I already checked and its fine
[21:43] <smoser> bdmurray, thanks.
[21:44] <smoser> for my curiousity, how did you do tha t?
[21:44] <slangasek> oh, great
[21:44] <bdmurray> I used a precise virtual machine and clickety clicked around
[21:51] <slangasek> so it's still broken in saucy, though?
[21:51] <slangasek> smoser: will you take care of this for saucy+t?
[21:53] <Daviey> Unless i am mistaken, that issue only manifests itself if you try to add the cloud archive to saucy.. which isn't possible... so it's not a saucy issue. not even SRU worthy.. right?
[21:53] <Daviey> smoser: ^
[21:54] <bdmurray> No, if you add any ppa via the gui it has an extra space in the sources line.
[21:54] <bdmurray> and an _ in the sources file name due to a missing strip()
[21:54] <bdmurray> I've already added the fix to upstream
[21:54] <Daviey> Oh
[21:54] <Daviey> I see that in Impact now.
[22:04] <Daviey> bdmurray: So what is the plan for that issue in saucy ?
[22:04] <bdmurray> Daviey: to SRU a fix for it
[22:06] <Daviey> bdmurray: Ok, are you driving that - or is smoser ?
[22:06] <bdmurray> I'll likely do it since I think it would be good to fix bug 1075537 too
[22:06] <ubot2> Launchpad bug 1075537 in software-properties (Ubuntu Saucy) "software-properties needs to automatically trigger a cache refresh after adding a repo" [Medium,Fix committed] https://launchpad.net/bugs/1075537
[22:07] <Daviey> ok, thanks
[23:51] <lool> Hinted unity8 + lxc-android-config; hopefully last uploads before final touch image
[23:54]  * nlsthzn needs to get a galaxy phone :/