[00:17] <ScottK> It would be lovely if someone could review/accept the taglib update.   That's needed to fix one of the KDE build failures we had.
[00:22] <stgraber> ScottK: looking
[00:22] <ScottK> Thanks.
[00:23] <stgraber> well, once LP gives me a diff :)
[00:23] <ScottK> http://paste.ubuntu.com/1257087/
[00:24] <stgraber> I guess that wasn't a case where you could get away with a generic usr/include/taglib/*.h?
[00:26] <stgraber> anyway, accepted
[00:45] <jbicha> ^ I guess that needs at least a verbal FFe since it adds a new (renamed) package but there aren't any rdepends
[00:47] <jbicha> it won't build anyway until webkit makes it to quantal
[00:47] <balloons> can anyone tell me if I'm doing something wrong -- I'm trying to launch ubiquity from my quantal box, but it only wants to run the kubuntu installer
[00:48] <ScottK> stgraber: Thanks.
[00:48] <balloons> ubiquity gtk_ui crashes, with no frontend available
[00:51] <balloons> ahh.. I solved it, but it's odd you get the kde version by default
[00:51] <balloons> why isn't ubiquity-frontend-gtk installed by default?
[01:37] <micahg> debfx: Laney: qtwebkit isn't supposed to be built from the qt4-x11 source since maverick, but from qtwebkit-source
[02:25] <ScottK> would someone please rescore taglib.  There's stuff in proposed that needs it to build.
[02:27] <stgraber> ScottK: rescored
[02:28] <ScottK> stgraber: Thanks.
[04:47] <NCommander> jbicha, ping
[04:47] <NCommander> I don't see a bug/reason for the telepathy-farstream sync.
[04:48] <jbicha> NCommander: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686564
[04:48] <ubot2> Debian bug 686564 in libtelepathy-farstream2 "Breaks theora video calling" [Grave,Fixed]
[04:49] <NCommander> jbicha, thanks,accepted
[04:50] <NCommander> (Its an annoying PITA to look at sync changelogs since Launchpad doesn't give me a handy link like it does with uploads)
[07:18] <cjwatson> balloons: it'll be random.  I see no need to explicitly prefer any particular frontend since we always select a particular one during live fs building
[07:19] <cjwatson> balloons: and really, REALLY don't run ubiquity on your regular system.  it is not even slightly a good idea ...
[07:20] <cjwatson> (it will at the very least feel free to make configuration changes to the running system and is not at all guaranteed to put things back the way they were later)
[08:43] <cjwatson> Laney: ignore the mail about my mistaken copy of make-dfsg to quantal-updates rather than quantal - I deleted that again
[08:46] <debfx> micahg: it's a bit more complicated than that
[08:47] <Laney> cjwatson: righto. You got in before I saw it
[09:24] <cjwatson> Riddell: ^- no Replaces: field?
[09:25] <Riddell> cjwatson: is that needed in -proposed?
[09:25] <Riddell> surely -proposed is for people who do testing?
[09:27] <cjwatson> There's no harm in adding Replaces, and it may help
[09:27] <cjwatson> So why not?
[09:27] <Riddell> ok dokay
[09:28] <cjwatson> If it gets rid of even a handful of confused bug reports it's worth it
[11:00] <cjwatson> Could somebody review ubiquity in unapproved, please?
[11:52] <cjwatson> In fact if somebody other than me could do any queue review that would be pretty nice. :-)
[11:52] <smartboyhw> :P
[11:54] <Laney> I'll do some in a bit.
[11:54] <Laney> post lunch
[11:54] <cjwatson> Thanks
[11:55] <Laney> 283 results :(
[11:55] <Laney> oh, langpacks
[11:55] <cjwatson> Huh
[11:55] <cjwatson> I can deal with those ...
[12:05] <cjwatson> Flushed.
[12:06] <Laney> how do you deal with those? do you just accept them?
[12:06] <cjwatson> Yeah
[12:06] <cjwatson> Well I spot-checked one that it looked vaguely reasonable
[12:06] <cjwatson> But I'm not going to review them all :-)
[12:06]  * xnox ponders why is it source package per lang, instead of singe source package with binary package per lang.
[12:07] <cjwatson> They don't *always* get uploaded in a giant block
[12:07] <xnox> ok then
[12:08] <cjwatson> Just often
[12:08] <cjwatson> I expect I have some status quo bias; I think I'm happier with fewer ginormous source packages though
[12:15] <xnox> some of them are very small like 9kB src & 3kB binary....
[12:16] <xnox> gnome and kde-base are big.
[12:16]  * xnox meh...
[12:16] <cjwatson> the non-base ones alternate between tiny and huge
[12:29] <tumbleweed> meep, I should also do a queue pass. I haven't been doing much recently
[12:29]  * smartboyhw wonders why everyone suddenly caught up with queue passing today:P
[12:30] <tumbleweed> urgh, I need to catch up on FFe bugs first
[12:31] <Daviey> I don't think they are overwhelming tumbleweed
[12:31] <tumbleweed> no, but tehy're in a busy inbox
[12:31] <Daviey> tumbleweed: yeah, inbox traffic has indeed been high
[12:33] <seb128> Daviey, thanks for geary!
[12:34] <Daviey> seb128: np
[13:20] <hallyn> hi - IIRC when I asked beofre, for bug 1056381, it was said an FFE for spice isn't needed since it's needed for a qxl bugfix?
[13:20] <ubot2> Launchpad bug 1056381 in xserver-xorg-video-qxl "[FFe: spice] error on x startup" [High,Confirmed] https://launchpad.net/bugs/1056381
[13:20] <hallyn> but, better safe than sorry :)
[13:24] <stgraber> hallyn: can we get a changelog for all those packages? that'd make it easier to figure out whether there are any feature changes that'd indeed require an FFe
[13:26] <hallyn> stgraber: quoted into the bug you mean?
[13:27] <stgraber> hallyn: yes, please
[13:28] <hallyn> ok
[13:40] <stgraber> rejected wakeup as it's a feature change without a FFe or even a bug (re-adding evolution plugin)
[14:01] <hallyn> stgraber: (posted to the bug)
[14:02] <stgraber> hallyn: yep and I added the upstream changelogs for each now
[14:02] <balloons> cjwatson, ahh, so no running of ubiquity to install to another target eh? Guess I can close my own bug found then :-)
[14:04] <xnox> balloons: already won't fixed it. =) ubiquity more-or-less copies the whole system it's booted of (the live-cd) + does cleanup. And since installed systems != livecd special built the results are unexpected =)
[14:32] <cjwatson> balloons: Yeah, that's explicitly unsupported
[15:18] <plars> popey: so should I use ppa:unity-team/ppa then? I looked at unity-team/release and it doesn't appear to be set to build for arm at all
[15:18] <popey> yes plars
[15:18] <plars> popey: ok, I had the wrong one yesterday it seems, it looks like arm still isn't build though so I'll check back later today
[15:19] <popey> thanks plars
[17:04]  * iulian wonders why spice is sitting in the queue if its FFe hasn't been approved yet.
[17:04] <iulian> stgraber: Are you looking at spice?
[17:07] <stgraber> iulian: I can review it later today but I wouldn't mind another review of the FFe by someone who knows a bit more about spice. I'm just the original reporter of the bug as I tried using spice a couple of weeks ago and noticed that X wouldn't start in my VM.
[17:08] <iulian> stgraber: I have no experience with spice at all and thus I shall leave it to someone else.
[17:15] <infinity> stgraber: It sounds like you have as much experience as anyone, given that you've, I dunno, used it. :P
[17:16] <stgraber> hmm, then I'll give it another look and if I don't spot anything that looks scary I'll accept the FFe. Current state is that X doesn't start, so can't get much worse than that I guess
[19:05] <plars> popey: hey, it finally built, and seems to work here :)
[19:05] <popey> woooooot
[19:06] <popey> plars, so can you open music with a right click and then play preview from the store?
[19:06]  * popey crosses fingers
[19:07] <plars> popey: right click, yes - from the main results this time too (not just music)
[19:07] <popey> excellent, thanks plars, much appreciated, could you please leave a comment on bug 1055684 ?
[19:07] <ubot2> Launchpad bug 1055684 in unity-lens-shopping "[FFE] Use music lens details page for music store results" [High,In progress] https://launchpad.net/bugs/1055684
[19:08] <plars> popey: I think I'm missing the bits I need to playback the preview... let me install that
[19:11] <Laney> https://launchpad.net/ubuntu/+source/qt4-x11/4:4.8.3+dfsg-0ubuntu3/+build/3871112
[20:16] <infinity> I'm rejecting eglibc, since I plan to do an upload today, and it'll be a waste of buildd time to build both, I'll make sure the one in the queue is included in mine.
[20:17] <mdeslaur> infinity: cool, thanks
[20:18] <infinity> mdeslaur: NP, happy to reject more security uploads!
[20:18] <mdeslaur> lol :)
[20:18] <mdeslaur> stupid security updates wasting all the CPU time :)
[20:19] <infinity> mdeslaur: I'm still bitter about the security update to precise that wiped out two weeks of testing on my eglibc SRU. :/
[20:20] <infinity> mdeslaur: (Reeeeeally would have been nice if someone had at least tried to contact me and coordinate that)
[20:21]  * NCommander sits down and deals with the unapproved queue
[20:21] <micahg> infinity: I thought about mentioning it but figured you would see it in backscroll, will highlight next time
[20:21] <mdeslaur> infinity: yeah, it sucks when that happens. sorry about that....I believe it got started a while ago
[20:21] <infinity> micahg: Erm, hilighting me after it's uploaded would have been a bit too late anyway.
[20:22] <infinity> mdeslaur: The annoyance is that I could have finished off the SRU testing pretty quickly, and we could have pushed the security update on top.
[20:22] <micahg> infinity: they discussed it a bit first :)
[20:22] <infinity> micahg: But not with me, nor with regard to the SRU, that's the bit that's annoying me.
[20:22] <infinity> micahg: And it's pretty non-obvious to people who aren't paying really close attention when their SRU just disappears.
[20:23] <micahg> infinity: oh, I thought you meant the devel upload, yeah, I wasn't around for the security update in stable
[20:23] <infinity> micahg: Oh, no, the devel upload is fine.  I just rejected it to avoid wasting resources.
[20:23] <infinity> micahg: This is entirely about the precise upload.
[20:24] <infinity> micahg: Which, along with resetting my SRU timer, also broke a whole class of users who had been happily using the one in -proposed. :/
[20:28] <mdeslaur> infinity: we'll make it up to you with some security team beer at uds ;P
[20:28] <infinity> mdeslaur: But.  But.  You guys aren't half as fun as the kernel team.
[20:29] <infinity> mdeslaur: You can always stop by their table and buy us a round. :)
[20:29] <mdeslaur> infinity: oh, we go to the Kernel Team Variety Show too!
[20:42] <NCommander> seb128, ping, I see an entire set of indicator-* packages in the queue with no attached bug.
[20:42] <NCommander> What changes are they making?
[20:42] <ScottK> NCommander: There's no requirement for a bug.  Read the diff.
[20:42] <NCommander> (I see new upstream version released)
[20:42] <NCommander> ScottK, I did, the diff just says new upstrema version with no reason
[20:43] <ScottK> As long as the new version is bugfix only, that's sufficient.
[20:43] <seb128> NCommander, #ps is just rolling stable tarballs for release, translation updates, minor cleanups
[20:43] <NCommander> seb128, thanks
[20:43] <NCommander> ScottK, I'm aware of that, but I do like to verify $WORLD :-). Call it insanity/pendaticness
[20:43] <NCommander> seb128, I'll release the entire set now
[20:44] <seb128> NCommander, thanks
[21:21] <ogasawara> infinity: could I get those linux and linux-meta uploads approved?  It should be our last before kernel freeze tomorrow.  it's an ABI bumper too.
[21:22] <infinity> ogasawara: Yeahp, can do.
[21:23] <ogasawara> infinity: thanks, you're the best
[21:23] <infinity> ogasawara: Aww, I'm blushing.
[21:32] <plars> popey: ok, I can confirm that preview works too, sorry for the delay
[21:32] <popey> plars, no need to apologise, I really appreciate you taking the time to test it, thanks!
[21:32] <Daviey> infinity: are you handling d-i uploads?
[21:33] <infinity> Daviey: I will in ~8h, yeah.
[21:33] <Daviey> rocking banana !
[21:33] <infinity> (When the kernel builds are all done and such)
[21:51] <stgraber> if someone wonders, I've tested most of the changes in that casper upload. I couldn't really test the RAID stuff, but my guess is that it can't be much worse than what they have now (failure to boot)
[21:51] <stgraber> the various persistence changes have been tested and so has the username/userfullname/hostname override
[21:52] <stgraber> The network changes have been tested from busybox (to check that the syntax is fine) but I don't have a netboot environment here to test that it actually works at runtime (but the code is so similar that it really should)
[21:52] <infinity> stgraber: Tested "most" is really giving me confidence. ;)
[21:53] <stgraber> infinity: it's casper we're talking about ;) testing all the possible paths in that thing would take years...
[22:38] <ScottK> kde-baseapps is me trying to salvage some binaries.
[23:02] <infinity> ScottK: Was there a double-override-loss-of-binaries oops?
[23:07] <infinity> apw: Danke.
[23:08] <apw> infinity, np
[23:11] <wgrant> infinity: No, there was a copy-from-proposed-before-armhf-built oops
[23:11] <infinity> wgrant: Ahh.  Oops indeed.
[23:11] <wgrant> infinity: ScottK and I are poking to copy them across
[23:11] <infinity> wgrant: Thanks for helping.
[23:11] <wgrant> Using the same binary recovery method that's never been used on the primary archive before
[23:11] <wgrant> And running into some issues
[23:12] <wgrant> But I think we'll have it sorted out once he's back to rerun the copy
[23:12] <wgrant> And then we'll know this works and can use it properly in future
[23:14] <wgrant> The latest trick is that copyPackage doesn't let you specify a custom source pocket, instead just picking the latest publication with that (archive, name, version)
[23:15] <wgrant> So asking it to copy that version picks the release publication, not the proposed one, so it doesn't grab the missing binaries
[23:15] <wgrant> But if we copy it back to proposed, then from proposed back to release, it will grab the missing binaries, and all will be good in the world.
[23:15] <infinity> Yeah, I've used THAT copy trick before.
[23:15] <infinity> updates -> proposed -> updates
[23:15] <wgrant> Right
[23:16] <infinity> It's from a pocket to itself that's the curiously bizarre use-case.
[23:17] <wgrant> And the non-deterministic override selection issue is a bit problematic, but relatively easily fixable.