[00:17] 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] ScottK: looking [00:22] Thanks. [00:23] well, once LP gives me a diff :) [00:23] http://paste.ubuntu.com/1257087/ [00:24] I guess that wasn't a case where you could get away with a generic usr/include/taglib/*.h? [00:26] anyway, accepted [00:45] ^ I guess that needs at least a verbal FFe since it adds a new (renamed) package but there aren't any rdepends [00:47] it won't build anyway until webkit makes it to quantal [00:47] 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] stgraber: Thanks. [00:48] ubiquity gtk_ui crashes, with no frontend available [00:51] ahh.. I solved it, but it's odd you get the kde version by default [00:51] why isn't ubiquity-frontend-gtk installed by default? [01:37] debfx: Laney: qtwebkit isn't supposed to be built from the qt4-x11 source since maverick, but from qtwebkit-source [02:25] would someone please rescore taglib. There's stuff in proposed that needs it to build. [02:27] ScottK: rescored [02:28] stgraber: Thanks. [04:47] jbicha, ping [04:47] I don't see a bug/reason for the telepathy-farstream sync. [04:48] NCommander: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686564 [04:48] Debian bug 686564 in libtelepathy-farstream2 "Breaks theora video calling" [Grave,Fixed] [04:49] jbicha, thanks,accepted [04:50] (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] 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] balloons: and really, REALLY don't run ubiquity on your regular system. it is not even slightly a good idea ... [07:20] (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] Laney: ignore the mail about my mistaken copy of make-dfsg to quantal-updates rather than quantal - I deleted that again [08:46] micahg: it's a bit more complicated than that [08:47] cjwatson: righto. You got in before I saw it [09:24] Riddell: ^- no Replaces: field? [09:25] cjwatson: is that needed in -proposed? [09:25] surely -proposed is for people who do testing? [09:27] There's no harm in adding Replaces, and it may help [09:27] So why not? [09:27] ok dokay [09:28] If it gets rid of even a handful of confused bug reports it's worth it === mmrazik is now known as mmrazik|lunch [11:00] Could somebody review ubiquity in unapproved, please? === mmrazik|lunch is now known as mmrazik [11:52] In fact if somebody other than me could do any queue review that would be pretty nice. :-) [11:52] :P [11:54] I'll do some in a bit. [11:54] post lunch [11:54] Thanks [11:55] 283 results :( [11:55] oh, langpacks [11:55] Huh [11:55] I can deal with those ... [12:05] Flushed. [12:06] how do you deal with those? do you just accept them? [12:06] Yeah [12:06] Well I spot-checked one that it looked vaguely reasonable [12:06] 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] They don't *always* get uploaded in a giant block [12:07] ok then [12:08] Just often [12:08] I expect I have some status quo bias; I think I'm happier with fewer ginormous source packages though [12:15] some of them are very small like 9kB src & 3kB binary.... [12:16] gnome and kde-base are big. [12:16] * xnox meh... [12:16] the non-base ones alternate between tiny and huge [12:29] 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] urgh, I need to catch up on FFe bugs first [12:31] I don't think they are overwhelming tumbleweed [12:31] no, but tehy're in a busy inbox [12:31] tumbleweed: yeah, inbox traffic has indeed been high [12:33] Daviey, thanks for geary! [12:34] seb128: np === yofel_ is now known as yofel [13:20] 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] Launchpad bug 1056381 in xserver-xorg-video-qxl "[FFe: spice] error on x startup" [High,Confirmed] https://launchpad.net/bugs/1056381 [13:20] but, better safe than sorry :) [13:24] 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] stgraber: quoted into the bug you mean? [13:27] hallyn: yes, please [13:28] ok === smartboyhw is now known as nemesis-project === nemesis-project is now known as smartboyhw [13:40] rejected wakeup as it's a feature change without a FFe or even a bug (re-adding evolution plugin) [14:01] stgraber: (posted to the bug) [14:02] hallyn: yep and I added the upstream changelogs for each now [14:02] cjwatson, ahh, so no running of ubiquity to install to another target eh? Guess I can close my own bug found then :-) [14:04] 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] balloons: Yeah, that's explicitly unsupported [15:18] 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] yes plars [15:18] 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] thanks plars [17:04] * iulian wonders why spice is sitting in the queue if its FFe hasn't been approved yet. [17:04] stgraber: Are you looking at spice? [17:07] 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] stgraber: I have no experience with spice at all and thus I shall leave it to someone else. [17:15] stgraber: It sounds like you have as much experience as anyone, given that you've, I dunno, used it. :P [17:16] 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 === LordOfTime is now known as TheLordOfTime [19:05] popey: hey, it finally built, and seems to work here :) [19:05] woooooot [19:06] plars, so can you open music with a right click and then play preview from the store? [19:06] * popey crosses fingers [19:07] popey: right click, yes - from the main results this time too (not just music) [19:07] excellent, thanks plars, much appreciated, could you please leave a comment on bug 1055684 ? [19:07] 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] popey: I think I'm missing the bits I need to playback the preview... let me install that [19:11] https://launchpad.net/ubuntu/+source/qt4-x11/4:4.8.3+dfsg-0ubuntu3/+build/3871112 === seb128_ is now known as seb128 [20:16] 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] infinity: cool, thanks [20:18] mdeslaur: NP, happy to reject more security uploads! [20:18] lol :) [20:18] stupid security updates wasting all the CPU time :) [20:19] mdeslaur: I'm still bitter about the security update to precise that wiped out two weeks of testing on my eglibc SRU. :/ [20:20] 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] infinity: I thought about mentioning it but figured you would see it in backscroll, will highlight next time [20:21] infinity: yeah, it sucks when that happens. sorry about that....I believe it got started a while ago [20:21] micahg: Erm, hilighting me after it's uploaded would have been a bit too late anyway. [20:22] 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] infinity: they discussed it a bit first :) [20:22] micahg: But not with me, nor with regard to the SRU, that's the bit that's annoying me. [20:22] micahg: And it's pretty non-obvious to people who aren't paying really close attention when their SRU just disappears. [20:23] infinity: oh, I thought you meant the devel upload, yeah, I wasn't around for the security update in stable [20:23] micahg: Oh, no, the devel upload is fine. I just rejected it to avoid wasting resources. [20:23] micahg: This is entirely about the precise upload. [20:24] 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] infinity: we'll make it up to you with some security team beer at uds ;P [20:28] mdeslaur: But. But. You guys aren't half as fun as the kernel team. [20:29] mdeslaur: You can always stop by their table and buy us a round. :) [20:29] infinity: oh, we go to the Kernel Team Variety Show too! [20:42] seb128, ping, I see an entire set of indicator-* packages in the queue with no attached bug. [20:42] What changes are they making? [20:42] NCommander: There's no requirement for a bug. Read the diff. [20:42] (I see new upstream version released) [20:42] ScottK, I did, the diff just says new upstrema version with no reason [20:43] As long as the new version is bugfix only, that's sufficient. [20:43] NCommander, #ps is just rolling stable tarballs for release, translation updates, minor cleanups [20:43] seb128, thanks [20:43] ScottK, I'm aware of that, but I do like to verify $WORLD :-). Call it insanity/pendaticness [20:43] seb128, I'll release the entire set now [20:44] NCommander, thanks [21:21] 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] ogasawara: Yeahp, can do. [21:23] infinity: thanks, you're the best [21:23] ogasawara: Aww, I'm blushing. [21:32] popey: ok, I can confirm that preview works too, sorry for the delay [21:32] plars, no need to apologise, I really appreciate you taking the time to test it, thanks! [21:32] infinity: are you handling d-i uploads? [21:33] Daviey: I will in ~8h, yeah. [21:33] rocking banana ! [21:33] (When the kernel builds are all done and such) [21:51] 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] the various persistence changes have been tested and so has the username/userfullname/hostname override [21:52] 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] stgraber: Tested "most" is really giving me confidence. ;) [21:53] infinity: it's casper we're talking about ;) testing all the possible paths in that thing would take years... [22:38] kde-baseapps is me trying to salvage some binaries. [23:02] ScottK: Was there a double-override-loss-of-binaries oops? [23:07] apw: Danke. [23:08] infinity, np [23:11] infinity: No, there was a copy-from-proposed-before-armhf-built oops [23:11] wgrant: Ahh. Oops indeed. [23:11] infinity: ScottK and I are poking to copy them across [23:11] wgrant: Thanks for helping. [23:11] Using the same binary recovery method that's never been used on the primary archive before [23:11] And running into some issues [23:12] But I think we'll have it sorted out once he's back to rerun the copy [23:12] And then we'll know this works and can use it properly in future [23:14] 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] 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] 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] Yeah, I've used THAT copy trick before. [23:15] updates -> proposed -> updates [23:15] Right [23:16] It's from a pocket to itself that's the curiously bizarre use-case. [23:17] And the non-deterministic override selection issue is a bit problematic, but relatively easily fixable.