[01:52] <slangasek> ^^ this gets the cross-compiler in sync with gcc-4.7-source for release, which is probably a good idea; I actually want them in sync to try to pin down an issue where gcc-4.7 is reportedly behaving differently for certain code for native vs. cross building
[01:53] <slangasek> (and the native compilation is giving buggy results, but that's beside the point... we don't know that the compiler itself is at fault)
[01:54] <slangasek> oh, is the final freeze still advisory for universe? ok then
[03:03] <darkxst> Is there some reason that there arent yet Ubuntu GNOME RC builds?
[03:05] <infinity> darkxst: We created the milestone, and are just letting them cron in at their usual time.
[03:06] <infinity> darkxst: Which for ubuntu-gnome, appears to be 15:32 UTC...  A bit of a wait.
[03:06] <infinity> darkxst: I can do a manual spin for you, if you have confused testers.
[03:08] <infinity> darkxst: Spinning you a set now.
[04:40] <darkxst> infinity, thanks ;)
[04:51] <ScottK> infinity: Thanks.
[06:04] <infinity> Can someone do a quick review of that gdb upload I just made?
[06:33] <slangasek> infinity: doh - right, I forgot about the efi binary new, didn't I
[06:33] <slangasek> infinity: gdb> looking
[06:33] <slangasek> or not
[06:49] <infinity> slangasek: Does anything read /lib/init/fstab other than mountall, and ever before /etc/groups is available?
[06:50] <slangasek> infinity: well, I had a conversation with stgraber and hallyn about possibly making lxc read it, but no.  Also, how can /etc/group ever not be available?  /etc must be on the rootfs
[06:50] <infinity> slangasek: Well, it could be unavailable if something pulled that file and mountall into an initrd, for instance.
[06:51] <infinity> slangasek: (Which doesn't ever happen currently, I assume?)
[06:51] <infinity> slangasek: Anyhow, was just asking because of the "gid=tty" instead of "gid=5" in there, which would go awry if one couldn't resolve "tty" to anything useful.
[07:03] <slangasek> infinity: yes, no mountall in initramfs
[07:04] <infinity> I'm beggining to think maybe I should revert the pt_chown change for now.
[07:04] <infinity> And maybe fix mount to add gid=5,mode=0620 to the "defaults" set.
[07:05] <infinity> There's this curious feature where, even if your base system is booted and mounted correctly, if you "mount -t devpts devpts-foo foo/", all instanced of devpts (including the base system) pick up the new defaults.
[07:05] <infinity> And lose the gid/mode bits.
[07:05] <infinity> Which has always been true, but then pt_chown picked up the slack for this misconfiguration in the past.
[07:09] <infinity> slangasek: On the other hand, Fedora already pushed this out as a security update a couple of months ago, and basically said "if stuff breaks, mount /dev/pts correctly, derp" in their announcement. :P
[08:27] <didrocks> infinity: if you are still around, the mir one is for this touch image ^ (it's just a build-dep of xorg, but the fix is for touch only), not seeded anyway
[08:28] <shadeslayer> stgraber: poke poke
[08:28] <infinity> didrocks: I'm not here, and you can't prove it.
[08:29] <infinity> didrocks: Oh, also: congrats.  Where was my invite? :)
[08:29] <didrocks> infinity: ahah, thanks a lot! :-)
[09:29] <ogra_> hey, i accidentially triggered an ubuntu-gnome build, hope i didnt cause havoc with this
[09:32] <cjwatson> slangasek: Probably ought to be changed, yes.  Can you file a bug and I'll do it next cycle?  I don't think I should mess with it now for 13.10
[09:35] <infinity> ogra_: They'll probably live.  There's going to be a cronned one today too, anyway.
[09:39] <xnox> infinity: well i have two installer bugs fixed now, and if/when ubiquity upload will happen today. I'd love to respin all ubiquity images and test them before departing for the weekend.
[09:39] <xnox> unless too late.
[09:40] <infinity> xnox: Not too late.  I'm sure this won't be the last installed upload of the cycle (though one can always hope).
[09:40] <infinity> s/installed/installer/
[09:40] <infinity> xnox: The freeze pretty much explicitly doesn't apply to installers, since this is when we get all the good/juicy bugs.
[09:42] <xnox> infinity: oh and base-files are not in yet, so yeah we will be respining =)
[09:42] <infinity> Indeed, I'll upload that on the weekend, probably.
[09:43] <infinity> Or maybe today sometime.
[09:43] <infinity> Since I lost a bunch of my weekend to flying in the wrong direction.
[09:43] <infinity> Silly timezones.
[10:19] <Mirv> ↑ and ↓ indicators + unity stacks, fully tested on desktop, best autopilot results ever so seems pretty nice. indicators also tested on touch (manually) for the parts that are affected.
[10:20] <Mirv> of course the best AP tests comes down to unity7 team fixing AP false alarms, but still, makes for nicer numbers
[10:21] <mhr3> Mirv, so are there any issues with landing it?
[10:22] <Mirv> mhr3: not that I know of, as mentioned good AP results, manual testing on touch fine.
[10:23] <mhr3> Mirv, cool, pls ping me if there's any problem with it
[10:23] <Mirv> mhr3: sure. if release team has any worries, they'll tell us here.
[10:30] <asac> cjwatson: http://paste.ubuntu.com/6221814/
[10:31] <asac> those are components that didnt make it it seems.
[10:31] <asac> cjwatson: what are the options? what do you need from us?
[10:34] <cjwatson> It was only 15 minutes ago :)  I'll review
[10:34] <asac> cjwatson: ok cool. let me know. especially if we need to divert one of those to -updates or wait much longer
[10:34] <asac> thanks
[10:35] <cjwatson> (I'm mostly fixing a problem with the publisher right now, so if anyone else can help ...)
[10:35] <asac> cjwatson: what kind of help? I assume that is "anyone from release team"?
[10:35] <cjwatson> Yes
[10:35] <cjwatson> asac: Is ido one of yours as well?
[10:35] <asac> cjwatson: so thats all that is comnig from CI
[10:35] <asac> we unfortunately have still desktop stuff in CI
[10:35] <asac> fortunately actually, but in this case a bit awkward
[10:36] <asac> asking didrocks
[10:36] <seb128> ido has a desktop bug fix
[10:36] <seb128> it doesn't impact touch
[10:36] <asac> cjwatson: ido is also coming from CI, but its pure desktop only
[10:36] <cjwatson> seb128: Do you know if the fix in ido affects anything in screenshots?
[10:37] <cjwatson> It's fine otherwise
[10:37] <seb128> cjwatson, it means the indicator-session avatar icon being properly aligned if you use a non default font size
[10:37] <seb128> I doubt we have any screenshot of the bug
[10:37] <cjwatson> Ah, so not screenshots
[10:37] <asac> so yeah we missed ido
[10:37] <seb128> means->makes
[10:37] <seb128> asac, I'm glad you uploaded it :p
[10:37] <seb128> that bugs annoys me ;-)
[10:38] <seb128> asac, btw "unfortunately have still desktop stuff in CI" ... does it mean you plan to drop CI for desktop components?
[10:38] <seb128> cjwatson, thanks
[10:41] <Daviey>  /37
[10:57] <cjwatson> asac,didrocks: all accepted now
[10:57] <didrocks> cjwatson: thanks a lot :) one worrying things less :)
[10:57] <asac> cjwatson: awesome!
[10:57] <asac> what an amazing day
[10:57] <asac> i will have to buy flowers for my wife still :P
[10:58]  * asac puts that on his "nice to have TODO list" :)
[10:58] <didrocks> asac: "nice to have" only?
[10:58] <didrocks> I think qtdeclarative-opensource-src is unseeded, right?
[10:58]  * didrocks checks
[10:59] <cjwatson> can't be unseeded if it's in those packagesets
[10:59] <cjwatson> but it looks fine, is it OK from the touch POV?
[10:59] <didrocks> cjwatson: yeah, it's fixing the "unity8 is taking 100% of GPU" :)
[10:59] <didrocks> CPU*
[11:00] <didrocks> thanks colin!
[11:00] <didrocks> ok, now touch-only uploads, all tested, fine, let's publish them
[11:01] <asac> didrocks: yeah i should prioritze that more appropriately :)
[11:03] <didrocks> heh
[11:12] <cjwatson> infinity: Did you retry the failures due to lp-buildd vs. pt_chown?
[11:13] <infinity> cjwatson: The one or two I knew about.  Were there many?
[11:13] <cjwatson> I only knew of the ones you told me about :-)
[11:14] <infinity> Fair.  I did those. :P
[11:44] <Mirv> thanks seb128 cjwatson asac didrocks :)
[11:45] <Mirv> I even got to eat proper food today, so I'm even more happy
[11:46] <didrocks> Mirv: lucky you! :)
[11:48] <seb128> Mirv, yw ;-)
[13:16] <jamespage> openstack just pushed out a second rc for glance with a number of critical and high bug fixes - zul preparing and reviewing now
[14:07] <zul> glance
[14:07] <zul> oops
[14:43] <didrocks> I think platform-api is what is freezing location-service ^
[14:45] <xnox> ubiquity ^ diff will be large, but it's really one bugfix per commit on lp:ubiquity. Also note that majority of the diff is debconf-updatepo, which means unfortunately that many strings were not possible to translate up to now.
[14:48] <shadeslayer> cjwatson: any reason why kubuntu-active ISO's aren't built?
[14:51] <didrocks> (thanks to whoever accepted location-service ;))
[14:51] <infinity> shadeslayer: I believe kubuntu-active was marked disabled in the ISO tracker, because someone didn't want them to be in milestones/release.  Has that position changed?
[14:53] <infinity> shadeslayer: Active wasn't in any of the alphas or betas, only dailies.
[14:53] <cjwatson> shadeslayer: check the build failures
[14:53] <cjwatson> shadeslayer: it's been failing for a while
[14:53] <shadeslayer> I don't know where :(
[14:53] <cjwatson> I hadn't had a chance to look
[14:53] <infinity> Oh, did you literally mean "not built" rather than "not posted to the tracker"?
[14:53] <cjwatson> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/ somewhere
[14:54] <shadeslayer> infinity: yes
[14:54] <shadeslayer> ahhh
[14:54] <shadeslayer> contour
[14:54] <shadeslayer> cjwatson: infinity could you trigger a build now?
[14:54] <shadeslayer> should be fixed
[14:55] <cjwatson> as of when?  today?
[14:55] <shadeslayer> I pushed fixes early today
[14:55] <shadeslayer> https://launchpad.net/ubuntu/+source/plasma-mobile/1:0.5-0ubuntu2
[14:55] <cjwatson> doing
[14:55] <shadeslayer> thx
[14:56] <infinity> I don't see how that would fix it.
[14:57] <infinity> shadeslayer: If both contour and plasma-active are being installed, you've not improved the situation by adding an unversioned Breaks.
[14:57] <shadeslayer> infinity: contour is no more
[14:57] <shadeslayer> dropped it from the seed
[14:57] <shadeslayer> removed from archive
[14:57] <shadeslayer> https://launchpad.net/ubuntu/+source/kubuntu-meta/1.291
[14:58] <shadeslayer> https://launchpad.net/ubuntu/+source/contour/+publishinghistory
[14:58] <cjwatson> I guess we'll find out
[14:58] <infinity> shadeslayer: Ahh, that was a bit more informative than the plasma-mobile link. ;)
[14:58] <shadeslayer> :)
[14:59] <shadeslayer> sorry about only providing half the info
[15:18] <lool> Hey, I've added a block ubuntuone-credentials hint to test it while it's in -proposed (it's not under cu2d CI)
[15:18] <lool> (dobey is the uploader and has tested it "upstream" / in trunk)
[15:18] <lool> (it's only seeded in touch)
[15:19] <cjwatson> thanks
[15:33] <xnox> stgraber: updating ubuntu-meta does "* Added shotwell to desktop-recommends [powerpc]" yet i was just removed "* Removed shotwell from desktop-recommends [powerpc]" by your last upload. is that correct?
[15:36] <cjwatson> xnox: Looks like it was removed from powerpc at one point and then restored
[15:36] <xnox> cjwatson: ok. uploaded.
[15:36] <cjwatson> maybe?
[15:37] <xnox> it's recommends and powerpc.... maybe it was removed/FTBFS at the time of last upload?!
[15:37] <cjwatson> Yeah, https://launchpad.net/ubuntu/saucy/powerpc/shotwell, deleted from release entry #7
[15:38] <xnox> cjwatson: otherwise it's a FTBFS fix.
[15:38] <dbarth> hi
[15:38] <lool> 17:36 -queuebot:#ubuntu-release- Unapproved: ubuntuone-credentials (saucy-proposed/universe) [13.10-0ubuntu1 => 13.10-0ubuntu2] (ubuntuone)
[15:38] <lool> what does the ubuntuone package set mean?
[15:38] <lool> does it have special rules for reviews or something?
[15:38] <cjwatson> I think it's for upload perms
[15:38] <dbarth> can i bring the case of bug #1206268 to your attention again
[15:38] <ubot2> Launchpad bug 1206268 in webbrowser-app (Ubuntu) "[MIR] unity-webapps-qml" [Undecided,Fix committed] https://launchpad.net/bugs/1206268
[15:39] <xnox> don't think so, just uploads perms & release-bug tracking / owners.
[15:39] <mterry> Heyo folks!  There is a change that dbarth and folks would like to make to the ubuntu-sdk package.  ^ This would involve dropping a Recommends from that seed, and then changing qtmultimedia to stop building a certain package only referenced by the sdk metapackage.  How doable is that (we have branches, just looking for approval) at this stage?
[15:40] <xnox> mterry: are all changes required reviewable somewhere? is it all the branches attached on the bug report?
[15:40] <xnox> mterry: can you comment links with merge proposals against seeds and/or all packages involved?
[15:40] <xnox> (comment on the bug that is)
[15:41] <lool> stgraber: There might be some possible improvements to the autoaccept script if you like to: ubuntuone-credentials is only seeded in touch, but is stuck in queue because it's in a special upload packageset (ubuntuone)
[15:41] <xnox> cause it's hard to see what the scope of changes is....
[15:41] <mterry> xnox, sure.  let me link
[15:41] <stgraber> lool: I'll whitelist that one
[15:42] <dbarth> mterry: should Mirv also comment on the bug directly, with the plan he proposed earlier in the thread?
[15:42] <lool> stgraber: thanks
[15:43] <stgraber> lool: added to whitelist now
[15:43] <ogra_> can someone please let livecd-rootfs through ?
[15:44] <ogra_> (first is adding click packages to the manifest, second is a fix for a serious touch bug)
[15:45] <mterry> dbarth, the plan is basically "land these three branches"
[15:45] <stgraber> looking
[15:45] <mterry> xnox, three branches added to bug in comments
[15:47] <mterry> robru, ^ btw
[15:47] <stgraber> ogra_: I'm a bit concerned by that manifest change, won't that break Ursinha's script and anything that expects packages listed in the manifest to be avaiable from the archive?
[15:47] <ogra_> stgraber, it wont break my script, Ursinha's is still not merged afaik
[15:47] <ogra_> stgraber, and jibel picks his data from my location
[15:48] <ogra_> stgraber, in any case we need that info in the manifest
[15:48] <stgraber> well, I'd argue we should have a separate manifest file for click
[15:48] <ogra_> sure, we can do that later
[15:48] <stgraber> cjwatson: I'd like your opinion on this if you have a minute?
[15:49] <ogra_> stgraber, this is the quick variant to get it in before release
[15:49] <ogra_> stgraber, i'l happily teach cdimage about a new file and how to publish it in T
[15:49] <cjwatson> stgraber: I recommended the approach ogra_'s taken - I think manifest consumers should be prepared for the packages to be either .deb or .click
[15:50] <dbarth> mterry: right
[15:50] <cjwatson> If it breaks anything then surely it'll be straightforward to fix
[15:50] <cjwatson> try: except:
[15:50] <ogra_> the format is the exact same too
[15:50] <stgraber> cjwatson: is there an easy way for something reading the manifest to determine whether it's a .deb or .click?
 <version>
[15:50] <cjwatson> stgraber: "does it exist in the archive as a .deb"
[15:51] <cjwatson> I mean, it has to go looking for the changelog anyway, it can just check, no?
[15:51] <ogra_> stgraber, most likely the namespace will be com.ubuntu.foo.bar.*
[15:51] <cjwatson> ogra_: that's definitely not a reasonable thing to check for in the consumer
[15:51] <cjwatson> if it would be helpful to prefix the package name with "click:" or something, that would be possible
[15:51] <stgraber> sure, it's just going to be tricky to know whether something is a click package or a package coming from a PPA (even though we're not supposed to ever use PPA, the past as showed that we sometimes do)
[15:52] <cjwatson> I dunno, I guess a separate file would be possible, I'd just like to avoid a proliferation of output files
[15:52] <cjwatson> I think it's confusing
[15:52] <ogra_> in any case a separate file is nothing for the week before release imho
[15:52] <stgraber> I think I'd be fine with a click: prefix as it shouldn't break ogra_'s script and will let other parsers easily detect click and either act on it or ignore them
[15:52] <ogra_> i dont want to do big plumbings in cdimage that close to release
[15:56] <stgraber> xnox: do we really have to introduce a new string in ubiquity that close to release?
[15:57] <stgraber> xnox: hmm, well, it doesn't really matter since none of the ubuntuone strings were translated anyway... I guess it's going to be one of those releases...
[15:57] <xnox> stgraber: note that none of the other strings introduced this cycle in ubiquity didn't make it into .pot and were not translated due to not running debconf-updatepo this cycle at all. So in fact I am introducing new strings anyhow in that plugin.
[15:58] <ogra_> stgraber, so do you let it in ? i urgently need the second fix
[15:58] <ogra_> oh
[15:58] <xnox> stgraber: it only affects ubuntu images, as nobody else seeded ubiquity-ubuntuone plugin.
[15:58]  * ogra_ notes the mail
[15:58] <ogra_> sigh
[15:58] <stgraber> ogra_: I'll accept your /system/bin/sh change and reject the other
[15:58] <ogra_> k, thanks :)
[15:58] <xnox> stgraber: yeah, it is shame that translations will be bad..... (note U1 api only returns back errors in english =/ )
[15:59] <stgraber> ogra_: hmm, actually I can't since you stacked the /bin/sh one on top of the manifest one... (I was hoping it was the other way around and I could simply pull the old one from the reject queue)
[15:59] <stgraber> ogra_: if you re-upload adding a click: prefix to the manifest entries, I'll accept it. Alternatively, just upload the /bin/sh fix and I'll accept that.
[16:00] <ogra_> ok that has to wait 1h then ...
[16:00] <stgraber> ogra_: why?
[16:00]  * ogra_ has meetings now 
[16:00] <stgraber> ah ok
[16:00] <ogra_> i'll re-work the click part ...
[16:00] <ogra_> since we need that
[16:00] <stgraber> thanks
[16:01] <ogra_> (i doubt any of the scripts can handle columns in the package name though)
[16:01] <stgraber> ogra_: ping me once it's back in the queue if I don't notice and I'll make sure it's reviewed quickly
[16:01] <stgraber> ogra_: well, either they really care about the source name existing and they'll fail either way or they don't and a click: prefix won't make any difference
[16:07] <cyphermox> ^ didrocks: signon-ui as requested
[16:07] <stgraber> I'm reviewing it now
[16:07] <cyphermox> stgraber: thanks
[16:09] <ogra_> stgraber, cjwatson http://paste.ubuntu.com/6223092/ does that look ok to you ?
[16:10] <alex-abreu> cyphermox, is the ball rolling for webbrowser-app ?
[16:10] <stgraber> ogra_: did you mean "while read line"?
[16:11] <cyphermox> alex-abreu: best I can tell you is it *did* for image 94, I don't know more
[16:11] <ogra_> stgraber, not really, i tested that variant locally
[16:11] <stgraber> ogra_: hmm, actually, both do the same, ignore me ;)
[16:11] <ogra_> but i can tiurn it into a while loop :)
[16:11] <stgraber> it's just the first time I see it done with for I believe ;)
[16:11] <ogra_> stgraber, heh, now that i think about it, me too :P
[16:12] <stgraber> ogra_: anyway, yes, that looks good to me
[16:12] <ogra_> great, committing and uploading 2.194 then
[16:13] <stgraber> ogra_: you know that you can just squash all the changes and upload 2.192 right? as none of those got accepted into the archive
[16:13] <stgraber> cyphermox: are you familiar with the actual changes in that upload?
[16:13] <ogra_> stgraber, i'm to lazy to roll back the bzr branch
[16:13] <stgraber> ogra_: ok :)
[16:13] <ogra_> its upstream committed
[16:13] <ogra_> :)
[16:14] <cyphermox> stgraber: I tested that you could still create accounts and such, and ran the autopilot tests
[16:14] <stgraber> cyphermox: I'm not entirely confident that this is a bugfix only upload based on the wording of the changelog and the number of qml changes, does that upload cause any kind of user visible change?
[16:15] <didrocks> thanks cyphermox!
[16:15] <cyphermox> stgraber: not that I noticed
[16:16] <cyphermox> didrocks: do you know more? ^
[16:17] <stgraber> it's a bit hard to figure it out from the diff with all of those qml files being renamed/split/merged...
[16:18] <stgraber> ogra_: just to confirm, that click change is in a touch specific section of auto/build, right?
[16:18] <ogra_> stgraber, yep. ubuntu-touch and armhf even
[16:19] <stgraber> ok, thanks
[16:20] <stgraber> ogra_: there you go ^
[16:20]  * ogra_ hugs stgraber 
[16:20] <ogra_> thanks :)
[16:21] <cjwatson> ogra_: "for line in read" runs the loop body once with $line set to "read"
[16:21] <cjwatson> ogra_: that needs to be a while loop instead
[16:21] <cjwatson> (I tested this ...)
[16:21] <ogra_> cjwatson, eeek
[16:21] <ogra_> will fix in a minute
[16:21] <cjwatson> $ (echo foo; echo bar; echo baz) | for line in read; do echo $line; done
[16:21] <cjwatson> read
[16:22] <cjwatson> I would be very surprised if any POSIX shell did otherwise
[16:22] <ogra_> http://paste.ubuntu.com/6223144/
[16:23] <didrocks> stgraber: only on touch AFAIK
[16:23] <didrocks> cyphermox: ^
[16:23] <stgraber> ogra_: those don't look prefixed to me
[16:24] <cjwatson> ogra_: that only works at all by sheer coincidence
[16:24] <cjwatson> And indeed will never be prefixed
[16:24] <ogra_> http://paste.ubuntu.com/6223153/
[16:25] <cjwatson> ogra_: What that does is cause the shell to evaluate the output of "click list" as a file name, attempt to redirect stdin from it, and then emit an error message saying that that (ridiculous) file name doesn't exist
[16:25] <cjwatson> ogra_: still broken
[16:25] <cjwatson> ogra_: you need:
[16:25] <stgraber> ogra_: FWIW I tend to prefer: Chroot chroot "click list | while read line; do ...; done
[16:25] <cjwatson> Chroot chroot "click list" | while read line; do ...; done
[16:25] <ogra_> ok
[16:26] <cjwatson> And indeed your second version is broken for the same reason - <"$(...)" is basically nonsensical shell :)
[16:26] <stgraber> right and cjwatson's will actually work since he didn't forget a " :)
[16:26] <shadeslayer> cjwatson: ISO seems to have built \o/
[16:26] <cjwatson> shadeslayer: cool
[16:26] <ogra_> ok, final attempt http://paste.ubuntu.com/6223157/
[16:27] <cjwatson> should work yes
[16:37] <didrocks> thanks stgraber
[17:06] <thostr_> we got a test failure on ppc https://launchpadlibrarian.net/153485520/buildlog_ubuntu-saucy-powerpc.mediascanner_0.3.93%2B13.10.20131011-0ubuntu1_FAILEDTOBUILD.txt.gz
[17:06] <thostr_> however, mediascanner is currently not utilized by any desktop, it's only used for phone where it works
[17:07] <thostr_> so, could we ignore the test error under those circumstances?
[17:07] <cjwatson> We can remove the binaries on powerpc
[17:07] <cjwatson> Sorting that out now
[17:08] <cjwatson> It just needs unity-scope-mediascanner removed too
[17:09] <thostr_> cjwatson: thanks
[17:09] <cjwatson> done now pending the next publisher cycle
[17:13] <stgraber> hmm, interesting, pre-release freeze isn't considered as development by Launchpad?
[17:13] <stgraber> >>> list(lp.distributions['ubuntu'].getDevelopmentSeries())
[17:13] <stgraber> []
[17:14] <stgraber> (I noticed because I had to pass -s saucy to a few of our tools recently and finally got around to checking why)
[17:14] <slangasek> stgraber: correct
[17:18] <cjwatson> stgraber: .current_series
[17:18] <cjwatson> stgraber: I fixed ubuntu-archive-tools for that fairly recently - you may want to update
[17:18] <cjwatson> (r775 last week)
[17:22] <stgraber> cjwatson: haha, I was indeed a bit behind on ubuntu-archive-tools! thanks for the fix
[17:24] <xnox> looks like ubiquity 2.15.23 has landed, can we respin all ubiquity images?
[17:25] <stgraber> we're still on cronned run
[17:25] <xnox> stgraber: i know, but it has so many fixes and duplicate bugs are kept being filed.
[17:26] <xnox> stgraber: can ubiquity images that have already been build today be respun? e.g. ubuntu-desktop at least?
[17:26] <stgraber> xnox: ok, I'll trigger a rebuild of all images listed on the manifest
[17:26] <xnox> stgraber: thanks.
[17:27] <stgraber> done (selected all the desktop images listed under the Final milestone)
[18:04] <rtg> infinity, re: bug #1236666 - should I request a sync ? get the source deb and upload manually, or go away and never mention it again ?
[18:04] <ubot2> Launchpad bug 1236666 in msr-tools (Ubuntu) "[Feature] update msr-tools package to revision 1.3" [Low,New] https://launchpad.net/bugs/1236666
[18:31] <mdeslaur> can I upload a fix for python-xlib? (LP: #1231453, and LP: #1221514). Looks like it's seeded on the edubuntu dvd.
[18:31] <ubot2> Launchpad bug 1231453 in python-xlib (Ubuntu) "get_full_property() throws exceptions" [Undecided,Confirmed] https://launchpad.net/bugs/1231453
[18:31] <ubot2> Launchpad bug 1231453 in python-xlib (Ubuntu) "duplicate for #1221514 get_full_property() throws exceptions" [Undecided,Confirmed] https://launchpad.net/bugs/1231453
[18:34] <mdeslaur> stgraber: ^
[18:35] <infinity> rtg: Sell me on why we want a new version 6 days before release, and what it won't break.
[18:40] <stgraber> mdeslaur: sounds reasonable
[18:40] <mdeslaur> stgraber: thanks, uploaded
[19:34] <rtg> infinity, why is msr-tools in main ? the new 1.3 version doesn't look like it has any compelling new features to warrant uploading right now. 14.04 ought to be soon enough.
[19:35] <infinity> rtg: It's in main for cpu-checker
[19:35] <infinity> rtg: Which, in turn, is in main for qemu.
[19:36] <infinity> rtg: Which is in main because we hate our users and refuse to support Xen.
[19:36] <infinity> QED.
[19:36] <rtg> infinity, ok, I'll take option 3 (i.e., go away)
[19:36] <infinity> rtg: Sure.  It's not modified in Ubuntu, so it'll autosync when we open 14.04.
[19:36] <rtg> yep
[21:05] <jdstrand> infinity: fyi, got approval from #ubuntu-ci-eng for the apparmor upload
[21:05] <jdstrand> infinity: http://paste.ubuntu.com/6224151/
[21:06] <jdstrand> $ apt-cache depends apparmor|grep python
[21:06] <jdstrand>   Depends: python3
[21:06] <jdstrand> before:
[21:06] <jdstrand> $ apt-cache depends apparmor|grep python
[21:06] <jdstrand>   Depends: python
[21:06] <jdstrand> infinity: so, does your comment in #ubuntu-devel mean I can upload?
[21:10]  * jdstrand uploads
[21:11] <jdstrand> if there is a problem, reject it
[21:12] <knome> hmph, apparently ubiquity slideshow translations weren't uploaded since a few weeks.
[21:27] <stgraber> knome: hmm, that's unfortunate... let me do that quickly now
[21:27] <knome> stgraber, cheers :)
[21:42] <ScottK> jdstrand: Seems fine.
[21:42] <stgraber> knome: uploaded
[21:43] <ScottK> Oh, someone got it already.
[21:43] <stgraber> yeah, I did
[21:43] <jdstrand> stgraber, ScottK: thanks! :)
[21:44] <stgraber> ^ that diff will likely be quite massive, it's a translation update from LP, so I'd recommend just checking that I'm not doing anything else :)
[21:45] <knome> stgraber, thanks again! :)
[21:48] <lool> hint-unblocked ubuntuone-credentials (touch only)
[22:11] <slangasek> stgraber: diff looks fine, but is kind of late?  Why didn't the translation updates get done before final freeze?
[22:11] <slangasek> and do we know for sure that we're having another set of images rolled, so that we should definitely accept this now?
[22:19] <slangasek> lool: what unblocking is needed?  the fact that it's touch only means it should go through automatically, and anyway I don't see it uploaded
[22:19] <lool> slangasek: just a followup to: 17:18 < lool> Hey, I've added a block ubuntuone-credentials hint to test it while it's in -proposed (it's not under cu2d CI)
[22:20] <slangasek> lool: ah
[22:20] <lool> slangasek: I did my own blocking and unblocking basically, but wanted to keep the RT in the loop for hints
[22:20] <slangasek> ack :)
[22:28] <stgraber> slangasek: right, we apparently dropped the ball on that one and nobody updated the translations in weeks... knome noticed a bit earlier today
[22:28] <slangasek> stgraber: so we're planning full ISO respins to pick this up?
[22:29] <stgraber> slangasek: we're still running on cron at the moment and infinity is planning to turn off cron probably tomorrow/sunday
[22:29] <slangasek> ok
[22:29] <slangasek> accepting, then
[22:29] <stgraber> thanks
[22:30] <knome> slangasek, ta