[00:03] xnox: "rendering Ubuntu uninstallable in most of Quebec"? is that an easy fix? [00:04] lamont: hmm, pretty sure that's our responsibility to fix via lp:ubuntu-geonames... (see xnox's last comment on the bug) [00:08] 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] 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] Debian changelog and upstream changelogs are here: http://paste.ubuntu.com/6243106/ [00:11] hmm, actually let's forget about that, looking at the other missing depends, two of those aren't even in Debian [00:13] 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] stgraber: I have sdl-{mixer,image}1.2 arm64 fixes. They're apparently on the edubuntu DVD. Thoughts? [00:34] wgrant: upload, I'll let them into -proposed at least [00:35] Thanks, doing [00:41] thanks [00:43] np [00:51] 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] 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] I don't think it's justifiable to push an SRU to -updates that only fixes an arm64 build [00:59] but, well, maybe we wind up copying them to T instead of -updates [01:00] that works too [01:01] 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] yeah [01:49] slangasek: which website is the afflicted one? [02:33] lamont: geoip.ubuntu.com, no? [02:35] slangasek: that one uses the geoip package, which I've updated wth the fix in -cat [02:36] lamont: that's the 'geoip' source package? [02:36] slangasek, lamont: I confirm, the server is fixed now [02:37] hmm, ok then! [02:38] slangasek: yes, I updated the bug to also apply to the geoip package [02:39] which, you know, the current lts should see sometime [02:39] :D [02:39] in other news, my conversing here was prematurely interrupted by my laptop locking up. [02:44] ^^ supported only, arm64 fix [03:37] That's another supported-only [03:45] wgrant: hmm, looks like Launchpad got quite confused by that one ;) [03:45] * stgraber diffs manually [03:46] wgrant: That's moar arm64 fixes? [03:48] stgraber: Huh, weird [03:48] But thanks [03:49] 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] (they all look fine for SRU, though I didn't check if they did the paperwork or not) [04:24] gnome-control-center is not a high-priority fix, it should go to SRU and the paperwork's not filed [04:24] stgraber, infinity: I think lightdm can be an SRU. [04:24] slangasek: ^^^ [04:25] Same thing with nm-applet. [04:27] x264 could do with a one-liner for arm64. It's on edubuntu, kubuntu, mythbuntu, ubuntustudio. [04:27] So far, I don't see anything going on that would merit a respin for Kubuntu. I'd rather not. [04:27] Sure :) [04:28] 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] That seems to be the implication. [04:31] That seems rather unlikely on install though. [04:31] Which is why I think it's OK for SRU. [04:32] right; probably fine for a 0-day SRU to cover the upgrade case [04:32] 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] stgraber: I must have missed following up on ruby-arel. Thanks. [07:04] argh, sorry, didn't notice that was on edubuntu [07:15] if somebody wants to unblock ots, that's needed for abiword === doko_ is now known as doko [08:14] cking: Are you coming in to the office to play? Or are you here, and I just can't see you? [08:14] infinity, sorry, I have a dr appointment that I can't avoid [08:14] cking: Ahh. Fine, go worry about your health and such. See if I care. [08:14] heh [08:15] is apw in the office today? [08:16] cking, i am in transit as they say [08:27] is it me or is network-manager a bag of lemons the last day or so [08:30] rc3's for cinder and keystone uploaded - see bug 1240254 for details [08:30] Launchpad bug 1240254 in cinder (Ubuntu Saucy) "Havana rc3 tracker" [Critical,Triaged] https://launchpad.net/bugs/1240254 [08:30] cinder specifically is important as it addresses some upgrade issues [08:41] infinity: Can I leave a couple of libs (ftgl, x264) in the queue, to be accepted if there end up being respins? [09:06] infinity: ^ re-fix whoopsie [09:11] Laney: How tested is this gnome-settings-daemon upload? [09:13] infinity: I tested it and two other people said it works on the bug [09:13] I was expecting it to be SRU though [09:15] jamespage: any other saucy server uploads expected? [09:56] Daviey, there maybe another maas upload - roaksoax is working towards that [09:57] 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] infinity: xnox: will there be any respin for desktop with fix to bug #947107 ? [09:59] Launchpad bug 947107 in ubiquity (Ubuntu Precise) "No partition labels in the resize widgets" [High,Triaged] https://launchpad.net/bugs/947107 [09:59] psivaa: yes, among with many other things. [09:59] psivaa: see saucy-changes@ mailing for all the stuff recently accepted / uploaded. [10:00] infinity, Daviey: looking at the maas bugs now [10:00] and I forgot to accept ubiquity ... done [10:01] xnox: ack.. was not sure what required a respin [10:03] psivaa: Everything. :P [10:03] infinity: yea i realise :) [10:05] If you're doing that, then you could consider g-s-d [10:08] jamespage: assuming there aren't any bugs which are install or first-use critical ? [10:12] Laney: I'm considering it, I already asked you to tell me how well-tested it was. [10:13] Laney: Oh, and you answeed. [10:13] r [10:21] Daviey, so I have a bug that is impacting juju+MAAS usage for multi-tenant maas installes [10:21] bug 1239488 [10:21] Launchpad bug 1239488 in maas (Ubuntu Saucy) "Juju api client cannot distinguish between environments" [High,Triaged] https://launchpad.net/bugs/1239488 [10:21] one issue with lldp during commissioning - bug 1228085 [10:22] 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] and the associated fix for bug 1229275 [10:22] 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] which is the juju-core bit for bug 1239488 [10:22] Launchpad bug 1239488 in maas (Ubuntu Saucy) "Juju api client cannot distinguish between environments" [High,Triaged] https://launchpad.net/bugs/1239488 [10:22] but thats not on the ISO [10:29] 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] Daviey, agreed [10:31] 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] Daviey, roaksoax will be up shortly; don't want to step on his toes as he's been handling maas [10:31] oh yes, ok [10:32] Daviey, I'll stuff the juju-core fix into the queue as soon as upstream backport it to 1.16.0 [10:32] r-base must be build-dep chain for kubuntu or something, it's not actually on images [10:33] jamespage: sounds good. [10:45] jamespage: what's up with bug https://bugs.launchpad.net/ubuntu/+bug/1216980 ? [10:45] Launchpad bug 1216980 in Ubuntu "Switch cloud image signing key" [Medium,Confirmed] [10:46] hm, s-lts-backports is going to be a bit trickier, it needs more packages for backporting. :S [10:46] xnox, I'll have to ask utlemming [10:48] 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] can someone let lxc-android-config^^^ into proposed please [10:50] and the unity/unity-2d fixes for the new pointer barriers, the only user of the libxi/libxfixes changes. :P [10:51] thanks ! [11:14] mlankhorst, are you serious about updating cloog and isl for precise? [11:15] I have no idea what part of llvm needs it [11:17] hm hm actually it seems both packages bumped sonames between the precise version and the one I copied over [11:18] so not renaming them could work [11:19] You'd have to rename the sources [11:20] I guess [11:20] maybe the -dev package too, and have conflict on unrenamed [11:20] not maybe, but defintely [11:21] You could probably use versioned paths [11:23] 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] that leaves pixman [11:26] I fear renaming that is going to be awful because it's tied to libcairo2. [11:34] cjwatson: do you handle the hint or should I? [11:34] I will [11:34] thanks [11:35] I already did. [11:35] ok [12:01] 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] ubiquity [12:03] Ah. That'll do it. [12:03] ScottK: New ubiquity causes world respin, yeah. [12:04] I think we may have forgotten that the fix there didn't affect the KDE frontend and could have gone into -updates [12:04] Sorry :-( [12:04] ScottK: World respin will be in the nest hour or so, when I've verified everything's just so, archive/proposed-wise. [12:04] s/nest/next/ [12:08] 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] can someone accept mesa-lts-raring to precise-proposed? [12:28] 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] xmlrpc-c isn't on any images [12:42] thanks [12:53] cjwatson: so, indicator-datetime here for -updates ^ [12:54] the 3 commits (2 bugs) have been tested in both desktop and touch (and follow the SRU process) [12:54] and the commit without bug change an icon reference, but only for touch (thostr confirmed it) [13:23] 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] it can be forced given that they've never passed [13:24] 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] didrocks: ok, just waiting for desktop to spin [13:24] cjwatson: thanks [13:24] lool: Yeah, one you don't have permission for - I can do it [13:24] lool: What's the version number? [13:24] 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] cjwatson: system-image/1.9.1-0ubuntu1 [13:24] cjwatson: ubuntu-download-manager/0.2+13.10.20131016.1-0ubuntu1 [13:26] lool: I'll leave the unblocks to you [13:26] lool: I've done "force-badtest system-image/1.9.1-0ubuntu1" [13:26] thanks === barry` is now known as barry_ === barry_ is now known as barry [13:32] I guess if Mark doesn't pick a name by tomorrow, the tech board will have to do it. [13:32] Oh. Wait .... [13:32] I've bugged him several times. [13:33] I say we call it tenacious techboard. [13:33] I like toxic tuna better. [13:34] cking had a winner yesterday... [13:35] Ahh, yes. Tactile Tapeworm. [13:35] i guess now that is public it counts it out [13:36] cking: Pretty sure that wasn't the only reason to discount it. [13:36] xnox: in regards to bug 1216980, I am waiting on IS to upload a signed public key [13:36] Launchpad bug 1216980 in Ubuntu "Switch cloud image signing key" [Medium,Confirmed] https://launchpad.net/bugs/1216980 [13:36] they have the signed material, certainly [13:37] specifically elmo has a USB stick with it on [13:37] but I thought that had been delivered to you ages ago [13:38] cjwatson: elmo wanted to verify the purpouse, I did, but it just hasn't been uploaded yet. [13:46] utlemming: have prodded in person [13:46] 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] cjwatson: :) thank you kindly [13:47] hey so I noticed the juju section of the release notes are skeletonish, someone mind if I fill them in? [13:47] jcastro: goferit [13:54] jcastro: Please do. [13:54] jcastro: If you have things to say about any other part of the release, fill those in too. :) [14:08] 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] ScottK, you are testing from 13.04? [14:09] Yes [14:09] Both -d and not -d claim there's no new release available. [14:10] wgrant: On it. [14:11] infinity: Thanks [14:14] ScottK: 'update-manager -d' worked for me yesterday. [14:14] Worked for me over the weekend too. [14:17] I don't see any reason why it wouldn't work... [14:17] meta-release-development looks sane. [14:17] And not recently changed. [14:18] I think I figured it out. [14:18] Something we need to worry about? [14:18] Nope. [14:18] Funky local setup from a test I did last cycle and forgot about. [14:18] Sorry for the noise. [14:18] (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] Sigh. [14:19] Still, do test and let us know if you find any other show-stoppers. [14:19] The bug should only affect side-by-side installs, everything else should be fine. [14:19] Is it in the Ubuntu front end or a back end issue? [14:19] xnox: i dont see 'Install Now' being enabled on the side-by-side setup [14:19] Probably just the GTK frontend. [14:20] psivaa: That's the bug I just referred to, we're working on it. [14:20] If it's just the front end, can it go to updates? [14:20] infinity: ack [14:20] 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] It is just the front end [14:21] (This is https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1240532) [14:21] Launchpad bug 1240532 in ubiquity (Ubuntu) "side by side install mode had disable back and install buttons" [Critical,Confirmed] [14:21] I've never grasped the idea that people feel they need to end-to-end re-test for every small change. [14:22] We got through all the tests yesterday, so if we're going to retest, I'd rather it be the final. [14:23] 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] ScottK: And I can rebuild kubuntu first. [14:24] (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] 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] ScottK: *nod*... Colin's applying his giant brain to the problem, shouldn't be too long, I hope. [14:27] I'm rather hoping xnox will beat me to figuring it out ... [14:27] I'm mostly being a bisect-monkey [14:36] cjwatson: infinity: apw: http://paste.ubuntu.com/6245933/ [14:38] xnox: I still hit bug #1154345 and bug #1231091 with the screenreader tests [14:38] Launchpad bug 1154345 in ubiquity (Ubuntu) "Orca announces status of each steps' progress dot" [Low,Confirmed] https://launchpad.net/bugs/1154345 [14:38] 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] cjwatson: maybe if another respin is coming, we can get indicator-datetime in? [14:38] (just backlogging) [14:38] didrocks: Probably, yes. [14:38] didrocks: I'll assess that when we're ready. [14:39] sure, as long as it's either in the release pocket or -update by tomorrow morning (EU time), I'm fine :) [14:39] plars: Those probably can't be fixed before release at this point. :/ [14:39] thanks [14:40] 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] can someone accept mesa-lts-raring? [14:40] plars: Feel free to add things to the release notes, it's a wiki for a reason. [14:40] 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] 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] infinity: I know [14:46] Sigh. do-release-upgrade -d still not working here. There isn't a cache somewhere is there? [14:47] Yes. There is. [14:47] Now I think I got it. [14:54] there is muted swearing coming from the war room [14:54] didrocks: Err, dude. No. This indicator-datetime adds a Recommends on click, which pulls it into ubuntu-desktop. [14:55] infinity: urgh, really? I don't remember I was pinged with the packaging diff before sil2100 published [14:55] (so assumed no packaging diff) [14:56] didrocks: Rejected. [14:56] didrocks: If you get me a fresh upload ASAP, I can try to get it in the next spin. [14:56] didrocks: If not, well. Not so much. ;) [14:57] * didrocks checked his backlog [14:57] sil2100: so, please, pay real attention before publishing a stack with the .diff files when there are packaging diff [14:57] they are there for a reason (and blocking the automated publisher as well) [14:57] infinity: fixing it [14:57] didrocks: Thanks. [14:58] I was sure there was no packaging diff after doing the before-force-release [14:58] sil2100: This was your diff: http://paste.ubuntu.com/6246038/ [14:58] infinity: damn, then probably I didn't have the cu2d page properly refreshed or something [14:59] infinity: sorry about that [15:00] note that adding click as a recommends really really doesn't make any sense since touch doesn't install recommends anyway ;) [15:03] I'm diffing those 3 syncs in the queue (to save anyone else the trouble) [15:03] all 3 are seeded by all flavours based on ubuntu-desktop [15:04] stgraber, the signon ones? [15:04] i was about to ping cjwatson about those [15:04] signon-ui, libaccounts-glib and libaccounts-qt [15:04] it's an important fix for touch, but some overlap with desktop [15:04] right, which means we'd have to respin desktop for it [15:04] just for -updates [15:04] not critical to get it in the desktop image [15:05] but an SRU [15:05] We have a desktop respin coming anyway, if we decide this is low-impact enough to allow it. [15:05] fine with me :) [15:05] then you'll need the SRU paperwork done for those [15:05] we just need it for touch [15:05] kenvandine, does signon-ui have the arm64 fix? [15:05] though we may still have a respin coming, from what i got from backlog [15:05] right, I'll check how scary they are [15:05] 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] doko, arm64 fix? [15:05] kenvandine: don't ping me right now, I'm dealing with ubiquity [15:05] incomprehensible gtk weirdness [15:05] cjwatson, i won't then :) [15:06] stgraber, bug 1234282 [15:06] 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] cjwatson: I'm dealing with kenvandine's request [15:06] kenvandine, https://bugs.launchpad.net/ubuntu/+source/signon-ui/+bug/1239743 [15:06] Launchpad bug 1239743 in signon-ui (Ubuntu T-series) "don't limit the architecture to a fixed set" [High,Confirmed] [15:07] ah, we can fix that now [15:07] but i guess not important for 13.10 [15:07] doko, i'll propose a fix to trunk though [15:07] thanks [15:07] 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] stgraber, ubuntuone-credentials goes with those too [15:08] kenvandine: so I have a hard time seeing the relation between signon-ui and that bug ;) [15:08] and ubuntu-system-settings-online-accounts [15:08] haha [15:08] yeah, i thought that fix had already landed [15:08] kenvandine: the diff is: http://paste.ubuntu.com/6246080/ [15:08] so you can reject signon-ui if you like... but it only affects touch [15:08] that code doesn't even run on the desktop [15:08] at least not the qml bits [15:09] yeah, I'll let it in and we'll grab it with the next respin [15:09] although, i would like that fix for touch [15:09] thanks [15:09] 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] understand [15:09] so any change to a seeded package in the releaes pocket means a rebuild whether it's a visible change or not [15:10] just risk is low [15:10] * infinity nods. [15:10] I like low risk. [15:10] indeed :) [15:10] 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] kenvandine: hmm, those two libaccounts changes are technically feature additions... [15:17] well, adds some API to allow that bug to be fixed [15:18] without that, they couldn't limit the U1 accounts [15:18] and U1 doesn't support multiple accounts [15:18] what's the actual user visible effect of --disable-wal? [15:18] 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] stgraber: It also means that we can still change our mind. Once something is promoted, we're committed. [15:20] infinity: ok [15:20] 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] or potential bug [15:21] hmm, ok. Let's hope you're right. Accepting those two. [15:21] stgraber, we've been testing that for at least a week out of the daily builds ppa :) [15:22] wgrant: double upload? [15:22] 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] stgraber: Yeah, oops. Can you reject the remaining one? [15:22] we fixed something in that area, and intel or someone wasn't happy [15:22] s/wasn't happy/affected by/ [15:23] 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] stgraber, thanks! [15:24] stgraber: Heh. Sorry. [15:28] 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] stgraber: Double-override incident, lost half the binaries. :P [15:31] ok :) [15:31] stgraber: So had to copy it back over itself. [15:32] hmm, what happened with epiphany-browser... we didn't have that one on c-m yesterday... [15:32] it's arm64 not having a better www-browser provider [15:32] ignore it for now [15:33] stgraber: Yeah, ignore it. [15:33] ok [15:33] infinity, openmpi1.6 built, please unblock [15:33] doko: You're not planning to transition mpi-defaults, I hope? [15:34] infinity, did you count the rdeps? [15:34] doko: Cause I don't think that's even remotely sane. [15:34] na, will prepare for to open the t-series [15:34] coffe ... [15:35] Kay, that's slightly more sane. :) [15:35] doko: Want to stage some of that in a PPA? I can give you arm64 on one of the toolchain-r PPAs. [15:36] infinity, let's use the buildds for other builds for now [15:36] * infinity nods. [15:36] both lam and openmpi are untested [15:36] 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] I tested varnish! [15:37] It failed, but still. Thought counts. [15:38] infinity, will this include a browser? [15:40] doko: No. Who needs one of those? [15:40] 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] doko: It'll be missing exactly the same packages that are missing on ubuntu-desktop (thunderbird, firefox, and transmission) [15:41] stgraber, i jjust hinted ofono [15:41] stgraber: I'm doing unity-mir [15:41] mediaplayer done 10 minutes ago [15:41] ok [15:41] for the u1 thing, I pinged kenvandine twice :) [15:41] didrocks: what's with ofono? [15:42] didrocks: and accounts-qml-module? [15:42] lool: ogra talked about ofono [15:42] that he hinted it [15:42] please look ^ [15:42] lool: the rest is on ken's plate [15:43] lool, ofono is the GPRS fix, landing 254 [15:49] ah right missed that line [15:50] hinted location-service in; just a respawn added to upstart job [15:52] why does this have kubuntu packageset? [15:52] or ubuntu-desktop [15:52] I forgot the branch that cjwatson patched last time [15:52] cjwatson: Mind checking the origin of the packagesets for this one? [15:53] lool: later please [15:54] stgraber, i hinted the touch only packages, are you looking at the SRU bug for libaccounts-glib and libaccounts-qt? [15:54] lool: libubuntu-application-api1 [15:54] infinity: Would you mind reviewing it? [15:55] Looking. [15:55] kenvandine: we'll probably just take those in with the next respin but we're keeping them into -proposed until then [15:55] stgraber, thanks [15:57] ah, sorry, didn't see infinity was already on it, I accepted location-service [15:57] stgraber: So did I... [15:58] well, at least we agree :) [15:58] stgraber: thanks [16:17] infinity: here we go ^ [16:20] didrocks: To be fair, I'm not sure why that would even be a suggests, but it's harmless, I guess. [16:20] didrocks: Having packages depend/recommend/suggest a package manager is just strange. [16:20] infinity: upstream has strong feeling, I just gave up on that battle [16:21] didrocks: Upstream's feeling is wrong, according to the click author. Just sayin'. :P [16:23] infinity: would it be the first time? ;) [16:23] for click most likely [16:23] :) [16:28] 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] 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] bdmurray: Seems reasonable. [16:29] Good stuff [16:29] They came back with a revised patch for the original SRU [16:29] Laney, thanks for dealing with that buggy SRU [16:30] np [16:35] Should the Saucy Daily milestone be disabled in the tracker? [16:37] Nope, that's where the images are publishing to in addition to Final [16:40] cjwatson: apw: infinity: http://paste.ubuntu.com/6246499/ === rtg is now known as rtg-afk [16:42] infinity: what's the ETA on the respins? [16:44] plars: We have a fix we're testing right now, so "soon". [16:44]