[00:00] Pretty sure it would, yeah. [00:00] The filename must be of the form: [00:00] __.tar.gz [00:00] LP already special-cases translations.tar.gz, IIRC. [00:00] And changing would land in the published directory name [00:00] So not sure it's worth the effort at the moment TBH :) [00:01] Nope. [00:01] I don't think it special-cases _translations.tar.gz so much as cares much less about its name. [00:01] Or that. :P [00:01] Well, _translations also doesn't get caught in NEW. [00:02] The raw-translations section is the bit that matters. [00:02] But yeah, probably because of the upload type. [00:02] UNAPPROVED in this case. That's a special case for UEFI. [00:02] By request of the security team. [00:02] Oh, derp. Right, to avoid random people jamming them in. [00:02] We've HAD THIS CONVERSATION. [00:02] I'm getting old. [00:03] 'zackly. Compromise between locking down the set of UEFIable source packages and letting any single-PPU developer get stuff signed with our key. [00:05] I think I'll review GTK and then go get ready for a night of drunken debauchery. [00:17] * skaet thinks a glass of wine sounds about right, at any rate --> EOD [00:19] cjwatson: accepting nouveau. The patch that's dropped in the diff wasn't applied in the previous uploads so it looks indeed safe to remove. [00:19] tjaalton: ^ [00:32] iulian: no my understanding openstack projects has a standing FFE which includes python-novaclient [00:39] zul: A standing FFe *forever*, or until a certain pre-release date (and didn't this come up last release cycle too?) [00:39] zul: There has to be a cutoff point where we can't just jam in new features and hope they work. [00:40] infinity: there hasnt been a a certain pre-relaase date, besides the new novaclient will be the last for quantal [00:42] Oh, vomit. Looks like a CompSci Java student attacked the code. [00:42] - if nic_info['net-id']: [00:42] + if nic_info.get('net-id'): [00:42] Etc. [00:44] infinity: first one can give the KeyError, while the later returns None, casted to bool => False. So actually looks like a bug fix. [00:45] .... unless net-id is always set to something...... in that case vomit. [00:45] xnox: Yeah, I suppose it could be unset (and I wasn't actually paying attention to the part that it was an if, just the []->.get() change) [00:46] xnox: I retract the vomit, based on it being in a test, though that's potentially sketchy in other ways. :P [00:46] * xnox feeds vomit back to infinity [00:46] Ew. [00:46] That's my cue to put on pants and leave the house. [00:47] infinity: in a parallel universe it's actually cherries and strawberries =) [03:28] stgraber, cjwatson: yeah, the patch was cruft from my local tree.. probably should use git-bp in the future ;) [04:26] if someone with live image knowledge could please review this and make sure I got it right ^^^ === henrix_ is now known as henrix [08:24] i have a few kernel packages that landed in the wrong component in the -proposed pocket. can someone take a look at that, please? [08:25] stgraber: nouveau> ah, thanks [08:26] oh, we're staying frozen? [08:30] apparently so [08:30] henrix: I'll fix it up in a few minutes [08:30] still on child duty [08:30] cjwatson: great, thanks [08:35] cjwatson: will do [08:48] You know [08:48] I think I might just bite the bullet and finish porting this old "fix up all the kernel overrides post-publication" script [08:52] henrix: will take a little longer as a result [08:53] cjwatson: ok, no worries [09:00] cjwatson: can you review my livecd-rootfs upload in the queue for quantal, it adds some missing tasks for Ubuntu Studio (I'm 99% sure it's fine) [09:11] infinity, as requested [09:11] infinity, and yes we do [09:16] micahg: yes, in my queue [09:16] henrix: oh, hah, I thought you meant they'd been *published* with the wrong components [09:16] but they're in NEW [09:16] oh well, the effort won't ultimately go to waste [09:17] we already have a tool to mangle the queue :) [09:17] cjwatson: ups, sorry :-/ [09:17] cjwatson: i should have provided you with a bug number [09:18] cjwatson: bug #1056036 btw [09:18] Launchpad bug 1056036 in linux "linux: 3.2.0-32.51 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1056036 [09:18] micahg: oh, yeah, that's fine [09:18] henrix: Oh. You mean precise. [09:18] Please tell me the series! :-) [09:18] Otherwise I'm going to assume current development [09:19] cjwatson: ok, noted and will do that next time. [09:20] all right, I can try out this script after all [09:39] diff from 3.5.12-0ubuntu3 to 3.5.13-0ubuntu1 (14.7 MiB) [09:40] :) [09:41] * Laney sides with infinity about "* New upstream release" changelogs [09:48] did someone leave gtkmm3.0 in the queue on purpose? [09:49] * Laney abuses barry for not uploading merges with -v [10:00] slangasek> fwiw I've looked at the glibmm2.4 in the queue and think I see a problem with it [10:00] bah. not gtkmm [10:01] related? [10:10] * cjwatson sends the LP branch to remove the queue script off to EC2 [10:10] At last [10:10] * Laney misparsed that at first and thought we were to become more cloudy [10:11] no [10:11] :) [10:25] bah [10:31] hmm, am i assuming right that we wont have a release meeting tonight (given there was a release yesterday) [10:31] ? [10:46] please to score up https://launchpad.net/ubuntu/+source/libsoup2.4/2.40.0-0ubuntu1/+build/3860291 [10:46] makes webkit uninstallable, which makes things sad [10:46] doing [10:46] done [10:46] ta [10:50] Daviey: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt is looking pretty good, but just needs a bit more of a push; could somebody on your team prepare MIRs as appropriate for ipmitool, javascript-common, python-babel, and wwwconfig-common? [10:54] cjwatson: ipmitool will be dropped on next upload, and python-babel was pulled in by accident with pydist. [10:54] But yes, keeping an eye on it. [10:55] ipmitool MIR was marked Invalid, so not showing on report. [10:56] OK ... [10:56] * cjwatson gets rid of svn2cl [10:57] Not that it'd have been a big deal since it was a split-out, but [10:58] bah, the libsoup rabbit hole gos deeper [11:04] cjwatson: sorry to nag you again, but have you took a look at precise packages (bug [11:04] . [11:04] cjwatson: bug #1056036 [11:04] Launchpad bug 1056036 in linux "linux: 3.2.0-32.51 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1056036 [11:04] henrix: Just getting back to it now [11:04] cjwatson: ah, cool. thanks [11:07] Just a bit baffled by why my script isn't doing the right thing [11:07] Oh, I bet SPPH.getPublishedBinaries is annoying [11:12] ... no, my own stupid fault [11:21] henrix: done now (I gave up on the script for the moment) [11:21] cjwatson: ack, thanks a lot [11:32] Laney, libsoup failed again. I assume we have to wait ... [11:33] yes [11:33] Daviey, cjwatson: the python-babel issue will be resolved if the nova ftbfs is fixed [11:33] doko: right, thanks [11:34] doko: do you know why webkit would fail on armel with the argument list too long error, but not on armhf? [11:34] https://launchpad.net/~laney/+archive/webkit/+packages [11:34] Daviey, so what about yui3? [11:34] Laney, sorry, no [11:34] doko: I'll press on that today. [11:35] ogra_: ^ you have any idea? [11:35] Daviey, we had another package with this, downgraded to suggests, but if it pops up again, maybe it's better to include these two in main [11:35] Laney, not really, no [11:36] Laney, ahh, this is *with* you patched make? [11:36] doko: Which two? [11:36] yes [11:37] Laney, hmm, that seems to be a virtual PPA [11:37] Kernel version: 2.6.24-32-xen #1 SMP Thu Jul 12 14:30:40 UTC 2012 x86_64 [11:38] i would incline to blame qemu [11:39] ok, i'll try it on my panda then [11:39] Laney, how about you try it again in the canonical-arm-dev PPA [11:39] that should be a physical builder [11:40] I'd have to copy the patched make-dfsg in there [11:40] might not be the best idea [11:40] ah, yeah, no [11:41] Daviey, ahh, it was yui, but the downgrade wasn't done for the -debug package ... fixing [11:41] doko: ah, ok [11:45] infinity: ahahahaha bonk [11:45] infinity: http://paste.ubuntu.com/1247367/ [12:00] bah, too many uninstallables [12:20] ogra_,infinity: so, zsync of ARM *.gz files [12:20] ogra_,infinity: do you want them always to come out locally as *.gz, or is it appropriate e.g. for zsync to decompress *.img.gz on the fly? [12:21] cjwatson, the former, else you suddenly end up with a 4G file if you downloaded a 400M img.gz [12:21] OK [12:21] I'm pretty sure this was just a mistake in publish-release [12:21] ah, good [12:21] And actually it dates back forever [12:21] funny, i have scripts using zsync here [12:21] ./ubuntu-netbook/ports/releases/maverick/release/ubuntu-netbook-10.10-preinstalled-netbook-armel+omap4.img.gz.zsync:Filename: ubuntu-netbook-10.10-preinstalled-netbook-armel+omap4.img [12:21] But are those scripts pointed at dailies? [12:21] and that definitely worked before the switch to lubuntu for ac100 [12:21] yes [12:21] publish-daily doesn't have the same bug [12:22] ah [12:22] Oh, but apparently it does now [12:22] Blast [12:22] OK, so we have two bugs here [12:23] Oh, I se [12:23] e [12:24] fixed - I'll regenerate *.zsync now [12:29] ogra_: Lubuntu daily should work now [12:29] yay, great [12:29] will test, one sec [12:31] http://paste.ubuntu.com/1247426/ [12:31] looks good [12:31] (nothing to fetch indeed :) ) [12:32] awesome, thanks. I'm going to go round and fix up all the old release directories [12:39] ogra_: all fixed now, including a handful on old-releases [12:39] cjwatson: thanks [12:40] * ogra_ hugs cjwatson [12:42] Laney: yeesh, I see what you mean about the libsoup rabbit-hole [12:43] cjwatson: I have some tabs open to keep an eye on things, but couldn't be bothered to annoy for many rescores [12:43] gsettings-desktop-schemas armel/ppc would be a good start [12:43] that's where I'd just got to [12:44] of course it could go further than that [12:44] those at least have satisfiable build-deps [12:44] so rescored [13:05] oho, a pre-release backport [13:15] ^- needed (along with a debian-installer upload later) to let me check appropriate lowmem levels for bug 1050595 [13:15] Launchpad bug 1050595 in lowmem "Ubuntu Server installation with 128M ram hangs" [High,In progress] https://launchpad.net/bugs/1050595 [13:16] so I'd quite like that in quickly if somebody has time to review [13:16] * ogra_ sees popey's release team report and laughs [13:16] " Lots of love in lenses" .... [13:16] :) [13:17] phew! [13:17] so we ship a partnetr search lens ? or is it p0rn ? [13:17] :) [13:18] cjwatson: looking at lowmem [13:18] well, once LP is done generating the diff... [13:24] slangasek: we are still requiring FFe for multi-arching packages right? (was looking at libgnomecanvas in the queue) [13:27] ta [13:27] could a kind release team member please cast an eye over https://bugs.launchpad.net/unity-lens-music/+bug/1054720 ? [13:27] Launchpad bug 1054720 in unity-lens-music "[UIFE] Previews: Unable to preview banshee songs in the dash" [Medium,Fix committed] [13:30] I asked Till to confirm that the brother-lpr-drivers-common upload is sane as it's not linked to a bug and it's not clear whether the change has been tested or the impact on the resulting binaries [13:35] hi - any objections to FFE for bug 1049908 ? it's a pretty nice improvement in upstart control over auto-start lxc instances [13:35] Launchpad bug 1049908 in lxc "[FFE] Upstart control of lxc container instances" [Medium,Confirmed] https://launchpad.net/bugs/1049908 [13:38] * smartboyhw discovers there will be no release weekly update email from Studio oh no:P [13:38] hallyn: reviewing [13:39] hallyn: btw, you should subscribe ~ubuntu-release to the FFe [13:39] i did [13:41] oh. well i did, but lp timed out. 9tab os still open) [13:41] hallyn: change looks reasonable. Did you try it with a lucid container to check that the two minutes timeout works properly and the container gets killed "properly"? [13:41] (lucid or anything that doens't have a SIGPWR handler) [13:42] stgraber: no, i'll set up a trst for that, thx [13:43] (we'll want to knwo that whether the ffe is granted or not :) [13:44] yeah, and I'm not going to grant the FFe if it regresses containers that aren't running >= precise :) [13:44] (especially as I'm running a fair number of those myself :)) [13:56] Laney: gah. i keep expecting bzr to dtrt :( [14:30] stgraber: lucid container stops just fine [14:30] skaet, meeting or not today ? [14:31] stgraber: and do so immediately, so i assume it's actually listening to sigpwr and shutting down [14:31] hallyn: hmm, it shouldn't, unless you backported the shutdown job in the lxc package? [14:32] hallyn: you may want to try removing the shutdown.conf job then and check what happens, without it, the container should take 2min doing nothing then be killed [14:32] http://paste.ubuntu.com/1247608/ [14:33] stgraber: yeah maybe you're right. [14:34] re-testing [14:37] stgraber: after 120 second timeout the container gets killed [14:37] so seems to DTRT to me [14:40] popey: The banshee thing doesn't look particularly critical to me (adding functionality that's merely missing, not broken, with a non-default application). [14:41] thanks for the feedback ScottK [14:41] popey: I was about to comment in the bug that it should wait. Do you disagree? [14:42] actually I don't. please comment away./ [14:43] hallyn: good [14:43] stgraber: actually, i'm not sure lxc-instance beahves the same on reboot [14:43] 'stop lxc-instance NAME=l1' waits for the timeout, [14:43] but i have a feeling that reboot immediately kills it. [14:45] popey: Thanks. [14:47] ogra_, yup meeting. [14:48] ok [14:48] feh, bad test [14:48] Yay meeting [14:48] skaet, thanks (i have a really sick cat around and need to schdule a vet appt. so i needed to know :) ) [14:49] skaet, scott-work will be too busy to send the release emails today:( [14:49] smartboyhw, he could have delegated to you :) [14:49] ogra_, well he didn't:P [14:49] ogra_, sorry about your cat. :( likely short one, since not that many reports made it in, but its important to sync up. [14:50] skaet, yeah, i guess he will be fine (has a red swollen nose looking like a clown atm) [14:51] likely some catfight leftover :) teenagers, y'know :) [14:51] poor fellow. sounds like an abscess, and yeah you want that looked at as soon as possible. :/ [14:51] yup [14:55] stgraber: all right, found a bug. at this point ig uess it waits until r :) [14:55] hallyn: what's the bug? [14:56] stgraber: if instance is running and you reboot, the lxc-instance job times out but then reboot is cancelled [14:57] it may be easy to fix but is subtle enough not to play with this late. [14:57] * hallyn biab [14:57] ok [14:59] ScottK: we seem to be good at coliding on FFes ;) [15:00] smartboyhw, you shoudl tell him your are available for the next time ;) [15:00] ogra_, I did tell him that I am available:P [15:01] stgraber: Did we agree? [15:01] Laney: What's the libaacs sync for? It looks fine; the changes just all appeared to be for other operating systems :-) [15:01] ScottK: initially, no, but after hallyn did some more tests, yes :) [15:02] All good then. [15:03] cjwatson: There's a leak fix that ricotz forgot to mention in the changelog === Ursinha is now known as Ursinha-afk [15:03] Ah, I noticed that and wondered if it was relevant. Fine then. [15:03] (it's a sponsored upload for him) [15:03] OK [15:10] Laney: I think I left gtkmm3.0 in the queue because the diff was giant and I was tired [15:10] Laney: I'll have a look over it now [15:11] I think xnox attempted to say something about it earlier but gave up before he got there ;-) [15:11] Laney: meh... i was wrong anyway [15:12] I guess the half-million line new file docs/reference/gtkmm-3.0.tag which I really don't care about helps [15:12] giant docs are giant [15:14] skaet: I will change the work item link for Ubuntu Studio in https://wiki.ubuntu.com/ReleaseTeam/Meeting/2012-09-28?action=show&redirect=ReleaseTeam%2FMeeting%2FAgenda, it got an extra hyphen:P [15:15] thanks smartboyhw :) appreciate it. [15:16] OK link changed [15:16] Eee 38% completed...Not good:( [15:18] Right. It's gigantic, but it's basically all docs, trivial changes such as whitespace, and bits of new API exposed from GTK+ that's appropriately annotated. Accepted. [15:25] xnox: So, this partman-auto upload looks right to me; nice work. However, doesn't automatically_partition/replace/choices need essentially the same changes? [15:25] xnox: I'll accept it for now as I think this is a clear improvement [15:25] cjwatson: Hahaha, re: metalink oops. [15:26] cjwatson: it probably does =) but need to check if I affects desktop installer. It does offer wipe & install currently. Unless replaces is something different.... [15:26] cjwatson: Also, that d-i upload there seems a bit premature with a new linux-ti-omap4 sitting in the queue... [15:27] which actually fixes a d-i issue :) [15:27] cjwatson: ok. thanks for accepting that. Also there is ubiquity commit to go with it: handling "quantal (development branch)" -> "12.10" upgrades. [15:27] infinity: Which I saw after the upload :-( [15:27] xnox: I forget what replace is [15:27] infinity: But I'd kind of like a new d-i before my EOD so that I can do some lowmem testing [15:27] cjwatson: also the reuse is not very multi-disk / multi-install aware..... [15:28] It was really more for that than the new kernel [15:28] cjwatson: Oh. I'll unreject the reject I just did. :P [15:28] Heh. Thanks [15:28] xnox: Yeah [15:28] Various bits of partman-auto aren't desperately so [15:28] cjwatson: And I'll do another bump tonight when ti-omap is done, no big deal. [15:28] cjwatson: if it's pre-existing it's not very RC then =) [15:28] Indeed [15:29] And the last thing in the queue is libgnomecanvas, which stgraber was questioning whether it needed an FFe [15:30] stgraber: If you think it would be bad for somebody else to accept it without having noticed the conversation, then reject and let stokachu know that it's a hold rather than a hard reject [15:30] cjwatson, pinged stokachu. maybe wait until Monday? [15:31] doko: I'm in no rush to accept it; I just want to make sure somebody doesn't accept it without seeing this conversation [15:31] * infinity would be inclined to grant it the FFe without the paperwork, personally. [15:31] * cjwatson has no opinion on that [15:31] The actual work looks fine to me, though I haven't line-by-lined it against Multiarch/Implementation [15:35] Oh, hey, maybe those -16 kernels should be in the release pocket first. [15:35] * infinity does that. [15:35] Oops, did I miss that? Sorry [15:36] All better. [15:36] I'll retry all the builds after the archive's sorter. [15:36] It'll be an hour before d-i can build, then :-/ [15:36] And sorted, too. [15:36] * cjwatson slowly climbs back up the stack to armel/powerpc builds working again [15:37] copied gtk+3.0 from -proposed === Ursinha-afk is now known as Ursinha [15:37] and I see -lowlatency's done too [15:38] I copied it too. [15:38] I may have also beaten you to gtk+3.0 [15:38] Meh, PCJs won't care much [15:38] Sadly, sru-release doesn't appear to actually check pending publishing records. [15:39] Or maybe it's copyPackage itself that doesn't. [15:39] Yay now I got scott's permission to send the mails:P [15:39] sru-release doesn't; the check is done in the async job [15:39] Or indeed Archive.copyPackage doesn't [15:39] Wait, did I understand you right? [15:40] Dunno. [15:40] Clearly, the checks happen a bit late in the tools, given that one ends up with two ACCEPTs, and two messages to -changes, and then the OOPS later. :P [15:41] Hah [15:41] The OOPS is a bug no matter what [15:41] I thought I'd fixed that, actually [15:41] cjwatson: is there a way to check who's the uploader for something in the queue? [15:41] Maybe not well enough [15:41] You may have fixed the OOPS. Check your mail, since it's your ACCEPT that should have oopsed. [15:41] stgraber: yes, multiarching is not a no-risk change and ought to go through FFe [15:42] But -changes definitely shows us both accepting gtk+3.0, so that part's broken for sure. :) [15:42] stgraber: Look at the .changes [15:42] slangasek, i'm poked about a MIR for the xdg pam stuff ... coudl you file one ? security team is informed [15:43] if a separate bug is wanted for the MIR, sure [15:43] apparently :/ [15:43] cjwatson: The .changes in the queue unhelpfully has the signature stripped. [15:44] ogra_, slangasek: nah, that's fine [15:44] ogra_, slangasek: I'm about to comment in the ffe bug [15:44] infinity: was just about to point that out :) [15:44] skaet, I will help to send the release meeting emails, I got permission from scott-work :) [15:44] mdeslaur: ok cool [15:44] mdeslaur, oh, great, the people in -meeting disagreed so heavily :) [15:44] and syncs have no .changes :-) [15:44] mdeslaur: how many beers is your comment costing me? :-) [15:45] slangasek, one [15:45] slangasek: none since you actually know how to write good code apparently :) [15:45] i dealt with that already ;) [15:45] heh [15:45] Laney: Syncs in the queue actually have an uploader associated with them anyway, quite prominently, so that's not hard to track down. :P [15:45] oh, i made the deal with jdstrand ... so he might claim the beverage at UDS :) [15:45] stgraber: I think failing that there's an API feature somewhere ... [15:46] slangasek, I don't care if it's a separate issue, just get the information filed and assign it to security [15:46] infinity: not sponsoree though. So it's kind of the opposite to what you get from .changes [15:46] (firefox hangs for a bit every time I look at +apidoc, so give me a minute) [15:47] Laney: Uploader is the more interesting person to me, most of the time, in that I hold them responsible for whatever broke. :P [15:47] huh, the uploader isn't exposed [15:47] Laney: (If they want to hunt down the person they broke things on behalf of, that's their issue) [15:48] It wouldn't be desperately hard to export PackageUpload.signing_key, if somebody wants a mini-project [15:49] cjwatson: getting a .uploader for queue entries giving us a person object would be neat, then I could finally have queuebot show the IRC nickname of the uploader :) [15:49] Although it might be better to export an API method with a reference to the person [15:49] So that you don't have to do URL hacking on signing_key.self_link to get it [15:50] Somebody should file a bug for it at least :) [15:50] It could just be a renamed version of findPersonToNotify [15:51] Though worth checking that it behaves properly for syncs [15:52] I suspect you could refactor _giveKarma a little bit in terms of it, too [15:52] skaet: ACK from the security team on pam-xdg-support (LP: #894391) [15:52] \o/ [15:52] processing linux-ac100 [15:52] whoo, snowed the security team again [15:52] mdeslaur: Many thanks. [15:53] fwiw before we seed it there's a license compatibility niggle to sort out [15:53] cjwatson: https://bugs.launchpad.net/launchpad/+bug/1058186 [15:53] Launchpad bug 1058186 in launchpad "Make it possible to retrieve the uploader (signer) of a package upload" [Undecided,New] [15:54] Ta [15:54] Any web UI change there would have to be careful to bulk-load the person objects or else it'll be timeout city [15:55] I think there might be a query limit test on the queue page already - if not there should be :) [15:55] Oh great, did somebody NBS-remove ac100 before processing NEW? [15:56] Whoever that was triggered a bug in kernel-overrides. :-) [15:58] cjwatson: linux-ac100 is pure universe anyway, if that helps. [15:58] ^ stokachu is now doing a few more rebuilds. I'll pull it from rejected once the paperwork is in order. [15:59] infinity: Yeah, I worked that out [15:59] thanks mdeslaur :) [15:59] I think the NBS bit may have been a red herring, as it let me remove those. Probably a bug somewhere else in kernel-overrides. [16:00] cjwatson: I can't say that I use kernel-overrides for >= precise anyway, since we don't actually have any kernel packages that publish to multiple components anymore. [16:00] cjwatson: But I guess it helps that I also do kernels enough to know which ones live where. [16:00] skaet, when you have a moment, could you please review https://bugs.launchpad.net/unity-lens-shopping/+bug/1055684 now b2 is out there [16:00] Launchpad bug 1055684 in unity-lens-shopping "[FFE] Use music lens details page for music store results" [High,In progress] [16:00] cjwatson: (Well, that's even true of SRU kernels at this point, where I know exactly which bits live where, but that's more a sad statement about repetition...) [16:03] Anyone have an opinion on the UIFe in bug 1043379? [16:03] Launchpad bug 1043379 in indicator-sync "[UIFe] sync indicator should use ubuntuone-client-* icons + new paused icon needed" [Low,Confirmed] https://launchpad.net/bugs/1043379 [16:03] Corresponds to an upload in the queue. [16:03] cjwatson: oh, I just rejected the upload because nobody had reviewed the UIFe yet :) [16:03] Hah [16:04] cjwatson: It doesn't sound like the sort of thing that would affect doc team screenshots and such, but they should probably still sign off. [16:04] (The feature itself sounds like something we'd want though, IMO) [16:05] Yeah [16:05] jbicha: Opinions? [16:05] didn't we (skaet) NACK indicator-sync by default anyway? [16:06] so, not a UIFe requiring upload. [16:06] Laney: ? [16:06] Laney: Context? [16:06] stgraber@castiana:~$ seeded-in-ubuntu indicator-sync [16:06] gir1.2-syncmenu-0.1 (from indicator-sync) is seeded in: [16:06] edubuntu: dvd [16:06] ubuntu: daily-live [16:06] Laney: ^ [16:07] and it's in main [16:07] ignore me, it's just an unrealted binary built from the same source :) [16:07] *unrelated [16:07] I'm pretty sure it got denied. [16:07] Yeah. [16:07] I'm curious why that unrelated binary ends up in live, actually. [16:08] if indicator-sync isn't included by default, it doesn't need UIFE [16:08] Which means not default which means not a UIF matter [16:08] Right. [16:08] Unrejecting. :P [16:08] * cjwatson gives back a bunch more stuff [16:08] infinity: they don't, only thing in daily-live is gir1.2-syncmenu-0.1 (that or seeded-in-ubuntu is lying) [16:09] stgraber: Yes, I was wondering about that binary specifically. :P [16:09] infinity: my guess is that ubuntuone is pulling it somehow so it can integrate if the indicator is installed [16:10] yeah, stuff uses the APIs [16:10]