[00:00] sure, call me? [00:00] are you on skype? [00:00] i can be [00:02] please [00:02] mm it's trying to connect [00:02] ok, I'll ring ze landline [00:32] rockstar: just to confirm, the email I CC'd you on failed with Submit Request Failure as I expected it would [00:50] jam, hm. [00:53] rockstar: would forwarding the failure help you? [00:54] jam, no, I see that it's valid. [00:54] sure, I didn't know if the failure included any info you could use [00:57] jam, does the same thing happen on bugs as well? [00:57] same thing [00:58] jam, hm. I think the bug probably goes with foundations. I wonder if something has changed with python gpg bindings. [01:02] lifeless: meeting ping [01:04] hish [01:14] jam by 'avatar' do you mean 'current user'? [01:14] is that the actual name for it in that code? [01:14] * poolie is not pedantic, just curious [01:14] right [01:14] at least in this context [01:14] avatar.user_id is the database identifier used for the branch vfs [01:17] ok [01:18] jam, robert recently landed (or at least proposed) some new scopes, which may give you a template [01:20] lifeless: where did they go? they don't seem to be in devel yet [01:21] oh, it is landed, i just expected it would be in scopes.py [01:23] rockstar: want to talk? [01:23] i'll reply by mail [01:32] poolie: feel free to refactor; I was following what I saw (right or wrong) [01:33] thumper, 5 minutes. [01:33] rockstar: ok, I'll go make coffee [01:34] thumper: white with 2 sugars please [01:34] wallyworld_: pass me your cup [01:34] thumper: i would if i knew how to get the cup icon to display in irc :-) [01:36] ☕☕ [01:36] "find" in character map :) [01:36] poolie: show off! [01:43] * thumper waits for rockstar [01:44] thumper, wait no more! [02:06] Can we get ~ubuntu-bugs removed from ~launchpad-beta-testers? It was added overnight to allow the ubuntu-bugs ML to receive comments from remote bug trackers, but has the side effect of redirecting lots of people to edge. [02:07] Where "lots" is around 400. [02:08] that seems like a bad idea [02:08] file a bug, malone, critical sev [02:09] Why does it need a bug? [02:09] well, won't the comments not go to ubuntu-bugs if we remove it ? [02:09] There's already a bug for sending the remote comments to everybody. [02:09] ok. [02:09] And they've only been going there since last night. [02:09] So it's not a significant loss. [02:09] make sense to me [02:09] bugsquad can do it [02:10] Bug 639736 [02:10] lifeless: How? [02:10] exit the team? [02:10] Bug Control is a member, but bdmurray is the only admin. [02:10] oh [02:10] bdmurray: yo! [02:10] Otherwise an ~l-b-t admin can do it. [02:10] bdmurray: a) you may want to have someother admins [02:11] bdmurray: and b) ^ the discussion aobove [02:14] wgrant: sure I'll do it now [02:14] bdmurray: Thanks. [02:14] I was trying to work around a Launchpad bug [02:14] is there a reason for bugcontrol to be a member these days? [02:15] Yeah, I saw the mail go past overnight :) [02:15] ~ubuntu-bugcontrol could be the bug supervisor, and ~ubuntu-bugs just be subscribed. [02:18] wgrant: well Launchpad is oops'ing on me now wrt ubuntu-bugs and lp-beta-testers [02:18] bdmurray: What's the traceback? [02:18] wgrant: its a TimeoutError in the sql statement [02:18] Awesome. [02:19] Retry a couple of times, I suppose. [02:19] Maybe it will eventually work. [02:29] thumper: O hai; I seem to recall SQLObjectNotFound coming up in your review of my branch -- did you recommend to just bin it and I missed it? [02:30] StevenK: I think I recommended getting it form lazr.lifecycle [02:30] Ah yes, that sounds right [02:30] thumper: I'm fixing up all of the lint :-) [02:31] thumper: I don't see SQLObjectNotFound in lazr.lifecycle? [02:32] what do you see? [02:32] I just grepped for it, I got no results [02:32] thumper: is there a bug that [02:32] https://code.edge.launchpad.net/~lifeless/launchpad/bugmessage/+merge/35620/reviews/45660/+reassign [02:33] doesn't let you change the review type requested ? [02:33] lifeless: yes [02:33] ok cool. [02:34] StevenK: you are right [02:34] it isn't there [02:34] from lp.app.errors import NotFoundError [02:34] is this a way of teaching your mentee a lesson? :-) [02:34] that'll do a 404 [02:35] mwhudson: heh [02:35] "don't take everything on trust" [02:35] mwhudson: and "everybody lies" [02:35] :) [02:35] Thank you, House [02:36] * StevenK passes thumper a cane, and some Vicodin [02:36] * thumper hobbles off to do some shopping [03:03] man [03:03] 2026 OOPS-1719N1979 BugTask:+index [03:03] still need to get that down [03:05] Ursinha-afk: if you see this https://devpad.canonical.com/~lpqateam/qa_reports/launchpad-stable-deployment.txt - not sure why 'Revision 11522 can not be deployed: not-ok' [03:05] wgrant: so I set the expiration date for the 16th we'll see what that does [03:06] also we probably want to report on more of the non-ok revisions [03:18] lifeless: bug 640125 for logging stuff [04:30] anyone seen this error running bin/test -vvm lp.registry.browser.tests.test_milestone [04:30] Failure in test lp.registry.browser.tests.test_milestone.TestMilestoneMemcache.test_milestone_index_memcache_anonymous [04:30] File "/home/ian/projects/lp-branches/current/lib/lp/registry/browser/tests/test_milestone.py", line 108, in test_milestone_index_memcache_anonymous [04:30] 'anonymous, view/expire_cache_minutes minute', content) [04:30] File "/home/ian/projects/lp-branches/current/lib/lp/testing/memcache.py", line 33, in assertCacheHit [04:30] self.assertTrue(cache_start in before) [04:30] AssertionError [04:32] i was testing a small change which touched test_milestone.py and get the same error even after reverting back to the original version [04:40] wallyworld__: what touched test_milestone? [04:41] Is ec2 broken for anyone else? [04:41] The script, I mean. [04:41] thumper: line 86 change to series = self.factory.makeProductSeries(product=product) -- it was just self.factory.makeSeries(...) [04:41] jtv: I'm just testing, but it is an older one [04:41] wallyworld__: ah. [04:41] I just updated everything, and regret it [04:42] Actually it may just be "ec2 land"—I'm firing off an "ec2 test" that's really firing up an instance afaics [04:42] thumper: i re-ran the tests on a different branch without the changes and it still failed the same way :-( [04:43] wallyworld__: I'll try here [04:43] ok. thanks. i'll have to get out my scuba gear and dive in to take a look [04:45] wallyworld__: it runs here on your tales-linkify-broken-links branch [04:45] wallyworld__: on lucid [04:45] thumper: hmmmm. that's the same branch i tried it on :-( [04:45] wallyworld__: it could be a lucid vs maverick issue [04:45] can we find other volunteers to try? [04:46] ok. I'll make sure all other tests etc run locally and then run it through ec2 test [04:47] wallyworld__: one thing on that branch [04:47] thumper: yeeeees? [04:47] wallyworld__: can I get you to prefix any variable without a proxy with naked_ ? [04:48] so... [04:48] naked_product = removeSecurityProxy(branch.product) [04:48] wallyworld__: as this confused me looking through the tests [04:48] yup. good idea [04:48] wallyworld__: as I expected it to fail not realising that the product didn't have a proxy [04:48] * wallyworld__ nods [04:48] thanks [04:49] maybe one day next year this branch will get landed :-) [04:51] it is ' ' close [04:51] * thumper mimics ' ' this close with fingers slightly apart [04:51] jtv: symptoms? [04:51] still, i'm getting to play with pipes going back and firth between the 2 branches. nice plugin :-) [04:52] s/firth/forth [04:53] lifeless: http://paste.ubuntu.com/494554/ [04:54] "ec2 test" works [04:56] wallyworld__: don't forget to pump :) [04:56] * thumper steps away to cook, back later for more evening calls [04:57] wallyworld__: I'll check back on the tales fix branch before I sit down to eat to see if we can get that into the landing queue [04:57] thumper: i won't forget :-) [04:58] thumper: i'm just about to push the "final" changes. had to answer the door. a box from Think Geek arrived :-) [05:04] lifeless: what's the status of your getLastOops fix? ie when is it safe to try and land a branch again? [05:34] it landed [05:34] so the symptoms are addressed, I'm landing another branch via ec2 land atm, if that works I'll mail the list. if it doesn't I'll mail the list. [05:57] stub: hai [05:57] stub: I has db patch up [05:57] yo [05:57] yup [05:57] I'd like to check its a sane approach with you [06:04] lifeless: That seems fine. I want to run a quick test on staging to see if we should populate it in the DB patch and make it NOT NULL. [06:05] stub: coolio [06:05] stub: I was figuring on a garbo task to populate it [06:06] We could just use the message id instead of the index, but that would break existing links. [06:06] lifeless: I don't see how it is useful if it information is only available sometimes. [06:07] stub: garbo task to populate over a cycle [06:07] ok [06:07] once the row exists land a patch to set it on all new rows [06:07] The table isn't wide - I don't think it will take long to rewrite it but I'll check first. [06:07] then, once the garbo has caught up, we know its all there [06:08] land a patch to use it [06:41] stub: its going to be millions of rows though [06:48] wallyworld___: around? [06:52] wallyworld_: around? [06:52] thumper: like a rissole [06:53] wallyworld_: I've approved the tales branch with an optional but suggested change === almaisan-away is now known as al-maisan [06:53] ok. will check email [06:53] btw, a make clean helped that milestone test to pass [06:55] thumper: i'll make the suggested change and land it once ec2 is back in business. thx [06:55] wallyworld_: ack [06:55] * thumper done until call with mthaddon later [07:02] lifeless: its not too slow to update, but it is too slow to calculate all the indexes [07:03] well... both... [07:03] stub: times? [07:03] longer than I could be arsed waiting ;) === al-maisan is now known as almaisan-away [07:06] stub: so incremental is the way [07:07] stub: how long to add null and index ? [07:07] stub: or should we add null and index after the rollout ? [07:09] The index is added in this rollout, we populate, then we add the not null next rollout. [07:09] kk [07:09] what patch number ? [07:10] stub: how many rows do we need to calculate? [07:16] stub:? [07:17] 3.3 million rows to calculate [07:22] So 42 seconds to calculate on staging with this approach... I'll leave the update running for a bit. [07:22] patch will be 2208-14-0 [07:24] how are you populating ? === almaisan-away is now known as al-maisan [07:31] stub: and can you approve so I cans lands it ? [07:42] lifeless: are your Epic slides on the web? [07:42] yes [07:42] linked from the architectureguide [07:42] tx [07:43] and emails n stuff [07:50] lifeless: http://paste.ubuntu.com/494601/ is the best I can do, but the update is too slow (killed it again) [07:51] lifeless: So I'll approve the patch in the form you have and we will need datamigration and a follow up patch [07:57] thanks [08:44] good moring [08:49] Morning [10:00] lifeless, hi [10:00] lifeless, I saw your getLastOops branch landed. Did it help with your ec2 runs? [10:28] good morning. [10:29] hi jml [10:48] I thought someone had done some work recently on exposing blueprints over the webservice [10:49] There have been a few efforts there. [10:49] ajmitch had one. [10:49] I don't recall who tried it last. [10:49] Everyone seems to give up quickly... [10:51] I think james_w & cjwatson have both tried. [10:51] *sigh* [10:52] Maybe some things just weren't meant to be (I may be thinking of the app itself here, though...) [10:53] jml: ajmitch said he was working on one. [10:53] arg, I should read [10:54] nigelb, it happens :) [10:54] * nigelb is waking up at 3 pm - confusion guaranteed [11:00] yeah, james_w had done a bit more than me & submitted it for review - I think people recoiled in horror from the blueprints internals that got exposed [11:00] heh [11:00] I don't know if anyone else has tried further since then [11:01] Now I know why wgrant always wants that part killed [11:01] I too tried back in the early days. [11:02] But there's a lot of refactoring required. [11:02] Then I decided that attempting to arrange the application's demise was more productive. [11:02] this is why I've not really touched it since [11:03] oh, it is going to be killed? [11:03] if wgrant has his way [11:04] Sadly, others do not seem convinced. [11:08] someone broke the css again? [11:17] ajmitch: yup, looks like it === noodles785 is now known as noodles775 [12:03] Morning, all. [12:03] I'd love to spend a couple of months improving our developer documentation & tools. [12:03] deryck, good morning [12:07] deryck, just quickly, what's the status of https://dev.launchpad.net/LEP/BugzillaComponents ? [12:08] jml, we're in progress on it. bryceh started coding a couple weeks ago. [12:08] deryck, ta. [12:08] jml, I thought you approved this one. Did we leap before we looked? [12:08] deryck, it's approved, but it was in the "Ready to code" section. Just tidying up the LEP page. [12:08] ah, ok. [12:09] the page tells a slightly different story to the Kanban boards, I think :) [12:16] jelmer: well it, itself, got through ec2 [12:18] deryck: for your delectation https://code.edge.launchpad.net/~lifeless/launchpad/bugmessage/+merge/35620 [12:19] jelmer: two branches since have passed ec2, but not got through pqm [12:19] lifeless, nice! [12:28] * thumper halts [12:28] deryck: hopefully [12:29] deryck: we're 3 weeks out from starting the data migration ;) [12:29] heh, well true. But still it's step in the right direction. [12:30] bigjools, hey. I just now noticed you requested a review from me. Sorry. You still need this? [12:31] hey deryck, yeah it would not hurt if you had a look. It's to do with closing private bugs from uploads. [12:31] bigjools, ok, will look now. [12:31] cheers [12:32] deryck: we had the conversation ages ago where we said it would be a good idea to do the closing in a Job, but I've decided on the dirty hack instead :) [12:32] bigjools, right, I recall that now. And you dirty hacker, you. ;) [12:33] deryck: bugtrackerset isn't pagination [12:33] deryck: though it only has 900 rows, so its not really dying for it. [12:35] jml: thanks for landing that fix the other day [12:35] bigjools: your cps are done; can you refreeze the db in prod though? [12:35] lifeless, np [12:36] lifeless: it was first on my list of things to do this morning, and the branch is playing in prod_lp right now [12:36] bigjools: sweet, thanks [12:36] lifeless: although the DAS enablement branch should have gone to appservers as well, BTW [12:36] bigjools: we deployed to all [12:37] bigjools: edge prod backends the works. [12:37] lifeless: your CP request just said "soyuz" ? [12:37] yes, but there were 4? 5? things, and we want same revs as much as possible. [12:37] if it went everywhere then great [12:37] so chex just said 'meh, the works'. [12:38] :) [12:38] thanks for getting it in [12:38] lifeless, right. I didn't think it was paginated. Would still benefit from that, though the page isn't really doing much short of the listing I think. [12:38] bigjools: If you'd had it partially there I would have known in advance to ensure it got to the appservers :) Still it, did, so its cool. [12:38] deryck: I'm sure of it [12:38] 11 / 8 BugTrackerSet:+index [12:39] pity that the oops are not listed [12:43] SpamapS: hey [12:43] SpamapS: what was that 11 second api you found again? [12:50] bigjools: What do you think about bug #566339? I'm fairly sure it's not the one that you've fixed. [12:50] possibly yeah, there's more than one place that sends emails [12:51] Yay. [12:51] bigjools, so I'm not really worried about this change as it stands now, but I do have concerns other additions to the script don't come along acting on a not security proxied bug and doing things we don't want. [12:51] well the bug mail and the upload notifications I mean [12:52] deryck: totally - this change is completely isolated to that one function though, so it should be fine. I hope :) [12:52] deryck: thanks for looking [12:52] bigjools, well, I would rather have the comment above be a true XXX or a strongly worded "if you do more than fix release bugs here, this has to move to jobs." What do you think of that? [12:53] deryck: possibly - I'm not sure the job is necessary but I agree with a strongly-worded warning about being careful with the unproxied object in that function/. [12:54] then the developer can make an informed choice about what to do [12:54] bigjools, right, that works. Thanks. r=me. [12:54] deryck: great, thanks [12:56] danilos: if I'm still not getting it, perhaps we can talk my morning; tis midnight here. === mrevell is now known as mrevell-lunch [12:59] lifeless, sure [13:00] danilos: also I really want to figure out if it was canonical_url, or the template code, or 50/50 that contributed to the big +templates speedup [13:00] danilos: I'm already encouraging gary to get the new template engine widely deployed asap, but don't have enough data yet to say if we need to overhaul/replace/ditch canonical_url. [13:06] deryck: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1720G80 [13:06] 938 queries! === matsubara-afk is now known as matsubara [13:07] oh, wow. At least one very tracker then. [13:07] 1 915 4354 4 4350 SQL-launchpad-main-slaveSELECT COUNT(*) FROM BugWatch WHERE BugWatch.bugtracker = %s [13:07] its counting the bugs per tracker. [13:08] group by time boys! [13:08] ok, so that's a pretty cheap fix! [13:08] right! group by FTW! :-) [13:08] should be for a while, yes [13:08] Today's my long day, so I'll see what I can do today. [13:10] https://bugs.edge.launchpad.net/malone/+bug/618375 [13:11] lifeless: I'm thinking of making scripts that call logger.exception(msg) emit an OOPS. Worthwhile making scripts that call logger.error(msg) emit an OOPS too? Or logger.warn(msg)? [13:11] deryck: Time: 90.955 ms [13:11] jelmer: Morning. [13:11] select BugWatch.bugtracker, count(bugwatch.*) from bugwatch group by bugwatch.bugtracker; [13:11] wgrant: hi [13:11] stub: \o/ [13:12] stub: here are my thoughts [13:12] stub: things that go wrong in scripts should be oops [13:12] To all three? I was thinking of starting with exception and error. [13:12] stub: except for things that go wrong writing oops out. [13:12] stub: I'd do exception and error, and let everyone know that thats happening. [13:13] k [13:13] stub: just make sure there is a backdoor to say 'hey, oops writing failed' [13:13] (and include the traceback of *that* failure) [13:13] ok, really must go. [13:13] avoir. [13:13] lifeless: I'm not going to stop the log.error() output, just create the logs in addition. [13:13] night [13:14] jelmer: Your build uploading fixes seem to have alleviated my concerns. Looks pretty good now. [13:17] wgrant: Thanks! [13:17] jelmer: Are you deliberately storing the upload log in all cases now? [13:19] There's also a tiny race (the upload processor may catch a build after b-m moves it into incoming, but before it commits the UPLOADING status), but that may not be a concern. [13:19] This is all too complicated :( [13:23] wgrant: you're thinking we should have an explicit database commit before we do the move? [13:24] jelmer: That might work. [13:24] Otherwise, well, the extremely unlikely case will probably happen at some point :) [13:24] And then we'll have builds stuck in UPLOADING and the world will end. [13:25] wgrant: actually, it won't be an issue at the moment since the uploadprocessor will warn if it encounters a build that doesn't have the right build.status and skip that directory. [13:26] jelmer: Didn't you just change it to move it to failed? [13:26] It was OK when it just skipped. [13:37] wgrant: hmm, perhaps it should be changed back to only skip to cope with that situation [13:39] jelmer: It'd be nice if it would skip it once, but that's probably hard to arrange. [13:54] jelmer: Maybe skip if date_finished is in the last 5 minutes or something. [13:58] Gaaaaah. [13:58] Can anyone remember how to raise an exception (or do something similar anyway) in YUI3? [13:59] jml: I'm pretty close I think. I need to move the code from security.py on to the model, and tweak some methods, then get the pre-requisite branch reviewed [13:59] I haven't worked on it in a while though [14:00] Or maybe I should just stick with the JS way of doing things. === Ursinha-afk is now known as Ursinha [14:02] wgrant: A commit/flush seems like the proper thing to do though. [14:03] jelmer: As long as nothing expects an UPLOADING build to have an entry in incoming. [14:04] wgrant: right [14:08] jelmer: Previously the upload log was recorded only on failure -- it's probably fine to record on success too, but I'd like to be sure that's a deliberate change. [14:08] wgrant: yeah, I saw your point earlier. I was going to wait for Julian to come back from lunch and then ask him about it. [14:09] * bigjools is back [14:09] It might be a good idea to record it. But it's a little bit of extra librarian bloat. [14:09] wgrant: it's not recorded on successful uploads to save up on space, but lp-code has a triaged bug open about the fact that not storing it for successful builds is inconsistent [14:09] Yeah, I saw that. [14:10] Given the other large files we store for every build anyway, the space is trivial. [14:11] jelmer: the bug is filed on lp-code? [14:11] bigjools: yeah - it just talks about recipe builds [14:11] I'm inclined to stay with the existing behaviour [14:11] bigjools: https://bugs.edge.launchpad.net/launchpad-code/+bug/ [14:11] 581892 [14:12] I don't see the point of storing successful upload logs [14:12] nobody will look at them [14:13] abentley: hi [14:13] jelmer, hi. [14:14] abentley: You appear to be the reporter of bug 581892. I'm touching the related code at the moment and we were just discussing how useful having the upload logs for successful builds would be. [14:15] abentley: The upload logs are currently not stored because they're not particulary useful for anything and just take up space on the librarian. [14:15] jelmer, I think that knowing what a successful upload looks like can help with debugging unsuccessful ones. [14:16] jelmer, it also seems asymmetrical. Why store build logs and not upload logs? [14:17] abentley: build logs contain output from the package build system, they might be interesting to the uploader. [14:17] my suggestion is to make it optional depending on what the upload policy says [14:18] nobody wants or needs it in soyuz world [14:18] AFAIK anyway [14:18] but that should not block this landing [14:18] (with the existing behaviour) [14:18] james_w, that's great. [14:18] jelmer, I don't understand why "contain output from the package build system" makes it more storable. [14:19] It's useful to see how the package was built. There's more than a binary situation there. [14:19] james_w, btw, do you think it would be useful to have a tool that gets the build dependency branches for a given project? [14:19] abentley: it makes it more interesting, thus more storable. as a package uploader I often look at succesful build logs, I have never even thought about looking at the upload logs. [14:19] With a successful upload... it just works. [14:19] bigjools: That seems reasonable [14:20] mars, Around? [14:20] jml: I think so [14:20] jelmer, bigjools: when I was first looking at it and coding my own build page, it looked like something was wrong. [14:21] Because I knew the upload had happened, and I knew we store logs, but I couldnt' see it. [14:21] james_w, I don't think it would be too hard to do with what we have now. [14:21] jml: indeed not [14:21] wgrant, could you give me an example of different ways the package could be built? [14:21] bigjools: I was hoping there was quick consensus on this and we could deal with that bug (whether it be wontfix or fixcommitted), but since there isn't I'll just keep things as is for the moment and leave that bug alone. [14:22] james_w, perhaps I'll knock up a prototype and then see if I can get someone else to take over work on it :) [14:22] abentley: the soyuz build pages seem to be fine without it [14:22] abentley: the compiler output would be part of the build output [14:22] abentley: configure might make a bad decision based on the installed build-dependencies. [14:22] jelmer: it should be policy based [14:22] (although more likely I'll get distracted fixing txrestfulclient [14:22] ) [14:22] abentley: There could be build warnings. [14:23] We could have braindead packages detecting the installed kernel version and tailoring themselves to it grrrrrr. [14:23] jml: good idea [14:23] both of them [14:23] :) [14:24] wgrant, thanks. [14:24] So, I agree that it would be nice to store successful upload logs, and it would make things more consistent. [14:24] But they're really not useful, and are a bit of bloat. [14:25] abentley: Why did Code want them? [14:26] wgrant, when I was coding up the the build pages, I found it surprising. I thought the upload logs were "missing". [14:26] Ah. [14:26] mars, Unping; I'm an idiot. [14:27]