[00:21] * infinity feeds the poor, lonely buildds. [00:33] cjwatson: Argh. [00:34] cjwatson: Did you overzealously remove linux from -proposed? [00:35] cjwatson: Yup, you sure did. :/ [00:35] wgrant: So, silly copying tricks. Is there a clever way to get https://launchpad.net/ubuntu/+source/linux/3.5.0-17.27/+publishinghistory undeleted? [00:36] wgrant: With bonus points for having it back before the builds complete? ;) [00:36] infinity: If the source is deleted, then yeah [00:36] wgrant: It is. [00:36] Use copy-package's version argument [00:36] The API doesn't require the package to not be deleted [00:37] It's possible that your copy-package script does, but you can just hack that check out if it whinges [00:37] copy-package -b -e 3.5.0-17.27 --to-suite=quantal-proposed linux [00:37] I think [00:38] I had a -s quantal-proposed in mine too.. [00:38] * infinity knocks that out. [00:38] That's probably just used to find the origin version [00:39] So it should be irrelevant when -e is specified [00:39] But checking [00:41] * infinity comments some bits out. [00:41] Ah, so find_latest_published_source requires -s and that the package be currently published [00:42] Oh, hrm. Yeah. [00:42] I'd just eliminate that and use options.version directly in copy_packages [00:42] Remove the find_latest_published_source call [00:42] And more to the point, I can't just comment those bits out, cause it's used for versions too. [00:42] source_name=package, version=source.source_package_version, [00:42] version=options.version [00:42] done [00:42] Yeah, just did that. :P [00:43] Alright, that may or may not have just done... Something. [00:44] infinity, ScottK: BTW, the copier diff bug that broke both your binary revival attempts was fixed yesterday, will be on production next week [00:44] infinity: You copied it twice [00:44] infinity: It's in Unapproved now [00:44] Twice? Go me. [00:44] wgrant: The billion dollar question is what this will do to the builds. [00:45] infinity: If you copied with -b, nothing [00:45] They should continue and then be accepted fine [00:45] No new ones will be created [00:45] wgrant: Sure, and the two that already failed due to being for superseded source? [00:45] wgrant: Need SQL intervention to kick them back to needs-build? :/ [00:46] 2012-10-05 00:45:18 INFO Job: [00:46] [00:46] raised CannotCopy: [00:46] linux 3.5.0-17.27 in quantal (source has no binaries to be copied) [00:46] It was copied before there were any binaries at all? [00:46] Just builds, no binaries. [00:46] It was deleted before any builds completed. [00:46] https://launchpad.net/ubuntu/+source/linux/3.5.0-17.27 [00:46] Ah, OK [00:46] Trying to load, LP not being forgiving [00:46] But copy without -b [00:47] Since there are no binaries in either suite, a source-only copy will work fine [00:47] But you are correct that the amd64/i386 builds will need manual recovery [00:47] Bugger. [00:47] For added fun, we have no ops [00:47] We have GSAs. [00:48] We do [00:48] If you know the magic required. [00:48] And I guess we have bigjools to approve [00:48] But we have no webops or lifeless [00:48] So, copy without -b [00:48] To get the soruce back and salvage the other three builds [00:48] I haven't surgerised that table in years. [00:48] It's a really easy query. I'll just set them to failed, then retry. [00:48] Check. [00:48] New copy accepted. [00:49] No need to mess with the buildqueue etc. [00:49] linux 3.5.0-17.27 in quantal (same version already building in the destination archive for Quantal) [00:49] blaaargh [00:49] Yeah, this isn't going to work :/ [00:49] If there was a single binary in the initial copy it would have been fine. [00:49] Oh, bah. [00:49] But since it was copied with nothing, we're stuck [00:50] Hrm. What if I just copy it to release? Will that suffer the same issue? [00:50] It's not an ABI change, there's no real reason it needs to be in proposed. [00:50] Copy what to release? [00:50] The source. [00:50] Oh, it's not already there? [00:50] Or will it still have a sad about it being currently building? [00:50] No, it's in proposed. [00:50] Well, it WAS in proposed, and that's where I was copying it to. [00:51] I assumed it was deleted from proposed because it was copied to release [00:51] But I see now it's entirely gone. [00:51] The release copy will fail the same way [00:51] No, it was deleted from proposed because the previous version was moved to release, and Colin wasn't paying attention. :P [00:51] Heh [00:51] So, if all the builds were to spontaenously fail, would that help us any? [00:52] Or is "building in destination" not actually what it says? [00:53] A source-only copy will work if the builds are all failed [00:53] That, I can do. [00:53] So if you want to kill those three, you can copy it back into proposed source-only, retry the builds, and then we can fix the x86 stuff [00:53] They need to actually be failed, though, not just not building. [00:54] wgrant: They'll be failed shortly. If DarrenS loves me. [00:57] Although it's not directly relevant here, builds will complete and upload successfully as long as the source is published somewhere in the archive. The suite doesn't necessarily need to match [00:57] And you can then use the binary revival trick (once the bugfix is deployed) to copy them into the right pocket. [00:58] wgrant: And that would be more interesting if I could have rescued the source in the first place. ;) [00:58] Yeah [00:59] wgrant: Oh, and it's going to have to be SQL surgery on i386, amd64, and powerpc. The latter finished while we were talking. [01:00] Yeah, so I saw [01:00] And armel and armhf now dead. [01:00] Well, armhf is in the death throes... [01:00] armhf still seems alive [01:00] * infinity waits. [01:00] Yeah [01:00] Once it's failed properly, retry the source-only copy [01:01] * wgrant prepares SQL [01:01] There. [01:02] BuildStatus.SUPERSEDED should possibly be retriable nowadays, since it is possible to unsupersede things [01:02] But it's historically been our go-to status for making builds unretriable. [01:03] * infinity accepts and crosses his fingers. [01:04] 2012-10-05 01:03:17 INFO Ran 1 PlainPackageCopyJob jobs. [01:04] It worked. [01:05] It did indeed. And beat the publisher by a matter of seconds. [01:05] * infinity fires up the ARM builds again. [01:08] wgrant: Right, all looks snazzy. Whenever you can make the SQL mojo go, that'd be nice. You have a couple of hours of slack time, thanks to those builds being wildly faster than armhf. :P [01:08] Heh [02:26] ^-- lolwut? [02:27] Oh, that's the amd64 build, queuebot's confused. [03:18] wgrant: Thanks. Both for the quick turn around and the update. [03:59] Bug #1057518 has UI changes, could someone tell me if a UIFe is needed? [03:59] Launchpad bug 1057518 in onboard "debian.tar.gz supplied: New upstream release 0.98.1 available" [Undecided,New] https://launchpad.net/bugs/1057518 === cyphermox_ is now known as cyphermox [04:17] is 'Added NVIDIA driver detection' to checkbox called a feature? [04:18] * micahg rings the bell on the counter to see if anyone is around :) [04:18] That sounds like a feature to me, but I'm not exactly on the release team. [04:20] right, which is why I'm asking :) [04:28] micahg: Yes and yes. [04:28] ScottK: thanks for the confirmation :) [04:33] It's a feature for sure, but depending on the size of the code, and how obviously unbroken it seems, it may be FFeable. [04:36] looks FFeable, just wasn't sure if that qualified as a feature for checkbox [04:37] Pretty much any new code that isn't directly fixing a bug that could only be fixed by refactoring a bit is a "feature", to be fair. [04:37] That was a convoluted sentence. [04:37] fair enough :) [04:45] infinity: I'm working on some no change rebuilds so we can get the binaries that got missed when Riddell prematurely copied from proposed (you can see the first one ^^^). I'd appreciate if you could push them through. [04:46] ScottK: I'm working on wandering away from my computer and killing brain cells with gin, but I'll poke at things randomly when I come back. [04:46] Thanks, but you know what gin is made from, right? [04:46] ScottK: Love. [04:46] Juniper berries. [04:47] ScottK: And love. [04:47] And do you know what juniper berries are? [04:47] They are poisonous. [04:47] Just saying. [04:47] So are tomatoes, in large enough quantity, doesn't stop people from eating 'em. [04:49] Shortly after one of my brothers graduated from high school he got sick enough from gin that for years afterwards all you had to do way say the word and he would turn pale. [04:49] ;-) [04:56] scottk: did you want to review kaffeine in precise-proposed? (when you're done with your no change rebuilds)? [04:57] Depends on if I run out of steam or not. [05:16] hrm, i'm guessing I need a UIFe to upload Bug #621204 as well [05:16] Launchpad bug 621204 in im-switch "Typo in error string" [Undecided,In progress] https://launchpad.net/bugs/621204 [05:29] micahg: Done. [05:30] BTW, that's it for the KDE rebuilds for missing binaries. Maybe if the gin gets infinity, Riddell will tend to them once he wakes up. [05:39] scottk: thanks [06:39] infinity: argh sorry [06:42] infinity: we really should make pending-sru's recommendation be to remove by version [07:48] cjwatson, infinity, linux-signed above is the packaging half of the signing changes; if you would review w [07:48] (so much for waiting till it appeared) [07:52] cjwatson: Did you want to review the linux/amd64 in unapproved, since you have a vague idea of WTF should be in the tarball? ;) [07:53] I suppose I'd better [07:53] " Archive admins should review the corresponding source upload for correctness prior to approving these uploads" [07:53] BRB in a week [07:54] I reviewed the source and it seemed vaguely sane... [07:54] But, I'm not as well-versed in how this is all meant to work. [07:55] * apw notes there is at least the correct extra binary in the upload [07:55] (in the linux/amd64 binary) === henrix_ is now known as henrix [08:15] cjwatson: -e default> yes please. I don't think I've wanted the prefix/substring/whatever behaviour yet. [08:16] I use it for langpacks. [08:16] But that's a perfectly reasonable sort of use-case for pattern-matching being an argument, not the inverse. [08:16] Yep. [08:29] linux/amd64 accepted now. Distracted by an argument, sorry. [08:29] Wait, why didn't that work [08:30] Sigh. Accepted by id, can't be bothered to debug why by name didn't work === henrix is now known as henrix_ === henrix_ is now known as henrix [09:04] ScottK: I'm confused, https://launchpad.net/ubuntu/+source/kde-baseapps/4:4.9.2-0ubuntu4 exists but is not on https://launchpad.net/ubuntu/+source/kde-baseapps [09:04] oh wait, it just appeared [09:04] good I guess that's sorted, thanks much for doing that [09:09] What happened with those KDE builds? Were they copied in advance of pending-sru saying that all the builds were done? [09:10] (And could somebody have a look through my 30 no-change rebuilds in the queue?) [09:10] cjwatson: yes I copied them early which apparantly confuses launchpad [09:11] doing [09:11] I added a --names-only to queue locally so that I can loop over queuediff [09:11] Riddell: Yeah, please don't do that, that's why we have pending-sru list the build states [09:12] cjwatson: where is pending-sru? [09:12] http://people.canonical.com/~ubuntu-archive/pending-sru.html [09:12] section near the bottom for quantal [09:21] does queuediff cache the fact that there's no diff available? [09:22] I think it tends to run into proxy trouble a good bit === mmrazik is now known as mmrazik|lunch === mmrazik|lunch is now known as mmrazik === henrix_` is now known as henrix [11:10] Found one more KDE package needs rebuilding. [11:11] Riddell: kdepim-runtime should appear forthwith. === doko_ is now known as doko [11:46] Found another one. [11:46] smokekde should be along in a moment. [11:50] What's the barrier for desktop interface freeze? [11:50] https://wiki.ubuntu.com/DesktopInfrastructureFreeze "no further fixes" [11:50] s/interface/infrastructure/ [11:50] yeah [11:50] IMO anything that doesn't affect the users of that infrastructure shouldn't count: e.g. FTBFS fixes [11:51] I mean I would see that as an obvious case for an exception [11:51] so I have a fix for a crash in a library which occurs on non-default setups [11:51] can I upload that, for example? [11:51] Where did that come from? [11:51] the fix? [11:51] The freeze [11:52] oh, I'm not really sure about it [11:52] I lose track. [11:52] That doesn't even make sense. [11:52] Laney: I would upload it for review if I were you. [11:53] I feel like I should understand it so that I can review stuff too [11:53] I've no idea what the bounds of desktop infrastructure are either. [11:53] Laney: Don't worry, you're not the only one. [11:54] It feels like "hey can we not have lots of unity churn after here" [11:54] But it's not well-phrased. [11:55] We already have a freeze that's supposed to cover that. [11:55] Feature freeze. [12:32] cjwatson: have you had any feed back from kernel / X-org team re: PPC? [12:43] phillw: No; you'll need to chase them if you want an answer, as I absolutely don't have time [12:45] cjwatson: Thanks, I'll go in to full nagging mode :) If that fails, would you allow the change? (It would be, as you state, a 'bodge job' instead of a fix) [12:51] phillw: No, I want an ack from one of those teams one way or the other telling me what to do [12:51] I'm not going to take responsibility for changing those boot parameters without that, given that I don't really understand them [12:52] So I want at least *one* of our relevant developers to look it over and tell me what they think, even if they don't fix the underlying bug(s) [12:53] Without that I'm afraid I'm going to leave it as it is, on the basis that currently I'm hearing from people who are broken by the current setting, but for all I know some different group of people might be broken by the change [12:53] cjwatson: and we both know that one will blame the other... [12:53] (And obviously I wouldn't hear from the latter until after changing things) [12:56] cjwatson: shame they were not on the 24 hour marathon. Would have been a really good time to bash heads together. [12:57] What, when people are low on sleep? Doesn't seem like a good time to me ... [12:57] cjwatson: I got in early :) [12:57] I don't want a coerced or thoughtless answer; I want an actual one [12:59] cjwatson: so do I... So, why do -kernel and -xorg keep kicking the critical bugs into the 'long grass'? [12:59] cjwatson: [13:00] cjwatson: A3 worked, these bugs are 100% regression issues. [13:00] I expect they're upstream regressions that have not been reported coherently to the right people [13:01] Please stop asking me - I don't know [13:01] Talk to them [13:04] cjwatson: I do apologise, I do get frustrated at times. May I repeat that you are "one of the good guys" for trying to keep a PPC release going. I do not say 'thank-you' often enough. You really are a star. [13:05] * smartboyhw nods in agreement:P [13:06] I'm not fishing for compliments or anything - it's just that the best way I can help is to encourage you to talk to the people who actually have useful knowledge [13:29] * ogra_ shudders seeing Laney approved bug 999771 [13:29] Launchpad bug 999771 in myunity "myunity depends upon DISTRIB_RELEASE being the second entry in /etc/lsb-release" [Undecided,Won't fix] https://launchpad.net/bugs/999771 [13:30] k [13:31] they should have used lsb_release -r [13:33] that would require a runtime dependency on lsb-release [13:33] indeed [13:33] sure [13:33] the fix in there is miles better than it was [13:33] Hmm, this tickles a memory somewhere [13:33] cjwatson: your name is indeed invoked in the bug :-) [13:33] (which is in minimal, so shouldn't matter too much), but running the command is usually slower though [13:33] I have a distinct feeling I remember a bug related to assuming /etc/lsb-release was shell [13:33] but its a tool to manage unity ... which surely pulls in some python already [13:34] Laney: an older memory :) [13:34] heh [13:34] so adding lsb-release as a dep shouldnt add much [13:34] chromium used it for a while (don't remember if it still does or not) [13:34] ogra_: the problem is lsb_release is slow [13:34] oh, come on ... [13:35] I'm going to have to grep my upload mailboxes :-/ [13:35] skaet, er release meeting today? [13:35] its a one time check in a gui tool [13:35] it's hardly a terrible fix [13:35] people coming out of the woodwork immediately after the upload rather than the weeks when the patches were available ... [13:35] ogra_: it should really be generated at build time IMHO [13:35] Laney: the one worry I have is that my memory is that this may be crashy on some flavours [13:35] micahg, ++ [13:35] I'm trying to find the history to see if it's this I'm thinking of or something else [13:37] Laney, use /etc/os-release ... the format is defined [13:37] doko, but only available in quantal [13:37] bug 214861 [13:37] Launchpad bug 214861 in localechooser "expects to be able to source /etc/lsb-release" [High,Fix released] https://launchpad.net/bugs/214861 [13:37] Laney: ^- [13:38] well, I'll see to backport this then to precise [13:38] aha [13:38] Laney: localechooser has some battle-tested shell code for this [13:38] which matches the python implementation afaik [13:38] perhaps you want to inform marga [13:38] yeah [13:42] Laney: Done. Sorry for being late, but associative memory over four years takes a while to respond sometimes === mmrazik is now known as mmrazik|otp [13:45] cjwatson: Ta. It's an interesting data structure that has such a fast membership operation, but much slower lookup performance [13:47] Laney: That's a hash :-) [13:48] In the crypto sense - you can check whether you have the ciphertext, but getting back from that to the plaintext is hard ... [13:52] Also here the membership test is probablistic, and the hashes get harder to crack over time :P === mmrazik|otp is now known as mmrazik [14:16] smartboyhw - yes there is a release meeting today [14:16] skaet, thanks [14:23] skaet, for a gcc-4.7 update, which should go to -updates ... can I upload to -proposed? or just prepare and build in the ubuntu-toolchain-r ppa? [14:24] If you upload to -proposed at the moment, there's a decent chance somebody running on autopilot will copy it to release [14:24] doko, please do it in the ppa, [14:24] ok [14:35] not that I tend to be particularly active at release meetings, but advance notice: I almost certainly can't make it === henrix_ is now known as henrix === henrix is now known as henrix_ === henrix_ is now known as henrix [16:24] hmm.... do we want to reject the nvidia-graphics-drivers-tegra3 in unapproved queue, until the source version in the new queue is processed? [16:25] skaet, ? [16:25] one is tegra, the other is tegra3 [16:25] tegra3 is completely new [16:25] -tegra is just a package update for the tegra2 drivers [16:25] ogra_ Thanks! ok, missed that "3", and thought somethin weird was going on since the versions looked the same. [16:26] yeah, i was pondering to name them -cardhu and -ventana (teh work names for the tegras) ... but then tegra2 would have had so much extra paperwork (new source etc) [16:27] ogra_ what's the bug associated the tegra3 ones? would like to read the backstory. [16:27] i wanted to save us from that ... though i agree the naming isnt great :) [16:27] skaet, identical code, same bug [16:27] i would have filesd a tegra3 task, but thats only possible once a source package is in the archive [16:27] *filed [16:28] fair enough. Thanks for the background [16:28] skaet, the libas have now a SONAME field (never had that before) but that doesnt have the correct contant [16:28] sigh, my typing degrades every day [16:29] * skaet just sees that a flood of langpacks has hit the unapproved queue.... :P [16:29] skaet, if you run ldconfig on them, the broken info lands in ld.so.cache [16:30] if an app looks for libEGL.so.1 ld only knows about libEGL.so [16:30] so the app cant run [16:33] Laney, would you mind taking a look at the libunity that seems to be in the unapproved queue? [16:36] * skaet takes her turn letting through some rebuilds [16:37] micahg: sorry to pester you, we FFed bug 1060211 if you want to have a look, depending on what happens with that I'll resubmit the merge for checkbox 0.14.8 [16:37] Launchpad bug 1060211 in checkbox "[FFe] graphics_driver script does not report proprietary driver version" [Low,Fix committed] https://launchpad.net/bugs/1060211 [16:38] thanks ! [16:41] infinity, cjwatson, i have updated linux-signed to add the postinst/postrm and linux-image binary dependancies === tyhicks` is now known as tyhicks [16:49] roadmr: IANA release team member [16:49] * micahg can sponsor once approved [16:50] micahg: oh ok! thanks anyway! [17:13] * skaet starts wading through RIddell's langpack changes... [17:14] * iulian is reviewing the other ones. [17:15] Well, not all of them. :) [17:15] hi. can i get an approval on a cloud-init upload ? [17:15] Upload it first then we'll review it [17:15] https://launchpad.net/ubuntu/quantal/+source/cloud-init/0.7.0-0ubuntu2 [17:15] Or is it that one in the queue? [17:15] should be in queue [17:16] yes. [17:17] smoser: accepted [17:17] cjwatson, can you take the linux signed one too? [17:18] Yep, looking [17:18] ta [17:18] hmm... is queuebot acting up again? [17:18] * skaet accepted a couple and not seeing them. [17:19] Ugh. [17:19] Which? [17:19] ScottK: There seems to be an explosion of KDE-related things that want to come back to main. [17:20] infinity: Ugh, what. language packs maybe? [17:20] No ... [17:20] langpacks in main are part of it [17:20] Well, maybe [17:20] What the heck is the root cause of all that [17:20] according to http://people.canonical.com/~ubuntu-archive/component-mismatches.svg :) [17:20] langpacks and kde4libs->kate. [17:21] they were labeled universe [17:21] This is the tool that does the labelling [17:21] So, the langpack bit is simple to fix. Let's go see what changed to make the other bit happen. [17:22] ok, will leave them for infinity to sort. [17:22] thank you. [17:22] Hm, yes, language-pack-kde-zh-* might be the cause of the lot [17:22] ubuntu.quantal/usb-live: * /^language-pack-[^-]+-zh-han/ [17:22] That plus (presumably) a new dependency? [17:23] You'd think... [17:23] * skaet shakes her head at the kate package name, and see the potential for confusion. [17:24] Yeah, that would account for it [17:24] Fix that seed and I think everything else should follow [17:24] ok [17:24] Yeah, I'm not seeing the kde4libs->kate thing. [17:25] The fancy svg might be lying. [17:25] The rest is all the effect of Extra-Includes, I believe [17:25] Pull in enough stuff and the auto-"include -dbg" stuff kicks in and drags in half the world [17:25] Also, stuff. [17:25] Have you already mangled the seed, or shall I? [17:26] No, go ahead. I'm too woozy for regexps. [17:26] I've so far failed to wake up this morning. [17:26] I'm out of bed only to prove I'm not dead. ;) [17:26] But, let's regex away. [17:29] * infinity wonders why that regex is there at all... [17:29] Probably made sense once. [17:32] I suspect that replacing the zh-han regex with /^language-pack-gnome-zh-han/ will fix it all up nicely. [17:33] * infinity will do a quick before-and-after germinate for both Ubuntu and Kubuntu and check. [17:33] Agreed. [17:35] gilir: Have you uploaded pcmanfm as well? I can only see libfm in the queue. [17:36] gilir: Nevermind, saw it. [17:47] could somebody have a look at approving my update-manager uploads to p and o proposed? [17:50] bdmurray: Sure, I'll trade you those for my eglibc upload to precise. [17:51] bdmurray: (Which is a combination of the 10.1 that was previously accepted and then superseded by the security update, the 10.2 security update, and then two small patches from the recent quantal) [17:51] the latest upload for aptdaemon ftbfs because of failing tests, i tried building the latest built version and it now ftbfs as well [17:52] anyone have suggestions for someone that might be around that has messed with aptdaemon in the past? [17:52] infinity: the changelog entry for update-manager is longer than the change - I'm not sure this a good deal [17:52] or... if we can turn off those tests until mvo can look at it on monday, so we get some better testing of webapps over the weekend? [17:53] the tests fail for the current published version of aptdaemon anyway, so that isn't a regression [17:53] but i would really like to be able to get more testing for webapps [17:54] bdmurray: It's probably a bum rap for you, but someone needs to accept that eglibc, and I'm pretty sure it's not allowed to be me (even if I've verified a few times that the diff is sane). :P [17:54] skaet, ^^ [17:56] kenvandine: I'll have a look either tonight or tomorrow if nobody else does [17:56] Please don't disable tests [17:56] ok [17:56] i didn't want to... just couldn't find anyone to look at it that knew their way around [17:57] cjwatson, thanks! [17:57] the more testing we can get for webapps, the better :) [17:57] bdmurray: Uhm, your precise-proposed update imported quantal sources. [17:58] bdmurray: I'm thinking that was unintentional, given the changelog. [18:02] infinity: yes, I'm not sure how that happened [18:02] bdmurray: oneiric looks good, though. === yofel_ is now known as yofel [18:05] bdmurray: Given the tininess of the diff, I'd probably not mess with pre-upload magic at all, and just apply it directly to the source package, but whatever workflow helps you sleep better... [18:09] It looks like something in utils/demotions.py - I'll try and sort it out [18:13] thanks kenvandine, cjwatson [18:27] cjwatson: ^^ new shim with changed path for second stage, as requested [18:53] infinity: ^ [18:54] self-accepting shim (time-sensitive, can't break anything yet because we're still putting it in place) [18:55] shimmy it in! [18:57] Daviey, :-D [19:04] slangasek, well, I'd trust your review over mine on the subject, at any rate. :P === henrix is now known as henrix_ [19:17] infinity, bdmurray: does eglibc still need looking at? [19:17] slangasek: Looks like bdmurray got to it for me. [19:17] slangasek: You're free. :) [19:17] ah ok [19:17] (Free to keep hating secure boot...) [19:17] sorry, was a bit tied up this morning :P [19:22] * skaet --> dr. appt. back on later. [19:28] Daviey: mm, why does http://people.canonical.com/~ubuntu-archive/component-mismatches.txt show maas having a dependency on a package not in main? [19:28] (ipmitool) [19:32] slangasek: because that is the intention of the report, it shows packages that depend or recommend on universe packages.. And candidates for demotion.. but i know you know that? [19:33] Daviey: I'm trying to figure out why we're two weeks before release and there's a package in main with a dependency on a package that's never been in main, and I find no MIR for it [19:33] slangasek: https://bugs.launchpad.net/ubuntu/+source/ipmitool/+bug/1040682 [19:33] Launchpad bug 1040682 in ipmitool "[MIR] ipmitool" [High,Invalid] [19:34] ah, I didn't check 'invalid' [19:34] slangasek: it's being replaced with freeipmi on next upload, covered by MIR 1052056 [19:34] bug 1052056 [19:34] Launchpad bug 1052056 in freeipmi "[FFe] [MIR] freeipmi" [Undecided,In progress] https://launchpad.net/bugs/1052056 [19:34] ok [19:35] slangasek: The debdiff for jdstrand's requirements is here, http://paste.ubuntu.com/1262079/ pending one more addition.. which is in progress [19:35] (this was discussed in the release meeting, just a few hours ago) [19:35] alright [21:04] No more KDE stuff on http://people.canonical.com/~ubuntu-archive/testing/quantal_outdate_all.txt [21:04] Riddell: I think the copying misfire is all cleaned up now. [21:07] oh great, many many thanks [21:26] I already reviewed the minitube diff when granting its FFe, so accepted. [21:58]