[00:15] [6~[6~ [5~/wg 61 [00:15] argh, lag [01:43] argh [01:43] set_up_tacfile_logging [01:44] That's not the problem here, AFAICT, but yeah. [01:44] I commented it out, still borked. [01:44] well [01:44] It's evil, though. [01:44] I'm yak shaving on the stdio thing [01:44] Ah [01:44] its that or yakshave on a manhole [01:45] so [01:45] the channel is set to pretend to be non-errors [01:46] which is why that function isn't the cause of the looping [01:46] Ah [01:46] channel = logging.StreamHandler(log.StdioOnnaStick()) [01:46] thats what is connected to the python logging system [01:47] note further that the python logging stuff *also* needs a oops handler attached (with special gymnastics) because set_up_tacfile_logging turns errors into plain messages [01:47] special gymnastics because its calling 'normal' oops code in a twisted appserver. [01:47] climb through, if you dare [01:48] aaaaaaah [01:48] -> execute_zcml_for_scripts() [01:48] (Pdb) [01:48] and thats where my prompt disappears [01:53] it may just be horrendously slow under pdb. [01:53] ah yues [01:53] aieee [01:53] someone in twisted had a daft day [01:53] 623 -> def startLoggingWithObserver(observer, setStdout=1): [01:54] there appears to be no way to control that. [01:55] Heh [01:57] Twisted-11.1.0-py2.6-linux-i686.egg/twisted/application/app.py(228)start() [01:57] the use of -n doesn't stop this happening [01:57] so, interactive debugging -> nah, we can't do that [01:57] now, with that hacked in, lets see [01:59] oh joy [01:59] and then we re-setup logging doing that against as well [01:59] We have to be sure :) [01:59] via ib/lp/services/sshserver/service.py(174)startService() [01:59] yay. [02:00] now I have pdb, I am all powerful [02:00] 12K oopses written [02:00] then it stopped [02:01] 2 oopses this time [02:02] now 1 [02:02] heisenbug [02:04] lifeless, if we depend on python-fixtures is that likely to be released etc? [02:04] backported even? [02:04] useless backtrace though [02:04] poolie: hi released for sure [02:04] poolie: I have no idea about backports to official ubuntu; it is in a ppa building for a wide set of releases [02:04] i guess adding dependencies is a muscle that should be worked [02:04] it hurts :) [02:07] wgrant: https://bugs.launchpad.net/launchpad/+bug/901498/comments/5 [02:07] <_mup_> Bug #901498: poppy-sftp OOPSes infinitely < https://launchpad.net/bugs/901498 > [02:08] wgrant: :!ls -l /var/tmp/lperr/2011-12-08/ | wc -l [02:08] 5 [02:08] wgrant: suggestions on making it break solicited [02:08] lifeless: That normally degrades into infinite recursion, I believe. [02:08] of course, it might be the setStdout thing [02:08] wgrant: hasn't for me [02:08] Even when you run without your hacks and without -n? [02:09] its the setStdOut parameter to startLogging [02:11] * lifeless runs with 2>/dev/null [02:11] right [02:12] our logging is wired up to stderr [02:12] and we redirect stderr to be an OOPS [02:12] our *python* logging is wired up to stderr [02:14] Ah [02:14] we have logging wired up to stderr for scripts [02:14] where the stderr goes to lp-error-reports [02:14] for 'help me' reporting [02:16] wgrant: analyzed https://bugs.launchpad.net/launchpad/+bug/901498/comments/7 [02:16] <_mup_> Bug #901498: poppy-sftp OOPSes infinitely < https://launchpad.net/bugs/901498 > [02:19] oh wow. we export a function from a package. [02:19] bah [02:19] function from a module as the same name as the module [02:19] lib/canonical/launchpad/scripts/__init__.py line 31 [02:24] ok, this is crazy. going in loops :( [02:26] while poppy=aaaaaa; do sudo crazy --user=lifeless ; sleep 5 ; done [02:27] lifeless, i don't suppose you would be open to reconsidering https://code.launchpad.net/~mbp/launchpad/show-timeline/+merge/80166 to not consolidate it with ++profile++ for now? [02:27] the profile code is a bit hardcoded [02:27] i feel a bit averse to refactoring it [02:27] at least until i know if this is actually useful [02:29] mmm [02:29] If you want to land it, and then either refactor or remove it in january sometime, thats fine [02:30] I don't want deliberate duplication in this area; it is as you note already clumsy, and duplication around it makes that worse. [02:30] so I'm *not* ok with landing it and then forgetting about it. [02:30] ok, deal [02:30] i promise to at minimum delete it [02:30] ok [02:30] thank you [02:31] hopefully it will actually be useful and we can unify them [02:31] i will add an integration smoke test [02:41] wgrant: feedback wanted [02:41] https://bugs.launchpad.net/launchpad/+bug/901498/comments/8 [02:41] <_mup_> Bug #901498: poppy-sftp OOPSes infinitely < https://launchpad.net/bugs/901498 > [02:41] I thnk I have a full handle on it now [02:45] lifeless: That sounds reasonable, I think. [02:46] But I don't know twistd. [02:58] StevenK will rejoice [02:58] Oh? [02:58] he has a branch to delete setup_tacfile_logging [02:59] I suggested that he needed to figure out this set of intricate pain to move forward and it stalled [02:59] having figured it out, it should be fairly straightforward to make a patch [02:59] Ah [03:03] lifeless: What's your plan, then? [03:03] StevenK: https://bugs.launchpad.net/launchpad/+bug/901498/comments/8 [03:03] <_mup_> Bug #901498: poppy-sftp OOPSes infinitely < https://launchpad.net/bugs/901498 > [03:05] Hmm, I'm can't recall that branch [03:05] * StevenK looks [03:06] Found it. [03:09] lifeless: Does one just use https://lp-oops.canonical.com/admin/oops/prefix/ to assign appinstances to prefixes? [03:09] yes [03:09] * wgrant fixes them up. [03:09] per the docco wiki page [03:09] its a bit horrible [03:09] Horrible? This is Django! [03:09] a bit, not a lot [03:10] jus tsome of the maniuplation gets clumsy [03:10] lifeless: So I should resurrect my branch? [03:10] Oh goody. [03:10] We have 'production' and 'lpnet' appinstances. [03:10] StevenK: I think so, especially if you're up to tweaking the other bits too [03:10] wgrant: production was scripts etc [03:10] wgrant: lpnet is just appservers [03:11] IIRC [03:11] Probably. [03:13] lifeless: I would, but I have no idea how to. [03:14] lifeless: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-04319168ea720529358ae77eb667fea9 [03:14] zomg links that work :P [03:14] YES [03:14] StevenK: I can give you pointers [03:15] wgrant: epic fail traceback [03:16] wgrant: the no URL thing is interesting [03:16] Yes. [03:16] wgrant: no req variables either [03:16] It probably happened aoutside the request. [03:16] It's in the disconnection. [03:16] wgrant: can you file a bug for this? it managed to keep the timeline though. [03:16] * StevenK points lifeless to this whole annual leave thing. [03:16] StevenK: are you there now ? [03:17] StevenK: you could link your branch in as a starting point (just in a comment I mean) [03:19] Hmm. [03:19] Our DB needs pruning. [03:19] wgrant: oops DB? [03:19] lifeless: Comment 9 [03:19] So many obsolete unreferenced prefixes. [03:19] Yeah. [03:19] wgrant: oh, prefix pruning. [03:19] wgrant: wait till we have the new configs streamline [03:19] 139 unreferenced prefixes. [03:19] SSO and crap. [03:19] Yeah. [03:23] poolie: the linaro thing is a sadness [03:23] Which thing? [03:26] zygmund? I forget the spelling - moved a linaro project to github, unilaterally. [03:27] with a bit of a rant about usability [03:27] some true aspects [03:30] yeah [03:30] some seems fairly easily fixable :/ [03:32] Yes. [03:32] But the problem is they've been fairly easily fixable for 4 years. [03:32] And they're still not fixed. [03:37] a few good men [03:38] I'd suggest they get escalated, but what good will that do. [03:41] wgrant, they are actually a bit more easily fixable now [03:41] (I don't actually know what they are) [03:42] YHBTHANDHTH [03:42] ... [03:45] you have been trolled etc [03:46] Wgrant sometimes needs the reciprocal branded on his forehead :) [03:46] I was being quite serious :) [03:46] except you didn't know the specific issues [03:47] featurefixture assumes every defined feature is true :( [03:47] can be fixed [03:47] s//flag [03:47] so you were at minimum applying /some/ hyperbole [03:47] Some, yes. [03:47] But it was a reasonable assumption. [03:48] lifeless: i was pretty unhappy he did that [03:49] mwhudson: I am too [03:49] So am I. Doesn't meant I don't see his points as valid :) [03:50] mwhudson: he could at least have offered some patches [03:51] my upsetness is probably from a different direction though [03:52] mwhudson: sharable? [03:52] lifeless: bad timing, and we're supposed to be a team dammit [03:52] exactly [03:53] mwhudson: What made the timing bad? Team thing yes, I agree - thats kindof where my point was... [03:53] mwhudson: though I think that Linaro being a separate org makes that a little less clear. [03:53] lifeless: the project is a bunch of scripts we use for deployment [03:53] lifeless: he moved it <12 hours before we used them for the first time for a production deployment [03:53] oh wow [03:58] mwhudson: who reports to whom in this structure? [03:58] zyga and i both report to paul larson [04:14] short review anyone? https://code.launchpad.net/~mbp/launchpad/featurefixture-from-request/+merge/84887 [04:16] lifeless: Did you have a fix for https://lp-oops.canonical.com/?oopsid=OOPS-5c5df29093442e212197300c3b8d2f8a? [04:16] bah, slid off plate [04:16] let me shelve my DB changes and I'll get on it [04:16] wgrant: you're landing the soyuz start tweaks? [04:17] wgrant: was there a bug for this ? [04:17] ah yes, 898638 is it [04:17] lifeless: They landed a few hours ago. [04:17] lifeless: Also, your (qa)staging de-oops-prefix-isation made various staging OOPSes show up on prod. [04:18] wgrant: win [04:18] Because there are prefixes configured in schema-lazr.conf, for some probably not very good reason. [04:18] eg. CB and CID [04:18] And CIW [04:18] HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAAHAHHAAHA [04:18] And APPORTBLOB [04:18] Anyway. [04:18] caretokill ? [04:18] Not really. [04:18] Might as well just kill off all prefixes on Monday. [04:18] :) [04:18] Actually. [04:19] well, all script ones [04:19] I guess we can sensibly just drop those now, can't we. [04:19] Since we're using the new datedir-repo on prod everywhere. [04:19] set to none in the schema [04:19] Yeah, just was thinking it wasn't safe everywhere yet. [04:19] wgrant: we haven't updated the prod config yet [04:19] But it is. [04:19] They don't need to be unique any more, and reporter defaults to something sensible for scripts now. [04:20] yes, that part of it definitely [04:20] I'll remove all the prefix defaults now. [04:21] http://pastebin.com/3Q7v6YVD [04:22] aaaa [04:22] but ok [04:22] how do you propose to address it ? [04:23] I don't have any better ideas. [04:25] whee [04:25] File "/usr/lib/python2.6/urllib.py", line 1222, in quote [04:25] res = map(safe_map.__getitem__, s) [04:25] UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal [04:25] close enough to demonstrating the problem IMO [04:25] and with the fix [04:37] wgrant: lp:~lifeless/launchpad/bug-898638 [04:37] lifeless, what is an 'extra oops message'? [04:38] nm [04:38] wgrant: review - https://code.launchpad.net/~lifeless/launchpad/bug-898638/+merge/84891 [04:38] poolie: have a look in errorlog.py, should be fairly obvious [04:38] like with globalErrorUtility.oopsMessage(oops_message): ? [04:39] something like that yes [04:39] I don't know if there is a good API for 'and I am not raising right now' [04:39] I hope there is [04:39] otherwise I'm sending you off yak shaving again [04:39] (which wasn't my intent) [04:40] lifeless: APproved [04:41] we need a longpoll hook for changes to the MP other than diff [04:45] has stubs stuff landed again ? [04:45] * lifeless checks [04:46] It has, yes. [04:58] wgrant: https://code.launchpad.net/~lifeless/python-oops-tools/prune/+merge/84892 [04:58] I need to remember to not hit refresh. [05:06] wgrant: diff is there :P [05:07] lifeless, according to some documentation, oops messages are not supported in the webapp because they're not thread safe [05:08] poolie: hmm, so I believe we have per-thread utilities [05:08] poolie: so if I wrote that, I was misguided. [05:10] lifeless: k [05:10] r=me [05:29] where are oopses from make run now put? [05:29] /dev/null unless you have python-oops-tools set up, or kill rabbit. [05:30] i guess i'm really asking, what's the easiest way to look at them [05:31] poolie: run up oops-tools locally. [05:31] It's actually pretty easy nowadays. [05:31] poolie: give me 5 minutes to land a switch to the LP sourcedep branch and it will be even easier. [05:31] Although it would be nice if you didn't have to create a special postgres cluster and blah. [05:31] wgrant: patches gratefully. [05:31] srsly [05:31] ok thanks [05:31] poolie: If you kill rabbit and cause an oops, it will appear in /var/tmp/lperr as before. [05:32] wgrant: is there an exchange by default ? [05:32] wgrant: w/no exchange they should be written to disk regardless [05:32] lifeless: Hmm, that's true. [05:33] Perhaps the dev rabbit is more persistent than I thought it was. [05:33] poolie: I'd expect by default they arrive in /var/tmp/lperr/ [05:34] poolie: if you have oopstools you can glue it in very easily. I reference an email describing this from https://dev.launchpad.net/QA/OopsToolsSetup [05:34] the precise link is [05:34] https://lists.launchpad.net/launchpad-dev/msg08183.html [05:34] (but see https://dev.launchpad.net/QA/OopsToolsSetup#Deploying_locally_.28e.g._devpad.29 anyhow) [05:35] sadface [05:35] bzr resolve --all download-cache/ [05:35] bzr: ERROR: If --all is specified, no FILE may be provided [05:35] Yeah, that sucks :/ [05:35] bzr resolve --all -d download-cache/ [05:35] bzr: ERROR: no such option: -d [05:35] cd download-cache/ && bzr resolve --all && cd - [05:35] /home/robertc/oops-tools [05:37] :/ [05:39] man, I wanted to get so much more done today [05:39] E-TIME [05:39] of course, having rogue services check up gb's of queue memory is a good excuse. [05:41] Indeed. [05:41] 14M oopses from one service is quite the exceptional circumstance. [05:42] wgrant: you're missing the 700K it processed. [05:42] wgrant: that graph was depth, not volume [05:43] lifeless: True. [05:43] lifeless: Although some of that 700000 was from after the peak. [05:43] But before I hacked it to skip them. [05:43] wgrant: not really [05:44] wgrant: it had 9 hours of constant chewing on them [05:44] True. [05:44] wgrant: and ~20 minutes of quad consumer [05:44] Yeah [05:44] so thats 9*60=540 vs 80 [05:47] stub, this is for stub, this is for https://code.launchpad.net/~mbp/launchpad/666765-features-no-reasons/+merge/84050 [05:47] any better ideas welcome [05:47] poolie: does the request flags controller know the scope values ? [05:48] poolie: if so, adding an oops hook, or extending attach_request, would be clean. [05:48] yep [05:48] i don't understand how the existing use of it is really safe [05:48] i guess it's mostly stateless [05:48] its probably not [05:48] in the way it's used in the webapp [05:48] ok that should work [05:48] this is old and crufty code mostly facelifted [05:50] poolie: I think at the moment all data is attached to the request, which is effectively thread local and gets destroyed at the end of the request. The utility certainly should be stateless, or failing that use thread local storage. [05:50] certainly the amqp publisher has TLS built in [05:51] and the datedir repo publish function doesn't alter global state (though the old one did). All hail clean code. [05:51] right except it has this concept of 'messasges' which mislead me [05:51] I attached something to the OOPS reports via request the other day but can't remember what it was now... :-/ [05:51] pulling it from the request at the time it's fired looks like it will work [05:51] stub: the previous oops [05:51] and is even slightly clean [05:51] * stub wanders off on his walking frame to grab a cup of tea [05:51] ahh... that's right [05:54] poolie: trunk of python-oops-tools is now using the lp sourcedeps cache. [05:55] I'm going to mail the list a tl;dr summary in a second [06:48] all my lp branches failed with that soyuz apparently spurious failure [06:48] Yeah, it's become extremely common lately. [06:48] Possibly 100% common. [06:49] I have two branches in ec2 now that I'm going to try to catch. [06:59] wgrant: I've been trying to Q/A a change to PackageCloner.packageSetDiff… any idea how I exercise it? I thought I could initialize a distroseries but haven't had much luck with that. [06:59] (And what is a SetDiff?) [07:02] It's a diff of a package set. Note that a package set is not to be confused with a packageset. [07:03] Initialising a new distroseries in the same distribution should use the cloner. [07:03] But the easiest way is to use populate-archive to create a copy archive. [07:03] That uses the cloner. [07:04] And specifically packageSetDiff? [07:06] Hmm. [07:06] I'm not sure that's ever been used. [07:06] The cloner was initially going to be able to do progressive copies, IIRC. [07:06] But that never got finished AFAIK. [07:06] ok, night all [07:06] At least never used anywhere. [07:07] night poolie [07:07] wgrant: then I guess qa-untestable. [07:10] jtv: Probably. [07:17] wgrant: Thanks. By the way, it runs on cocoplum, right? [07:17] The package cloner in general? [07:19] Yeah. [07:19] Mostly. [07:22] Mostly..? [07:22] “They mostly come at night. Mostly.” [07:22] * jtv flashes wgrant a terrified look [07:23] It would occasionally be run from loganberry, probably, and will soon be on bilimbi. [07:26] I'm filing NDT & cocoplum rollouts then. [07:26] Objection. [07:26] ? [07:26] We can't roll out to cocoplum until next week., [07:26] poppy is a bit fucked [07:26] Took down all of LP this morning. [07:26] But that's germanium innit? [07:26] By overloading rabbit with 14 million OOPSes in 10 hours. [07:26] whoopie [07:26] poppy is both cocoplum and germanium. [07:26] Is that the new logging of GPG errors? [07:27] A bug in the new OOPS infrastructure. [07:27] Which causes the first error to create an infinite loop. [07:27] Of OOPSes. [07:27] I shouldn't have joked about that the other day. [07:28] https://lpstats.canonical.com/graphs/ProductionRabbitOopsQueue/20111208/20111209/ [07:28] wgrant: that should be on LPS in the cherrypick section I suspect [07:28] lifeless: It's in the cowboy section. [07:28] cool cool [07:28] I'll add germanium as well. [07:30] also https://lpstats.canonical.com/graphs/AppServerRequestLpnet/20111208/20111209/ which we have no current clue about [07:30] wgrant: is the upshot that rolling out to cocoplum doesn't work today? Or that do so would break something, and if so, how? Would it override a cowboy, for instance? [07:30] jtv: Rolling out to cocoplum will work for a few hours, and then cause all production services to hang. [07:31] Bug #901498 [07:31] <_mup_> Bug #901498: poppy-sftp OOPSes infinitely < https://launchpad.net/bugs/901498 > [07:31] So it would break something. [07:31] That's something I hate even more than just not being able to do it. [07:31] https://bugs.launchpad.net/launchpad/+bug/901498 [07:31] <_mup_> Bug #901498: poppy-sftp OOPSes infinitely < https://launchpad.net/bugs/901498 > [07:32] lifeless: Well, it's nothing to worry about. [07:32] lifeless: Data collection on loganberry probably just hung for a while. [07:32] lifeless: Note that there's a gap, and then the next point is high -- it's the sum of the missing data. [07:32] wgrant: argh. As usual I didn't see the moin warning until I hit the button. :( [07:32] wgrant: I'm afraid I cross-edited LPS. [07:33] Very sorry. [07:33] I still want a red background with a skull-and-crossbones motif when that happens. [07:34] jtv: It's a far too subtle warning. [07:34] I think it's actually more subtle than the warning that other people will be warned. [07:34] restyle it [07:34] we have a branch with the theme [07:34] lifeless: wiki.c.c? [07:34] jtv: What'd you change? Added a deployment request? [07:34] Ah, yeah. [07:34] No conflict. [07:35] * wgrant saves. [07:35] wgrant: yes, pretty sure. check with webops. [07:35] No, edited my existing deployment request. [07:35] Poppy oops loop. Now there's something to say quickly. [07:35] or as I like to say [07:35] poops [07:37] well if you had to say "poppy oops loop" a few times, chances you'd have ended up saying it anyway [07:37] chances *are [07:37] This keyboard lets my fingers fall too far behind my brain. [07:40] jtv: I've amended your suspended request further, to request germanium as well. [07:40] Because it's nice to keep them together. [07:40] They have the same downtime constraints, so there's no reason to let them diverge. [07:41] I was wondering about that. Is there any particular reason why we don't deploy those as a coherent set? [07:41] Because I only just altered LPS to recommend that that be done. [07:42] there's probably not much benefit in adding a special alias for them. [07:42] And we can't really merge the nodowntime-but-not-nodowntime targets into a single set, since they require codehosting. [07:42] (codehosting, mailman, librarian are nodowntime-but-not-nodowntime) [07:44] nowdowntime-but-not-nodowntime..? [07:45] Able to be deployed without downtime, but not in nodowntime because their upgrades require handholding. [07:45] Should we have a plus-zero-downtime set? [07:46] Heh [07:53] mailman needs to be divorced from LP [07:53] made into a separate consumable thing, not part of the same tree [07:53] Yes. [07:53] that will eliminate one of those [07:54] I've run that broad plan past elmo for comment, and he is (provisionally) cool with it [08:53] good morning [08:56] morning adeuring [08:56] hi jtv [08:56] Hey [08:57] hi mrevell [09:39] given Bug #788819, do I need a second bug to be able to subscribe to all team branches? [09:39] <_mup_> Bug #788819: want to subscribe to all merge proposals project wide < https://launchpad.net/bugs/788819 > [10:17] ocr: https://code.launchpad.net/~lifeless/python-oops-amqp/bug-901497/+merge/84915 plox === almaisan-away is now known as al-maisan [10:59] stub: around? should we catchup? [11:03] stub: I'll try to catch you tomorrow. EHALT now. [11:04] allenap: ditto for you (re the bug I was talking to julian about) [11:04] lifeless: allenap is not around reliably today [12:08] lifeless: night [12:21] morning everyone [12:24] bigjools: Seen IND vs WI match? [12:26] nigelb: yes, amazing [12:26] :) [12:26] The office seems to be in party mode :P [14:07] jcsackett, can you check your email to verify you were notified that you were assigned a bug? I am verifying that email is working...you can ignore the bug [14:08] sinzui: this was within say the last hour? (i have a misbehaving bug mail filter, so i'll need to search) [14:09] It was 15 minutes ago [14:10] sinzui: i see no email. [14:10] okay === jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jcsackett | Critical bugtasks: 3*10^2 [14:43] hey, is there something wrong with the builders. the queue seems pretty big. [14:43] or is this just usual flux [14:44] jml: probably a result of the librarian outage the other day [14:47] bigjools: that and we were missing some builders [14:47] or are [14:48] back saturday i think [14:48] flacoste: nothing to do with that unfortunately [15:05] oops, don't list active feature flags right? === Ursinha is now known as Ursinha-lunch [15:22] * deryck goes afk for early lunch/errands, back in hour === deryck is now known as deryck[afk] [15:30] jml: remember when we wrote some poppy tests and you duplicated them across ftp and sftp by using "multiply_tests" in the loader? [15:30] bigjools: yes. [15:30] jml: do you know how to run only one scenario? [15:30] bigjools: yeah, just pick the right regex [15:30] the test name that it prints when running is not recognised by -t [15:31] test.py test_poppy [15:31] well finding the regex is proving hard :) [15:31] for example: [15:31] lp.poppy.tests.test_poppy.TestPoppy.test_bad_gpg_on_changesfile(sftp) [15:31] bigjools: don't use -t, use the two regex way of selecting tests [15:31] ahl ISWYM [15:32] jml: didn't work :( [15:32] unless ( and ) need escaping [15:32] probably they do [15:32] I'm guessing you just want ftp [15:32] aha there we go [15:32] how'd you guess :) [15:32] that did it, thanks jml [15:32] you could probably also change the name of the scenario [15:35] jcsackett: could you please review this MP: https://code.launchpad.net/~adeuring/launchpad/history-model/+merge/84973 ? [15:35] adeuring: sure. [15:35] jcsackett: thanks! [15:54] I'm confused. I didn't realize we still used the release-cirical-only mode of PQM any more, yet my branch just got rejected because of it. === deryck[afk] is now known as deryck [16:32] benji: there were two buildbot failures earlier on [16:33] adeuring: r=me, sorry for the delay. [16:33] unless a testfix was landed or a rebuild requested [16:33] jcsackett: thanks :) [16:33] we are in testfix mode [16:33] benji: so we are not using release-critical anymore [16:33] but testfix yes [16:33] flacoste: let me double-check, but I'm pretty sure the rejection email said release-critical and not testfix === salgado is now known as salgado-lunch [16:34] benji: the message might be wrong [16:34] i think we are still in testfix [16:34] because nothing was done with the db_lp failures === al-maisan is now known as almaisan-away [16:36] flacoste: heh, my tendancy to read right to left combined with the fact that the regex has *both* testfix and release-critical in it bit me [16:36] what was the issue with "True != False: memcached is live but should not be." [16:36] these errors happened both on lp and db_lp? [16:36] was it deemed transient? [16:36] should we trigger a rebuild on db_lp? [16:37] or the same fix that got applied to lp should be to db_lp? [16:42] rick_h_, hey. can you just pastebin me the queries you want run, in order. Just the queries, no extra text. [16:42] deryck: sure thing, sec [16:44] deryck: http://paste.mitechie.com/show/466/ [16:58] flacoste, I came back in for only part of a conversation you were having with someone, and no-one replied. I'm going to assume that we still need someone to investigate the issues that benji raised in email, and the buildbot failures. [16:58] I'll arrange for it to be tackled. [17:00] benji, could you try reverting the new germinate locally as Francis suggested? I'm not sure how to do it, and if you are not either, I bet there are many people who could help you. [17:00] rick_h_, I don't follow the "repeat" comment below. Do I need to change an id and run them again? [17:00] deryck: yes please, I want to then get the same info for the parent messages of those two [17:00] I guess that the memcache error on buildbot is about some memcache that started and shouldn't have. [17:00] rick_h_, what is the parent message? [17:00] parent field in the results [17:01] message.parent [17:01] I'll try to investigate that [17:01] should be either null, or ids of messages as well [17:01] deryck: ^^ [17:01] gary_poster: I haven't upgraded it manually so I doubt I have the newest version, let me check [17:03] rick_h_, I don't get anything for the first results. [17:03] 0 rows [17:03] benji, it would be upgraded automatically when you upgrade stuff because we have Launchpad's PPA as a source [17:04] deryck: http://paste.mitechie.com/show/468/ ? [17:04] I guess you mean you didn't update launchpad dependencies, you just installed the missing dependency? [17:04] If that's the case you should definitely update all your dependencies before you try again [17:04] gary_poster: by "when you upgrade stuff" do you mean running a blanket "apt-get upgrade"? I haven't done that lately. [17:04] rick_h_, https://pastebin.canonical.com/56886/ [17:05] deryck: ok, thanks [17:06] adeuring, you linked a branch to bug 898200, which is the dupe. bug 295214 is the master bug. [17:06] <_mup_> Bug #898200: Can't sort bug list by customized fields < https://launchpad.net/bugs/898200 > [17:06] <_mup_> Bug #295214: ordering options should match data that is displayed in bug listings < https://launchpad.net/bugs/295214 > [17:06] adeuring, well, sorry, maybe you linked both? skimming through mail now. ;) [17:07] deryck: right, I linked both [17:07] adeuring, ok, cool. Sorry for the noise. [17:07] np === Ursinha-lunch is now known as Ursinha [17:09] deryck: one more please: http://paste.mitechie.com/show/469/ [17:10] gary_poster (and flacoste): neither updating germinate or using an older version makes my errors (http://paste.ubuntu.com/763881/) go away [17:10] gary_poster: I'd be surprised if the new germinate could have broken anything, since prior to https://code.launchpad.net/~cjwatson/launchpad/refactor-cron-germinate/+merge/84624 (which hasn't landed yet), it wasn't actually tested [17:11] holy smoke, what happened yesterday on buildbot? The currently running build has over 88 revisions, which start from over a week ago [17:11] it certainly has nothing to do with builds [17:11] as in buildmaster [17:13] cjwatson, germinate not being a cause makes sense in general. There does seem to be a difference between ec2 and buildbot results though, and deb dependencies would explain it. That said, something appears to be seriously screwy here. [17:13] in buildbot [17:13] and our devel [17:14] sure - just trying to help cut out probable red herrings [17:15] code not run in any tests has a low probability of breaking tests :-) [17:15] cjwatson, cool, thx. when you said builds are not at fault, that's in response to looking at benji's pastebin (email)? http://paste.ubuntu.com/763881/ [17:15] it looks build-y but I don't know that system. === salgado-lunch is now known as salgado [17:26] rick_h_, https://pastebin.canonical.com/56889/ [17:30] mrevell, I've seen so much mail about long bug titles and one line vs. two, I can't even follow it any more. [17:31] mrevell, I feel like we're trying to solve too many problems. What are we trying to solve? Are trying to get everything on one line, or trying to make better use of the space? [17:34] Hey deryck. My priority is this: we should offer a one-line view that gives the same info you can get from the currently live non-beta bug listings. If there's a way that we can also cater to wider screen users by putting additional data to the right-hand of their wide page, rather than on a second line, then that'd be a nice bonus. I'm sorry this has become a confused issue over the past few days. [17:35] I believe we've solved that first part. [17:36] mrevell, no worries, I just want to be clear. it feels a bit like we're talking about ideas, just to be talking now. And I was losing *why* we're discussing this. :) [17:36] mrevell, my impression from the check point call was that we had done as well as good on this, and we'd come back to this if we could, but were not really trying to. [17:36] mrevell, so I could have completely misunderstood, sorry. [17:38] deryck, Sorry, I should have given a clearer direction to the mailing list threads. The discussion I was hoping for was about whether it was possible to use people's widescreens more effectively, while not forcing horizontal scrolling or too much wrapping on narrower screen users. I agree, the discussion seems to have strayed. Got time for a quick call? [17:40] mrevell, yeah, that might be useful. I'm sorry. I think the discussion is happening across two different threads, too. [17:40] mrevell, skype? [17:40] sure [17:41] mrevell, ready when you are. [17:57] bigjools: you can use load-list to run one scenario precisely [17:57] lifeless: never mind that, help with me logging! [17:57] about to run out of hair [17:58] sure, give me 5 to do some essential I-just-woke-up-stuff [17:58] and you'll have my full attention, FWTW [17:58] TMI [17:59] mrevell: I *love* your attitude [17:59] You do? :) [17:59] mrevell: totally. [17:59] mrevell: re the thing poolie forwarded. [18:00] mrevell: your response has made my day, and it has only just started [18:01] gary_poster: that wasn't what I meant actually; sorry to confuse. What I said was that germinate is not involved in anything to do with the buildmaster [18:01] or what I meant to say [18:01] gary_poster: germinate is loosely-coupled to the publisher, rather than to builders [18:02] lifeless, Ah, cool :) [18:02] mrevell: FYI: I rarely do sarcasm online; it doesn't transcribe well enough to avoid confusion. [18:03] mrevell: so you can take emphatic positive statements as being what you see [18:03] Great :) [18:03] lifeless: I need to eat, I'll be back online in ~1hr [18:03] bigjools: ok. I'll look at your notes on the bug [18:03] bigjools: and repage it all in in prep. [18:03] rick_h_, I took a look at your MP again. Generally it looks great. Can we chat via mumble or Skype about something with it? [18:03] lifeless: I solved the problem - sorta. :) You'll see ... [18:03] deryck: sure thing [18:03] bigjools: I fear the pastch [18:03] rick_h_, mumble or Skype? [18:03] gary_poster: ah, Benji suggests python-lpbuildd in https://lists.launchpad.net/launchpad-dev/msg08641.html, which makes a lot more sense as that package is actually related [18:04] deryck: mumble [18:04] ack [18:15] rick_h_, see if Skype is better? [18:15] deryck: ok [18:20] gary_poster: i asked myself the same question about the 88 revisions build [18:20] Night all [18:20] and didn't find a satisfactory answer [18:20] there are like several testfix in there [18:21] flacoste: https://bugs.launchpad.net/python-oops-amqp/+bug/901449 is looking to me like its the longpoll code failing [18:21] <_mup_> Bug #901449: Rabbit failure when sending an OOPS seems to hang the producer < https://launchpad.net/bugs/901449 > [18:22] benji: i think your failure is bug #779367 [18:22] <_mup_> Bug #779367: spurious failure in test_builder.TestSlave < https://launchpad.net/bugs/779367 > [18:23] lifeless: how so? [18:23] * benji looks. [18:23] flacoste: unreliablesession is a longpoll thing [18:24] flacoste: the idea of 'big oopses' is a distraction. The issue was volume not size. [18:24] lifeless: i got that, so poppy was the source of the volume, which killed rabbit [18:25] and the app server dying is because of a bug in unreliable sessio? [18:25] flacoste: I *think* that unreliablesession is being hooked in automatically in the appservers; and it has (at least one) bug in handling rabbit issues (see comment 2) [18:25] flacoste: it might be, comment #3 is exactly the same as mine [18:26] flacoste: I think it may be. Doesn't mean we should stop looking [18:26] flacoste: there is also bug https://bugs.launchpad.net/python-oops-amqp/+bug/901497 which could indeed affect LP appservers during rabbit issues [18:26] <_mup_> Bug #901497: close_ignoring_EPIPE can trigger IOError < https://launchpad.net/bugs/901497 > [18:26] I've just pushed a release for that [19:02] hi flacoste, trunk for lazr.uri is an old bzr format and it breaks dailydeb. can you upgrade it? for some reason that branch, unlike most other LAZR projects, is owned by PQM not ~lazr-developers [19:03] flacoste: btw, lazr.uri and lazr.restfulclient need to be backported for the natty SRU of launchpadlib [19:06] deryck: ping, I've got the start working, but not sure if the look is going to pan out. http://uploads.mitechie.com/lp/limited_textinput.png [19:07] deryck: before I go with it more, what do you think, do we want to keep going with it? [19:07] bac: if it's owned by PQM, it will need to be done by a losa [19:07] rick_h_, well, if we can drop the scrolling and overflow, have the outer-styled element expand as the stuff overflows, and drop the border around the input, then yeah, that could work. ;) [19:08] rick_h_, but if that leads to cascading issues, then I think it's not worth pursuing. [19:08] flacoste: any reason to not change the ownership at the same time? [19:08] bac: probably not [19:08] will do [19:09] deryck: ok, yea didn't want to get too crazy changing all the css styles/etc. More meant the space on the side that appears and the fact that it'll cause more text to hit the default max_height setting of the resizing widget [19:09] which brings up scroll bars [19:10] deryck: I can remove the max height setting when used from the inline edit, but not sure if that would bring up other issues [19:11] rick_h_, I leave that to your judgement. Sorry, just don't know the ramifications of the max height restrictions without working on it more myself. [19:11] deryck: ok, sounds good. [19:13] bac: most lazr trunks *should* be pqm or tarmac managed (same user) - we just haven't got a round tuit [19:14] lifeless: oh, i thought this one was the outlier in the wrong direction [19:14] o/ lifeless [19:14] bigjools: oh hai [19:14] bigjools: do you want voice ? [19:15] lifeless: if I had remembered to bring my headset in.... [19:16] lifeless: the more I see of Twisted logging, the more I shake my head in disbelief [19:19] lifeless: I got as far as noticing that the twisted stuff was monkey patching sys.stdout and then I quit in disgust [19:21] bigjools: right [19:21] that happens from self.logger.start(application) deep in twisted [19:21] we have to work with that [19:22] it framed the situation for my proposed solution [19:22] (sorry for the slight latency replying, helping lynne with meds for cynthia) [19:23] no worries [19:23] lifeless: so I expect this is part of the problem with sys.stdout not working in the stream handler [19:24] but what I can't fathom is the duplication if I use stdioonnastick [19:24] the looping ? [19:24] no [19:24] it prints each message about 20 times [19:25] *bizarre* [19:25] I did not see that [19:25] apply the diff in my paste [19:25] use the log.stdioonnastick option [19:25] ok, so RotatableLogFileObserver fits in as a replacement observer [19:25] we want that to be the fallback observer for the OopsObserver [19:26] ye [19:26] s [19:28] so, we don't want errors going to stdout/stderr because nothing is watching those streams on the daemon [19:28] tbh I was trying to rip out all use of the python logger and use twisted's [19:28] that would be ideal [19:28] but [19:28] but [19:28] Hooks has some debug logging [19:29] we use an unknown amount of LP code today [19:29] someone might add a logging output in there somewhere and screw us [19:29] so we have to handle it [19:29] right [19:29] if we get one solid recipe [19:29] we should be set [19:29] I have had an unpleasant day working all this out [19:29] I bet [19:30] So, I think we need to do: [19:30] logging.basicConfig(stream=sys.stdout) [19:31] before all the twisted application stuff kicks in - e.g. where setup_tacfile_logging happens is fine. [19:31] the fiddling with channels etc isn't needed [19:31] ok [19:31] we can pass level=X to that function too [19:31] http://docs.python.org/library/logging.html#logging.basicConfig [19:32] using getLogger('poppy-sftp') should be fine [19:32] *should* :) [19:32] but wasn't [19:32] once everything else is sorted I mean [19:32] we need to change the OOPSObserver setup [19:33] its participating in the loop [19:33] I am really worried this will screw over the build manager [19:33] does the build manager call setup_tacfile_logging ? [19:33] no [19:34] we probably want what the builddmanager has [19:34] to fix the separate bug that poppy log rotation is terrible [19:34] it uses Rotatable... [19:34] right [19:34] we had 50G of poppy logs or something [19:34] it was taking a while to rsync after each rotation [19:34] yeah it logs excessively anyway [19:35] so yeah, the builddmanager could be affected [19:35] but, we have and end goal that makes sense for both [19:35] application.addComponent( [19:35] RotatableFileLogObserver(options.get('logfile')), ignoreClass=1) [19:35] thats what builddmanager does [19:36] that won't give OOPS integration [19:36] it probably needs to be [19:36] application.addComponent(OOPSObserver(oops_config, RotatableFileLogObserver(options.get('logfile')), ignoreClass=1)) [19:36] and may need a tweak to the OOPSObserver to pass down the rotation event. I don't know. [19:36] simples :) [19:37] that + a logging.basicConfig(stream=stdout, level=X) [19:37] RFLO installs its own signal handler [19:37] should give us everything we need [19:37] ok I am going to experiment now [19:37] this function: set_up_oops_reporting [19:38] in loggingsupport.py [19:38] is what creates the loop [19:38] (because it turns stderr output into oopses [19:38] and writes a msg on oops [19:38] and joins twisted msg() output to python logging [19:38] well I managed to stop the loop without changing that [19:38] which is joined to stderr by default [19:38] sure, you can break it at a number of points. [19:38] and I've seen looping in poppy before your changes [19:39] here, one sec [19:44] http://pastebin.com/LV3QtjT9 [19:44] this is a sketch [19:44] we have techdebt all around [19:44] e.g. in the SSHServerService which self-configures oops reporting [19:44] rather than letting it be configured for it [19:45] you may want to add a flag to stop calling the setup rather than changing what it calls, etc etc [19:47] lifeless: yes that will affect a few things [19:48] yup [19:48] this, b-m and the branch server iirc [19:48] won't affect b-m [19:48] AFAICT from daemons/buildd-manager.tac [19:49] and manager.py [19:49] it only grabs the rotatablefileobserver from loggingsupport [19:49] sorry not b-m [19:49] we *should* change the buildd-manager to get oopses from it, but we should get poppy and the bzr service sorted first. [19:50] well this will fix the bzr server I hope [19:50] unless ... [19:50] right, once the code fallout is done :) [19:51] basically the SSHService can't do its own oops config, because its being used in cooperation with other services, but logging-glued-in oops configuration is global. [19:51] so it has to be pulled out of there. [19:51] it could have its own oops config object, for direct raising of soft reports. [19:51] but thats a totally different question. [19:53] right, separate bug [19:53] I shall fix this first [19:54] yeah [19:54] this is contained to: [19:54] - stop sshservice configuring logs or oops [19:54] - delete all the accumulated cruft around that [19:54] - return an observer with rotation which we can use anywhere [19:54] - and setup python logging to just stdout [19:54] -fin [19:56] oh, and it looks like a trivial 'delete set_up_logging_for_script' - just doing a full grep to be sure [19:57] aieee [19:57] supermirror-pull [19:58] that should be an easy fix - migrate across to the set_up_oops_reporting API and call t.python.log.startLoggingWithObserver(oops_observer)) [19:59] or move it to the end of the set_up_logging_for_script call [19:59] either will work AFIACT [20:00] bigjools: you use 'longpoll' right as the tag? [20:01] lifeless: yes [20:01] FYI https://bugs.launchpad.net/launchpad/+bug/901844 [20:01] prob need to make it official [20:01] <_mup_> Bug #901844: unreliablesession service causing oops during after-request processing < https://launchpad.net/bugs/901844 > [20:05] lifeless: so in your patch you've removed startLoggingWithObserver [20:06] right [20:06] twistd calls that itself [20:06] if the application thing that the buildd-manager uses works, it should be enough [20:07] yeah [20:07] I haven't traced through to see whats happening [20:07] I keep thinking that it won't but that's the txlongpoll stuff .... it's a TAP not a TAX [20:07] TAC [20:12] lifeless: I like your optimism of expecting "options" to be available in the tac file :) [20:12] bigjools: see buildd-manager.tac [20:13] ah different options [20:16] would someone please review my branch? https://code.launchpad.net/~james-w/launchpad/binaries-created-since/+merge/85022 [20:16] jcsackett, are you still on call? [20:17] james_w: i am. [20:17] you have something for me? [20:18] https://code.launchpad.net/~james-w/launchpad/binaries-created-since/+merge/85022 if you would be so kind [20:18] i would be happy to. [20:18] jcsackett: could you please review https://code.launchpad.net/~abentley/launchpad/batch-dealising/+merge/85023 ? [20:21] abentley: sure. it's next. [20:22] jcsackett: tia [20:23] lifeless: what happens if set_up_oops_reporting is called twice? [20:24] you'll have two signal handlers installed ? [20:24] seems like a bad idea [20:30] lifeless: fwiw, googlebot doesn't execute javascript [20:30] http://code.google.com/web/ajaxcrawling [20:30] is the convention they suggest to make ajax site indexable [20:30] lifeless: just a theoretical question. Anyway, your change has the same affect as my branch - nothing from the python log ends up in the twisted log [20:30] lifeless: and sorry for the out-of-context info :-) [20:32] flacoste: interesting [20:33] yeah, more server work [20:33] which is what we hoped to get rid of [20:34] deryck: I've pushed changes to the inline editor, appreciate your feedback on if it gets the look you were thinking of [20:36] bigjools: hmm [20:36] lifeless: this is why I have no hair left today :) [20:36] bigjools: so, I suggest you push this current experiment somewhere [20:36] bigjools: I will dig while you sleep [20:36] bigjools: and hand-back your fri morning. [20:36] bigjools: its well past your EOD now :) [20:37] james_w: is the interface addition of created_since_date to add a field on a form in the webapp? i don't see anything connecting it back, but i'm unfamiliar with the soyuz bits of the webapp and could see it just being automatically handled with that addition. just want to make sure that's the case. [20:37] lifeless: yes, I am 2 whiskies in to EOD [20:37] jcsackett, I want it for the webservice, I don't think there's really anywhere it would fit in the webapp either [20:38] jcsackett, I have an API client that needs the parameter to make it a billion times more efficient [20:38] flacoste: whats the bug # for the linaro-cannot-upload-releases bug? I can't seem to find it again.. [20:38] james_w: ah. [20:39] lifeless, https://bugs.launchpad.net/launchpad/+bug/194558 [20:39] <_mup_> Bug #194558: Project file uploads time-out but don't OOPS < https://launchpad.net/bugs/194558 > [20:39] james_w: thank you! [20:39] what james_w says :-) [20:39] bigjools: so yeah, pastebin or push to a branch, and make it my problem [20:40] bigjools: I'll get the basics hanging together properly. [20:40] lifeless: http://pastebin.ubuntu.com/764210/ [20:40] I've actually been using it on a branch where I've added extra gpg debugging to poppy [20:41] good way to test the logging :) [20:41] james_w: r=me. [20:41] abentley: looking at yours now. [20:41] jcsackett, merci [20:41] now to see if I can actually land it [20:41] bigjools: cool, I saw the MP for that branch [20:42] bigjools: btw, I don't think we should log errors for these gpg failures if its a sigfail - thats a user problem (analgous to a 404). But lets worry about that *after* we sort out germanium [20:44] lifeless: right - this is purely for debugging since we have NFI why it fails [20:44] there's a "source" debug property that'll tell us where the error originated [20:44] bigjools: ah, I don't mean your change, I mean the existing code [20:45] lifeless: the logging comes from the FTP handler in Twisted :/ [20:45] something, perhaps in twisted itself, is logging an isError [20:45] we'll want to add an oops filter to mask those from being oopses I think. eventually. [20:45] the writer handler just tells the parent class there was a failure and it does the rest [20:51] yup [20:51] flacoste: thanks for the link [20:53] abentley: just to make sure i'm reading this all right, the purpose of this branch is to avoid reloading stuff and just grab the data we've already got, right? [20:54] jcsackett: right. [20:54] abentley: awesome. [20:54] rick_h_, sorry, missed the ping somehow. looking now. [20:54] abentley: okay, given that my understanding is on the mark, this looks good to me. r=me. [20:54] jcsackett: thanks. [20:57] deryck: cool, I'm off to run around, but feel free to leave any notes and I'll check it out in the morning [20:58] rick_h_, sounds good. Have a nice evening. [21:04] deryck: I'm having trouble reproducing 900398 locally. I've set a bug to incomplete, and it still says "There are currently no open bugs." Any tips? [21:06] abentley, ah, expire able. yeah, you'll need to back date a bug and back date when it was marked incomplete, by poking at db or in console. [21:07] deryck: How old does it need to be? [21:09] abentley, hmmm, that's a good question. my impulse was >60 but not sure what the expireable view shows, since those should auto expire. [21:09] * deryck looks at some things.... [21:09] deryck: that's why I find it confusing. I thought all incomplete bugs were "expirable", and if they were >60 they'd be expired. Well, invalid. [21:10] abentley: Assigned bugs or those with multiple tasks don't expire, IIRC. [21:11] wgrant: Ah, that could be it. [21:12] abentley: I believe there are other exceptions as well. They used to be documented, but I'm not sure if it's up to date. [21:14] wgrant: hmm. I set https://bugs.launchpad.dev/ubuntu/+source/linux-source-2.6.15/+bug/10 to incomplete, and claims it will expire, but doesn't show in the list. [21:14] <_mup_> Bug #10: It says "displaying matching bugs 1 to 8 of 8", but there is 9 < https://launchpad.net/bugs/10 > [21:14] abentley, also the project has to have expiry enabled for that view to work. [21:14] abentley, and I think expiry is off by default [21:14] deryck: Yes, I made sure that was checked. [21:15] ok, hmmm. can't be a dupe, can't be assigned, can't be targeted to milestone [21:15] * deryck is thinking of every criteria [21:16] abentley, ah. and it is a config param for how old it needs to be. config.malone.days_before_expiration [21:17] abentley, and as I read the method to get the list, the bugs have to be created than that value. [21:17] s/created/greater/ [21:17] deryck: It's particularly weird, because lp says it will expire on the bug page, but doesn't list it in the listing. [21:17] Oh, so +expirablebugs or whatever it is only makes sense when expiry is disabled? [21:17] Because otherwise everything there should already have expired... [21:18] well, expiring has to be enabled for that page to have any bugs. but yeah, I agree it doesn't make sense why a bug has to be ready to expire before it shows on that page. [21:19] "An Incomplete bug can remain in this list indefinitely, so long as the bug is regularly updated." [21:19] I guess that would explain why it's a custom view, instead of searching on status=Incomplete. [21:19] That suggests it doesn't have the timeout. [21:19] wgrant: I think that means that updates reset the timeout. [21:19] But then it wouldn't be on the list. [21:19] So it wouldn't stay on the list indefinitely. [21:20] wgrant: Maybe the page doesn't know what it actually lists? [21:20] the view uses findExpirableBugs which does: Bug.date_last_updated < CURRENT_TIMESTAMP AT TIME ZONE 'UTC' - interval '%s days' [21:20] where the config value is the %s [21:20] have we finished the migration to the new ENUM as well ? [21:20] Yeah, the docs seem wrong. [21:21] That makes the view pretty useless. [21:21] indeed [21:21] deryck: do we want to fix this view or kill it? [21:21] Oh. [21:21] you can only view them on that view when they're old enough to expire but before the script has actually run :) [21:21] But findExpirableBugTasks takes min_days_old as an argument. [21:21] wtf, i get this email back from PQM: http://pastebin.ubuntu.com/764259/ [21:22] what is that supposed to mean [21:22] flacoste: Check the attachment. [21:22] flacoste: It will say the regex doesn't match. [21:22] ah! [21:22] attachments! [21:22] that must be new [21:22] wgrant: thanks! [21:22] deryck: Perhaps we should change BugTaskExpirableListingView to show everything older than 0 days? [21:23] wgrant, yeah, I think so. [21:23] abentley, ^^. Just fix it to show anything that could expire when the time comes. [21:23] I guess for years it made sense to show only the stuff that was really expirable -- because they never actually expired. [21:23] deryck: Okay. [21:23] That's my understanding of what this view is meant to show. [21:23] wgrant, heh. yeah. [21:23] wgrant: older than 0 days == everything? [21:23] why are we still still in testfix mode? [21:24] abentley: I think so. [21:24] since both lp and db_lp are building happily? [21:24] flacoste: because the last build attempt failed, and no one has landed a testfix. [21:24] flacoste: I'm not sure. It may be because the last devel build blew up really impressively, and buildbot apparently lost its memory. [21:24] abentley: That doesn't normally matter. [21:24] right [21:24] Normally as long as both are either successful or building, it's happy. [21:24] yep [21:25] But buildbot-poller probably doesn't handle results that end in an exception, I guess. [21:25] but the memory aspect might confuse buildbot-poller :-/ [21:25] or something like that [21:25] abentley, deryck: Hah [21:25] wgrant: I could have sworn I saw that behaviour yesterday when I forced a build. [21:25] That's a recent change. [21:25] 11057.8.2 [21:25] modify can_expire to use the days_before_expiration config option [21:25] expirable_bugtasks = list(bugtaskset.findExpirableBugTasks( [21:25] - 0, getUtility(ILaunchpadCelebrities).janitor)) [21:25] + config.malone.days_before_expiration, getUtility(ILaunchpadCelebrities).janitor)) [21:26] ah interesting. [21:26] wgrant: thanks. [21:27] That's a bdmurray change. I'm sure he and I talked about it, but don't recall now why we did that. [21:27] [r=leonardr][ui=none][bug=595124] unexport IBug.can_expire which is [21:27] confusing instead create and export IBug.isExpirable which can [21:27] accept a custom number of days. [21:27] It was proposed here: https://code.launchpad.net/~brian-murray/launchpad/595124/+merge/28543 [21:27] Is the landing message. [21:27] How odd. [21:27] It seems unrelated. [21:27] ui=none is rather stale [21:28] heh, I even discussed this and approved then. [21:28] well, I unapprove my approval. ;) [21:28] deryck: It made sense back then :) [21:28] It was still switched off. [21:28] deryck: lol [21:28] So it was useful for expirable-bugs to show what *would* happen. [21:29] yeah, and as it is now, we'll never actually see them. [21:30] unless the expiry script barfs. ;) [21:30] Yep. [21:30] revert revert revert [21:33] baaaah [21:33] ********************************************************************** [21:33] Can't use pdb.set_trace when running a layer as a subprocess! [21:33] ********************************************************************** [21:33] How nice. [21:35] Ah, OK, lp-buildd problem is clear now. [21:35] * wgrant fixes. [21:35] * wgrant was wrong to blame poolie :( [21:36] deryck, wgrant: thanks. Can now reproduce the issue. [21:37] wgrant: winpdb might help. [21:37] statik showed me that trick. It helped when I was debugging LP :) [21:38] glad it wasn't me [21:38] wgrant, what was it? [21:38] poolie: We added a new config option last week. [21:38] poolie: It's mandatory. [21:38] poolie: The config file is installed by python-lpbuildd, but the migrator is in launchpad-buildd. [21:38] So upgrading python-lpbuildd doesn't upgrade the config file. [21:39] ah [21:39] kind of my fault for not separating them better perhaps [21:39] Meh. [21:40] i don't know if making it mandatory but added by upgrading makes sense, but i don't know the specific [21:40] I guess I'll move it, alter the migrator to also migrate for 111 if the option isn't in the file, and release a new one. [21:40] poolie: It's how all the path configuration is done, unfortunately. [21:40] It's all pretty ancient and bad. [21:44] poolie: http://lists.linaro.org/pipermail/linaro-dev/2011-December/009059.html suggests a place where git hosting would be valuable to LP users [21:45] yep [21:46] abentley: whats the expiry policy on your ajax batch cache ? [21:46] lifeless: None. [21:46] i think the clearest case for it is as a replacement for git.kernel.c.c. and git.l.c [21:46] abentley: so users have to refresh the page to see new results? [21:46] lifeless: right. [21:47] abentley: you might like to have a bug noting this - one of the things we're trying to do long term is make LP more responsive, and having to refresh will conflict with that [21:48] lifeless: the irony is, of course, that not loading is a great way of making Launchpad more responsive. [21:49] abentley: well, its a way. I don't think it gets used much at all - e.g. see poolies data that users use 'next' very rarely. [21:50] lifeless: For users that don't use the cache, its expiry policy doesn't matter :-) [21:50] agreed [21:51] just noting that this is a side effect of the cache - part of the expected overhead of having a cache [21:51] It is a significant difference to the non-ajax behaviour where next/prev give live data. [21:52] lifeless: So if they're not using the cache, then it neither makes launchpad more responsive nor forces them to reload. [21:52] It would be nice to have the user subscribe to the bugs visible in the batch, so they can be removed from the batch live [21:53] abentley: thats true. But we know some users do use the cache. And we haven't drilled into where that usage is distributed [21:53] I forget what the percentage was [21:53] call it N. It may be that N% of users use next/prev all the time. [21:53] lifeless: Yes, I'd love to see that data by user rather than by hit. [21:55] Anyhow, I will be happy to contribute to the effort to make pages update live. [21:57] poolie: Ah, actually, the config file I had was crufty. python-lpbuildd doesn't use the system config file at all. But there's a test-specific config file in the tree which wasn't updated. [22:06] abentley: I think for now a bug noting that this is the situation is appropriate (because its not obvious to users that this will be happening) [22:06] abentley: I can file it if you like [22:06] lifeless: There's no spinner when retrieving from cache, so it should be obvious, but feel free. [22:07] abentley: folk in europe working with small batches probably won't register the spinner anyhow :) === jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 3*10^2 [22:11] abentley: bug 901892 [22:11] <_mup_> Bug #901892: bug search cache makes next/prev return old data < https://launchpad.net/bugs/901892 > [22:11] deryck: ^ FYI too [22:11] abentley: its a little entertaining to me that 7 years on we're still talking about cache implementations [22:11] :) [22:12] ack, thanks [22:14] later on, everyone. [22:17] need to run for the rest of the evening [22:17] cu later [22:19] ciao [22:35] lifeless: so - I set up launchpad translations a while back for nova, and they seem to be working, even though nova doesn't have a .pot file in the repo (since it generates one through distutils-extra) [22:36] lifeless: I was starting to try to set up the same thing for glance, but I'm not sure I did it right - who should I bug with questions? [22:37] mtaylor: if there is a CHR listed in #launchpad, start there [22:37] mtaylor: failing that, just ask there - there are folk around [22:37] ok. cool. thanks [22:38] mtaylor: failing that, open a ticket at l.n/launchpad