[02:17] === Top 10 Time Out Counts by Page ID === [02:17] Hard / Soft Page ID [02:17] 296 / 6927 Archive:+index [02:17] 83 / 377 BugTask:+index [02:17] 43 / 169 ProjectGroupSet:CollectionResource:#project_groups [02:17] 22 / 261 Distribution:+bugs [02:17] 12 / 29 Archive:+copy-packages [02:17] 10 / 344 POFile:+translate [02:17] 10 / 27 MailingListApplication:MailingListAPIView [02:17] 9 / 34 DistroSeries:+queue [02:17] 8 / 29 Milestone:+index [02:17] 8 / 11 DistroSeriesLanguage:+index [02:40] lifeless: Do you have a +copy-packages OOPS? Is it repeated DistroArchSeries queries again? [02:40] Repeated DistroArchSeries and Archive queries, inf act. [02:41] (wow, that is a lot of Archive:+index soft timeouts. I wouldn't have guessed that it had that many hits) [02:54] wgrant: this is why I worry :) [02:57] lifeless: If you'd let PQM be taken out of RC earlier, it would be fixed by now :P [03:02] lifeless: Could you check a +copy-packages OOPS? I think it's the same issue as +queue -- SPR.getBuildByArch being awful. [03:05] wgrant: I'm on leave, nutting to do with me ;) [03:06] Pfft. [03:06] Archive:+index 20753 [03:06] 99% under 15.84 [03:07] Ow. [03:09] wgrant: I do [03:14] wgrant: https://bugs.launchpad.net/soyuz/+bug/575450 [03:14] <_mup_> Bug #575450: Archive:+copy-packages nearly unusable due to timeouts [03:15] lifeless: Wow, those are really awful queries. [03:15] tada [03:15] Not what I thought it would be. [03:15] Thanks. [03:15] and 150 noddy repeats [03:16] Those are hopefully fixed by my Archive:+index branch. [03:16] But they will probably reveal more. [03:16] sure [03:16] a query scaling test for copy-packages would be nice [03:17] But by that point I probably won't have to pester you. [03:17] Yeah. [03:17] But it's so awful at the moment that it's pointless to test. [03:17] https://launchpad.net/ubuntu/+archive/primary/+copy-packages [03:17] looks similar to me [03:17] wgrant: its never pointless to stop the erosion [03:18] lifeless: Pointless? No. Depressing and embarrassing? Definitely. [04:17] lifeless: I think we need to segregate OOPSes by HTTP method. [04:18] Looking at that +copy-packages OOPS again, it's a GET, not a POST. [04:18] So it's just batchnavigator's COUNTing stupidity. [04:42] wgrant: file a bug on oops-tools, I think that that is a good, valid, heuristic. [04:43] lifeless: k, thanks. [04:56] lifeless: How are we going to fix batchnavigator? Can we get postgres to give us an estimate? [04:57] broadly [04:58] a) there is an estimator in the code base already [04:58] b) we don't want to pass storm result sets outside the persistence layer anyway [04:58] c) while counting can be slow, we should be able to do better than 3 seconds [07:21] \o/ parallel testing for testr [07:22] about 0.3 seconds (25%) off of the time to test testtools. [07:38] I love well-designed tests. [07:50] wgrant: did you file that bug about presentation of the 'Ubuntu also tracks bugs for packages derived from this project: bzr in ubuntu.' links ? [07:50] lifeless: I didn't. [07:50] I feel like I should talk to someone first. [07:50] thats a mispattern [07:51] I'm sure you can point out that the current approach doesn't scale to even just the distros hosted in LP> [07:52] the mispattern is needing discussion *before* creating a place to talk about the issues [07:52] Well, It is tempting to at least raise it with Curtis first. [07:53] its been 1? 2? weeks. [07:53] I call timeout [07:53] (the timeout should be ~ 5 minutes) [07:53] Wellll, I forgot. [07:53] wgrant: exactly [07:53] You are on leave; you cannot call timeout :P [07:53] can too; nyarh nyarh nyarh [07:53] mørning lifeless, wgrant [07:54] ø? [07:54] Evening jelmer. [07:54] I'm feeling creative this morning. [07:54] My compose key is sadly broken :( [07:54] ö [07:54] Thére wë go. [07:54] wgrant: do you need one for Strine? [07:55] jelmer: Apparently. === almaisan-away is now known as al-maisan [08:26] ood morning [08:27] moin adeuring :) [08:28] hey al-maisan! [08:28] wgrant: btw, how many cpus do you have? [08:29] lifeless: 6 cores. [08:29] Morning adeuring, al-maisan. [08:29] wgrant: you might want to try glueing latest testr to running lp tests in vm's. [08:29] (one vm per test command invocation) [08:29] hello wgrant, how are things? [08:30] wgrant: (if you want 6 way concurrency in an lp test run) [08:30] al-maisan: Pretty good. [08:30] Enjoying my final week of freedom. [08:30] :) [08:30] there are some pretty interesting discussions going on re soyuz :) [08:31] You could say that. [08:32] wgrant: Yeah, right. You're spending it working on Launchpad [08:32] StevenK: Says he who is on leave but present... [08:32] StevenK: if you love your job, you never need to work :) [08:32] I'm too attached to IRC to /quit [08:32] true .. but also slightly dangerous ;) [08:33] * StevenK is going to spend some time this work working on Hudson [08:34] * jelmer waves to StevenK, al-maisan, adeuring [08:34] jelmer: O hai! [08:34] * al-maisan waves back :) [08:35] lifeless: Is there any documentation on the testr parallelisation functionality? [08:35] Test runs in half an hour would be pretty cool. [08:35] wgrant: MANUAL.txt [08:35] wgrant: testr run --help [08:35] wgrant: NEWS [08:36] lifeless: I suppose I'll need a very recent (!)release? [08:36] tip [08:36] k [08:36] its not finalised [08:36] morning jelmer [08:36] I may tweak the config if it doesn't fit well with our needs here [08:36] hey Michael [08:37] mwhudson_: Thanks for landing that C introspection branch :-) [08:38] Bah, fixtures isn't packaged :( [08:38] wgrant: it is in the testing-cabal PPA [08:38] jelmer: Perfect, thanks. [08:38] jelmer: thanks for the prods [08:38] wgrant: ppa:testing-cabal/archive [08:42] tip testr is in that ppa too [08:42] wgrant: its also in Debian. [08:44] Maybe I should go back to unstable for a while. [08:44] or natty [08:44] I trust unstable more. [08:44] unstable is ~frozen [08:45] But it doesn't have Unity rewrite crack :) [08:45] Anyway. [08:45] * wgrant investigates testr --parallel [08:45] wgrant: you can use natty with the normal gnome desktop as well [08:46] But NM doesn't seem to really work :/ [08:51] lifeless: Off the top of your head, will the Hudson EC2 plugin just deal with and mount an EBS volume, or does that require changes? I can't find much TFM to R [08:51] should just work [08:52] ^-WAG [08:54] morning [08:55] Morning bigjools. [08:56] inbox most definitely not zero today [08:57] I should clean up mine this week. [08:58] Because I guess I will acquire a new problematic one soon. [08:58] :( [08:58] i had a soul-crushing amount of email this morning [08:59] wgrant: you already subscribe to bugmail, that forms 80% of mine [08:59] then the oops reports [08:59] then warthogs on a bad day :) [08:59] bigjools: There's a lot of bugmail, sure, but it's nice and quick to get through. [09:00] hahaha [09:13] Hello [09:22] g'day mrevell [09:25] wgrant: just one week to go :) [09:25] mwhudson_: yeah, saw your tweet [09:25] * thumper goes to make a cuppa tea [09:25] hi mrevell [09:25] * thumper waves at StevenK [09:25] * thumper thinks that is everyone now [09:25] haha [09:25] Good work thumper [09:27] thumper: Indeed! [09:43] * bigjools pouts [09:44] Uhoh. [09:44] wgrant: https://bugs.launchpad.net/soyuz/+bug/685076 [09:44] <_mup_> Bug #685076: PPA deletion leaves unremoved publications [09:44] ARGH. [09:45] bigjools: How is that ARGH-worthy? [09:45] because I overlooked it [09:45] Heh. [09:46] there's a pheasant outside my window. Pie anyone? [09:46] mmm [09:46] PIE [09:46] :D [09:48] wgrant: so all these bugs you're filing! [09:48] shall I just assign you to them now? :) [09:49] Maybe. [09:50] wgrant: I am not clearly following the timeline you wrote in bug 682692. Could be my lack of caffeine though. [09:50] <_mup_> Bug #682692: Some PPAs have duplicated builds

[09:52] bigjools: What's ununderstandable? [09:53] I am having trouble understanding where the problem is in that example timeline [09:54] bigjools: The first copy was deleted 18 seconds before the second copy was performed. [09:54] So the status summary returned FULLYBUILT instead of FULLYBUILT_PENDING, so the copy was permitted with unpublished builds. [09:55] wgrant: can you condense that comment into a simple instruction to re-create the bug? [09:55] it will double as a QA test when we fix it [09:55] congrats on figuring it out [09:58] bigjools: Done. [09:59] wgrant: rock! thanks [09:59] Hmm. Should I expect an acknowledgement when I reply to an rt.admin.canonical.com ticket? [10:06] wgrant: https://answers.launchpad.net/soyuz/+question/136685 [10:06] wgrant: RT should reply but since it doesn't know you I expect it won't [10:07] bigjools: Have you looked at the end of that question? [10:07] the massive list of files you mean? :) [10:07] I was thinking more about my response and reviewed branch. [10:08] oh didn't get that far [10:08] carry on [11:52] wgrant: any further comments re my bug comment: https://bugs.launchpad.net/soyuz/+bug/684180/comments/3 ? [11:52] <_mup_> Bug #684180: Deleted sources can leave binaries hanging around forever

[11:53] bigjools: "Argh" just about covers it. [11:53] that's my Word of the Day [11:53] Deletion won't cover everything. [11:53] What if the source is superseded instead? [11:53] We can't block that. [11:53] We can, instead, cry. [11:54] it won't but it covers this case [11:54] we can block superseding surely? [11:54] it'll get caught later [11:54] Pllllllease don't. [11:54] That violates the very little layering we have :( [11:55] the layering sucks [11:55] Why? [11:55] we don't have layers, we have something organised into modules [11:55] Making the publisher depend on build statuses is unprecedented. [11:55] And slow. [11:56] in that case we need to make domination do more work [11:56] which is equally as unpaletable [11:56] We need to think about how binaries and sources interact. [11:56] For copies, for deletions, for dominations. [11:56] "badly" :) [11:56] It is all tied together. [11:56] And it is only consistent in one respect: it is fucked. === Ursinha-afk is now known as Ursinha [11:57] * bigjools loses mouthful of coffee [12:00] wgrant: we can't auto-supersede binaries if the source is superseded [12:00] they might be a dependent [12:00] I know [12:00] Except that's not the reason. [12:00] my main issue is preventing the manual deletion that people do in PPAs [12:00] what reason? [12:01] We don't seem to care about breaking dependencies. [12:01] Morning, all. [12:01] howdy deryck [12:02] wgrant: why do we have this then? http://people.canonical.com/~ubuntu-archive/NBS/ [12:02] I guess it is sort of dependency-related. [12:02] But not entirely. [12:02] Right. [12:02] NBS. [12:02] I hate NBS. [12:02] that's why we can't auto-supersede the binaries [12:03] I don't like introducing a hack to partially fix a problem without at least thinking about how to fix the whole thing. [12:04] I contest your definition of a hack [12:04] Blocking deletion because builds are in the wild is a hack. [12:04] I disagree [12:04] We should just make them be created deleted. Or something like that. [12:05] that's a hack too then ;) [12:05] It's a less obtrusive one. [12:05] GRRR what has a maverick update done to my fonts [12:07] So, we can't really reject the binaries if the source is deleted. Blocking deletion is undesirable. This leaves us with accepting binaries for a deleted source. [12:07] we can just throw them away and mark the build superseded [12:07] if the build is not active then we mark it superseded immediately [12:08] We could. But that seems like a waste. [12:08] someone wants the package deleted - we're just doing what they want. [12:11] I think most of my problems with this area stem from the way we fail to treat sources and their binaries as a single unit. [12:11] And the way this interacts with copies. [12:13] how would you treat them as a single unit? [12:14] We already do. For copies. And in the UI. Everywhere except most of the code. [12:14] how would you do that in the code? [12:18] I don't know exactly. But it's terribly confusing the way it is now: the same source can have different builds in different series and different archives. Copy from Hardy to Lucid, and you can no longer copy from Lucid to anywhere else. Copy one of those to another archive, and it will have all the same archs, but exactly one of them is actually a different build. Copy to a non-virt archive, it now contains another superset of the builds ... [12:18] ... of the original archive. [12:18] Want to do a security update? hppa is being slow. Let's copy without it. [12:18] Oh look, can't copy it any more. [12:20] you conveniently forgot about copy with binaries [12:20] or mixed examples with it set/not set [12:20] All those cases are copying with binaries. [12:20] Without binaries it's boring. [12:21] " one of them is actually a different build" - how? [12:22] bigjools: Because I copied from Hardy in one PPA to Lucid in another. Lucid has armel, Hardy does not. Lucid gets a new armel build, different from the one in the origin archive. [12:23] why are we creating new builds for binary copies? [12:23] Because the target series or archive can have more architectures. [12:23] that's crack [12:23] I think it probably is. [12:23] it's a binary copy, I don't expect more builds [12:23] It's also really, really slow. [12:24] But inter-series it becomes awkward. [12:25] My intuition says that builds should live in a set. And only sets should be copiable. Atomically. Inter-archive that's fine, since if you want more archs you can just rebuild it all. [12:26] But inter-series it doesn't work. [12:26] yup [12:27] So perhaps there should be an exception, where a set can be extended within an archive by copying to a new series. [12:27] But then when somebody copies someone else's set to another archive, they are screwed. Because they can't append to it, and they can no longer rebuild it. [12:28] "Argh" [12:29] wgrant: but soyuz isn't that complicated, don't worry. [12:30] we'll just throw more people at it [12:31] :) [12:31] Yes, the model is somewhat overcomplicated... but it can't be simplified away. [12:32] it's the nature of the beast === mrevell is now known as mrevell-lunch [13:04] wgrant: so I think I'll amend my suggestion on that bug to just throw away the builds that are in progress and mark the build record as superseded. [13:04] bigjools: When they try to finish? [13:04] I just need to decide whether to do it in p-a or the b-m [13:04] yes [13:05] if they are not dispatched yet then we can supersede immediately [13:05] They'll supersede automatically when they try to start. [13:05] good point, well made [13:05] I was thinking only of deletions [13:06] what do you think of the cleanup SQL I propose to do? [13:08] As long as there are no Published sourcepubs remaining, sure. [13:08] yeah, it's just superseding binaries where the source is already superseded without being published at all [13:08] should be safe [13:09] It's possible that it was revived later. But I guess we could ignore that. [13:09] some of the sources date back to 2009 [13:09] Only? [13:09] 2009-10-06 is the earliest [13:10] Hmmmm. [13:10] That's pretty strange. [13:10] 245 SPPHes [13:21] * bigjools -> fud === mrevell-lunch is now known as mrevell === henninge_ is now known as henninge === Ursinha is now known as Ursinha-lunch [14:26] I have a new frozenset subclass. When it gets wrapped in a Zope security proxy nothing is available, not even the usual frozenset methods. Does anyone know how to configure this in ZCML (or otherwise) without repeating the existing configuration. Right now I think I'm going to modify BasicTypes directly. [14:34] allenap: that's weird because frozenset is already part of _default_checker in zope.security.checker [14:34] flacoste: Yeah :-/ [14:35] allenap: have you try the security debugger on it? === matsubara is now known as matsubara-lunch [14:35] flacoste: Is that ZOPE_WATCH_CHECKERS? Not yet. [14:35] allenap: no, it's something else [14:35] hang on [14:35] looking for it [14:36] something i write a long time ago [14:36] it's in lazr.restful.debug [14:36] from lazr.restful.debug import debug_proxy [14:36] print debug_proxy(obj) [14:37] allenap: it will show all layers of wrapping, along the checkers registerd for security proxy [14:37] flacoste: Cool, that sounds useful. [14:39] flacoste: It gets: zope.security._proxy._Proxy (using zope.security.checker.Checker) [14:41] hmm [14:42] allenap: is that all? [14:42] flacoste: Yes! That's it :) [14:42] allenap: it's weird, because it should be showing the permission declared on it [14:42] so it's like if the read_permission and write_persmission were unset [14:42] but the default _setChecker [14:42] is a NamesCheker that grant access to all the set procotol [14:43] i suspect that something is chaning the default one [14:43] hand on, i'll try something [14:43] flacoste: Yeah, that's what's stumping me. [14:44] shit, my tree is out of date [14:44] allenap: try printing the checker in make harness on devel [14:44] see if it is the same thing [14:44] flacoste: That's where I did it. [14:46] allenap: ok, let me compare notes (after my standup) [14:47] flacoste: Okay, thanks. [14:51] mrevell, jml: http://leankitblog.com/2010/12/10-kanban-boards-leankit-kanban-style/ === salgado is now known as salgado-lunch === matsubara-lunch is now known as matsubara === Ursinha-lunch is now known as Ursinha === deryck is now known as deryck[lunch] [16:04] We're granting people/ teams upload rights to ppas via newComponentUploader() in launchpadlib. Our problem is that, when we do this, the PPA does not show up in +archivesubscriptions -- seems to me this should be happening? Am I off my rocker? [16:06] timrc: sounds wrong. Can you file a bug with the details to re-create that please. [16:06] bigjools: sure, np [16:06] timrc: presumably it's a private PPA? [16:06] bigjools: yep [16:07] bigjools: I'll be sure to note that detail in the bug report [16:07] well you can't have subscriptions on them otherwise :) [16:07] bigjools: the only way I know of to expose the subscription is to use Manage access via LP [16:07] thought I'd check the blindingly obvious first [16:07] you can use the API as well [16:08] bigjools: but maybe +archivesubscriptions only lists archives that you can install from and not ones you can upload too? I dunno, I'm a newbie :) === salgado-lunch is now known as salgado [16:08] and not ones you can _only_ upload too? [16:09] timrc: it's possible that's happened, yes, and it would be a bug if that's the case. === beuno is now known as beuno-lunch [16:25] sinzui: might you know anything about https://bugs.launchpad.net/launchpad-foundations/+bug/683945 ? I don't have anyone ATM who does. [16:25] <_mup_> Bug #683945: disabled lists are never completing disabling [16:32] abentley: how's the release is going? [16:32] flacoste: It's going fine. We've nearly got QA complete. [16:33] abentley: did we sort out the DKIM QA? [16:33] flacoste: poolie was supposed to do it on (his) saturday, but he hasn't updated the tags. [16:34] abentley: should we consider reverting it? [16:34] abentley: and should we do a no-downtime today with bzr 2.2.2? [16:34] flacoste: I am hoping that he's done it and just forgotten to update the tags. [16:35] flacoste: I was going to chase it down today. [16:35] abentley: ok, let's see what he says when he comes online later today [16:35] abentley: what about bzr 2.2.2? [16:36] flacoste: I don't feel strongly either way. [16:37] hmm, ok === deryck[lunch] is now known as deryck [16:38] flacoste: If we do, we might as well do 1206 as well, so we can nix both cowboys. [16:40] abentley: the cow-boys are not part of the nodowntime set [16:40] so it's probably not that useful [16:41] Hmm, I thought one of them was not part of the nodowntime set because of the cowboys. === mrevell_ is now known as mrevell [17:01] losas, https://bugs.launchpad.net/launchpad-foundations/+bug/684672 is dealt with, right? The bug report doesn't give a status update [17:01] <_mup_> Bug #684672: staging update broken on revno 10029 [17:02] eh, sorry, going to ops === beuno-lunch is now known as beuno === benji is now known as benji-lunch [17:40] bigjools: So, I found a minute to play around. You have to call newSubscription() to have the PPA appear in +archivesubscriptions .. which is fine as being 'subscribed' to the archive simply means you can install from it. I suppose there is a use case where you'd like to make the archive 'write-only' in that a person / team can upload to the PPA, but not install from it (e.g. the PPA is upstream to another archive that is inst [17:40] allable) [17:41] timrc: actually I think we have a bug somewhere about having implicit subscriptions for PPA uploaders. [17:41] bigjools: so I think the takeaway here is that it'd be nice to see the access rights you have on a private PPA, regardless of subscription.. is there a way to do this from the UI? [17:41] you can query what rights someone has via the API [17:41] bigjools: I was hoping there'd already be something out there to support our users :) but I'll put this on my list of TODOs [17:42] yeah some of this is a little clunky still [17:44] bigjools: well I appreciate your time, thanks [17:44] timrc: no problem, let me know if you have more questions [18:24] gary_poster, sorry I was OTP. I marked the bug as fix released. Chex and I resolved the stuck Mm + XMLRPC combo === benji-lunch is now known as benji [18:41] Hey hey. Any hope of getting my loggerhead update merged and staged? [18:43] This is the MP: https://code.launchpad.net/~mkanat/loggerhead/launchpad/+merge/42338 [18:43] that won't get it deployed [18:43] you need to propose a source dep change to launchpad itself [18:44] lifeless: Right, but first I have to merge to this branch, which I don't control. [18:44] mmm, well both things I need [18:44] anyhow, right now - we're frozen. [18:44] lifeless: Okay. How long does that last? [18:44] I'm not sure, i'm on leave - check the -dev list archive, dates should have been announced there [18:45] lifeless: Okay, thanks. === al-maisan is now known as almaisan-away [18:59] ack, thanks sinzui === Ursinha is now known as Ursinha-brb [19:21] sigh, the python3 shenanigans are just plain tiring [19:23] lifeless: which shenanigans in particular are getting you down? [19:23] benji: most currently the transform stuff [19:24] benji: but more generally the way its just so painful to do widespread compatibility with [19:24] * lifeless things py3k was a mistake [19:26] unfortunately I have to agree; too much incompatability for such small gains [19:26] I still think someone who wanted to be BDFL 2.0 could take up Python 2 and run with it. [19:36] benji: What I hear is that 2.7 is the last 2.x release ever. [19:37] mkanat: right, the last official one; the python-dev folks won't be working on any more releases, but someone else could take it up -- they'd have to use a name other than "Python" though [19:37] benji: Ah, yeah. [19:40] benji: they could use Compatython [19:40]