[00:02] mwhudson: suggests we need a newer testtools [00:14] or newer fixtures. EDUNNO [00:19] lifeless: So, oops-amqp's AMQP usage. [00:19] lifeless: At present, if the queue doesn't exist then OOPSes will silently be dropped. [00:23] is an ec2 land based on image 522 going to work, or do i need to update onto trunk? [00:24] poolie: 522 is the latest. If ec2 says it's using that, it will work. [00:24] wallyworld: Thank you for deleting 518 [00:24] StevenK: np. i should have done it sooner [00:34] wgrant: right, it depends on correct config [00:36] wgrant: thats a standard thing in amqp - the producer cannot know what a 'right' config is, can it ? [00:36] lifeless: Right. [00:36] wgrant: we'd check this via nagios I think - send a probe oops through kindof thing [00:37] We could use the mandatory publish flag, but failure notifications are async and not even exposed by amqplib, I don't think. [01:20] Can haz review? https://code.launchpad.net/~stevenk/launchpad/rest-glob-imports/+merge/78902 [01:27] wgrant: right [01:27] wgrant: so as it stands I think its feature complete and usable [01:27] wgrant: and we can write a small respooler for datedir-repo [01:28] anyhow -> next thing [01:31] lifeless: Yep. [01:36] Arggh [01:36] https://launchpad.net/linux-kernel [01:38] Hmm, created by a Googler, apparently. [01:38] Oddity. [01:39] StevenK: Has garbo-hourly run on qastaging yet? [01:42] erm [01:42] https://code.launchpad.net/~alex-endfinger/google/unity-4.0 [01:42] I think they must be stopped. [01:43] what [01:43] hm, isn't that url already imported somewhere else? [01:43] That's lp:google. [01:43] mwhudson: linux.git vs linux-2.6.git [01:44] wgrant: ah ok [01:46] Tempting to deactivate both projects, too. [01:46] One's a dupe, and one's insane. [01:47] Ah, jelmer may be on the case as well. [01:54] We need a "cripple user until they are not doing crazy things any more" button :( [02:02] === Top 10 Durations === [02:02] 190.98s OOPS-2109ED42 Distribution:+questions [02:02] 30.57s OOPS-2109EC14 Distribution:+ppas [02:05] Heh. [02:05] Distribution:+ppas is the same thing. [02:05] I saw it show up on the OOPS reports a couple of days back, didn't think much o fit. [02:15] Bug #872086 [02:15] <_mup_> Bug #872086: Distribution:+ppas and Distribution:+questions issue unlimited queries when memo=0&direction=backwards < https://launchpad.net/bugs/872086 > [03:17] lifeless: O hai [03:27] Oh dear, G in #linode [03:27] * StevenK tries to not confuse the channels [03:30] StevenK, wgrant: I've got a devastating monster horror branch that overthrows everything the buildd-manager does. Mind if I try it out on dogfood? [03:30] Oh god it burns it burns. [03:31] We didn't have too much luck with buildds there last night. [03:31] They didn't seem to want to... well, they didn't do very much at all. [03:32] That would be… [03:32] …“bad,” right? [03:34] That's a bit insensitive. They prefer the term "dogfood". [03:36] Ah, these modern euphemisms. [03:38] The branch I'd like to test is going to be a tough one. It basically puts the entire scanning loop in read-only transactions, with a few explicit write transactions that commit immediately (rather than waiting for a response from a slave etc.) [03:39] Yeah, saw that. [03:39] Unfortunate that you have to put the transaction stuff into the model code. [03:41] Very. [03:42] I can only hope it'll be one step on the way to a good redesign. At least we'll know where the database changes are. [03:42] Yep. [03:44] Two things really annoy me about it: (1) it's now painfully hard to work out the transactional behaviour and inspect it for semantic safety, and (2) it's actually been this way all the time but it was implicit so you couldn't even see what was going on. [03:46] Yup. [03:46] I wonder if this thorough twistification was really the best solution to the performance-bottleneck problem. [03:46] Well, the problem is that it wasn't a thorough Twistedification. [03:47] True, but I probably mean it in a different respect: [03:47] it probably goes against everything the Twisted crowd believes in, but instead of making entire protocol surfaces asynchronous, [03:48] it might have been better to identify just one or two high-latency interactions where async could be made safe. [03:49] I say “might” because whether it would have helped enough depends on details I have no knowledge of. [03:49] That's how it was initially, I believe. [03:49] It was a partial asyncification that jml and bigjools replaced. [03:49] With a full asyncification. [03:49] I thought they started with the synchronous loop. [03:50] I think some downloads were async. [03:50] Some of it was, at elast. [03:50] least [03:50] But not much. [03:50] Ah, true, yes. [03:50] So maybe that approach had simply been milked dry already. [03:54] wgrant: I'm still wondering if there's a safe place we can take this code. Here's one thought: associate a different master store with each builder. [03:55] Or just give each a thread — I know GIL contention is bad but the structure we have now seems to assume that everything spends most of its time blocked anyway. [03:56] That would solve some of the issues. [04:02] I also see a comment in there: “We need to re-fetch […] as the Storm store is invalidated over transaction boundaries.” [04:02] I know SQLObject did that implicitly, but Storm just re-fetches the object if necessary, right? [04:05] jtv: I believe it will always refetch in a new transaction. [04:05] StevenK: hi? [04:06] lifeless: https://code.launchpad.net/~stevenk/launchpad/kill-set_up_tacfile_logging/+merge/78908 << crack, or am I doing something good? [04:07] StevenK: incomplete; you need to migrate not just delete [04:07] wgrant: I know I should be grateful that Twisted is here to liberate us from structured programming and transparent multitasking and bring us the awesome scalability of single-threading. But on days like this I'm just not feeling it. I'll grab some more coffee. [04:07] StevenK: what set_up_tacfile_logging does is bridge python logging to twisted.python.log logging [04:08] StevenK: I filed a bug on this last week [04:08] StevenK: I have a branch that overlaps with this too, so we'll conflict. You might want to hold off a few days [04:08] Mmm. [04:09] I think deleting it is good. [04:09] I believe it's doing more harm than good. [04:09] Causing hangs, for example. [04:09] it needs to be addressed, yes. Just deleting however will cause stderr spew [04:10] Better than what we have now. [04:10] different [04:10] still a problem. [04:10] why do you think it is causing hangs ? [04:10] I know it is. [04:11] A unicode exception (like, say, uploading a changes file with a key that's on the keyserver but not registered in LP) will cause the upload to hang. [04:11] how [04:11] Yes. [04:11] no, really. How. [04:11] I don't know. I drowned in Twisted before I could work it out. [04:11] But it seems to recurse and then melt. [04:12] python logging should be eating unicode formatting errors. [04:12] anyhow, if you have a SSCCE it should be easy to address that [04:13] utilities/start-dev-soyuz.sh; gpg --keyserver keyserver.launchpad.dev --send-key somekey; debsign -ksomekey something.changes; dput lpdev:anyything something.changes [04:16] lifeless: Yes, I did that branch due to the bug you filed [04:16] StevenK: ah, I wasn't sure as the bug wasn't linked ;) [04:17] Is now :-) [04:24] heh === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [04:57] StevenK: can you WIP that branch for now ? [04:58] Done [04:59] than ks! [05:02] anyone happen to know if we have semi-sane configs for rabbit yet? (e.g. not None etc) [05:02] in prod [05:03] lifeless: We don't. [05:05] k, so I need a review for oops 0.0.9 (lp:~lifeless/oops/fallbacks) [05:07] https://code.launchpad.net/~lifeless/python-oops/fallbacks/+merge/78911 [05:21] * StevenK looks at pofile-stats-daily and runs screaming, his eyes bleeding [05:24] StevenK: if you need help with that, I'm here for you. [05:24] Right after lunch. === jtv is now known as jtv-eat [05:25] It last ran 2 months ago [05:25] And it takes on average 10 seconds to do one POFile. [05:25] And given the query in IPOFile._countTranslations(), I'm unsurprised. [05:27] (132 rows) [05:27] Nearly there. [05:27] wgrant: For what? [05:28] StevenK: That's the number of remaining private multi-pillar bugs that aren't in known evil projects or tagged apport-crash. [05:30] wgrant: can I nab you for a small follow on review - the changes to oops to support fallbacks from oops-amqp [05:30] jamesh: ping (touching base on oops migration) [05:33] lifeless: "if the first publisher doesn't and returns None" [05:34] blah, You want english now ? [05:34] 'fraid so. [05:34] well, it is. [05:34] But it can be clearer. how about [05:34] 'if the first publisher does not publish and instead returns None' [05:35] True. [05:35] 78+ if id: [05:35] Do you want to make that explicitly "is None"? [05:35] I'm torn [05:36] I'm thinking of rewriting the docs to say 'evaluates nonzero' [05:36] You need to do one of those. [05:36] I don't think an oops id of 0 or '' is useful [05:36] do you ? [05:37] Not useful, but it's possibly also not useful to special-case them. [05:37] there is a case for 0 in a single-creator monotonic allocation scheme, but bleh. [05:37] wgrant: well, they aren't special cased at the moment [05:37] (other existing code also just tests for if report.get('id'):) [05:40] wgrant: contributors shouldn't be a wiki page [05:42] I take it that poolie's +affectingbugs fix landed, then? :) [05:42] yes [05:42] wgrant: how hard would it be to switch that to be a blat to lpqa? [05:45] lifeless: You could just change your subscription regex to exclude it :P [05:45] But it wouldn't be hard. [05:47] lpqateam seems like ... the wrong place [05:47] I am open to any place [05:48] just wiki seems wrong to me - its not actually an editable page [05:48] wgrant: so, that review. [05:48] wgrant: I presume ESHINY happened [05:50] EMAWSONNEEDSMORERAM [05:57] I've pushed up fixes around those two points [05:57] bbiab [06:18] wgrant: and my patch fix it? [06:19] poolie: Hm? [06:19] I take it that poolie's +affectingbugs fix landed, then? :) [06:19] seems to work for lifeless; that's a good sign [06:19] hm, but not when sorted, oh well [06:20] No, that shouldn't even be on qastaging yet. [06:20] lifeless complained about dev.launchpad.net/Contributions [06:20] whats wrogn with it? [06:20] I guess lifeless subscribes to the whole wiki. [06:20] oh, i see [06:20] it's through pqm but not yet deployed [06:20] ohlol [06:25] wbn to have it built in [06:29] nigelb: its an advert, not shared-editable-docs [06:32] lifeless: hehe, but its not a qareport either :) [06:32] Want to get launchpadcontributions.com? :D [06:32] sure it is; its a blamelist [06:33] :> [06:33] this is kindof an ohloh feature [06:34] not entirely [06:35] we only measure external contributors. [06:37] yes, and ? [06:37] I mean, for 'measure thing about code and contributions' - thats what ohloh have specialised in [06:38] now, I'm not saying we shouldn't do it ourselves, what with geeknet having bought ohloh (so no longer a neutral web service), but as a feature, thats the space its in [06:38] didn't jml say 'every wiki page is a prototype of a web app'? [06:38] something very close to that [06:38] however, this is already not a wiki page ;) === jtv-eat is now known as jtv === almaisan-away is now known as al-maisan [07:20] StevenK, wgrant: the dogfood builders look happy… mind if I try upgrading the codebase, merging my branch, and triggering some builds? [07:21] jtv: Go ahead. [07:21] OK [07:55] Guten morgen. [08:07] good morning [08:42] stub: seen the ongoing work on index-only scans? Exciting. Though Simon feels they're nowhere near as useful as people think. [09:18] mwhudson: I had a q for you actualy :P but now I forget what it was [09:19] lifeless: heh, well, you have a few seconds i guess :) [09:19] lifeless: i updated https://code.launchpad.net/~mwhudson/launchpad/permit_timeout_from_features-on-participation-bug-861510/+merge/78355 on the off chance it was about that [09:20] wgrant: can you review this please? https://code.launchpad.net/~julian-edwards/meta-lp-deps/add-rabbit-management/+merge/78930 [09:26] rvba: bug 872077 needs an LP task [09:26] <_mup_> Bug #872077: Import of crosstool-ng from Mercurial fails with unknown revid < https://launchpad.net/bugs/872077 > [09:26] rvba: (because it would'nt be fixed if bzr-hg fixed it and we *didn't* deploy a new bzr-hg [09:29] bigjools: Doesn't it need to be in CAT? [09:29] bigjools: apt will use the new version if it's there. [09:29] wgrant: yes, but Tom wanted this .... [09:29] lifeless: ok, thanks. [09:29] * bigjools shrugs [09:29] bigjools: Depending on rabbitmq-management is sufficient. [09:30] It won't install unless there's a matching version of rabbitmq-server. [09:30] And that's all we care about. [09:30] is it worth removing the dep on -server? [09:30] No. [09:30] doesn't make any difference :) [09:30] But there's no point versioning them unless we actually have known version constraints. [09:30] that's what I thought [09:30] Which we don't. [09:31] this is probably being used as a cheating kind of way to figure out if everything was backported to cat properly [09:32] If rabbitmq-management installs, it has been. === gmb changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: gmb | Critical bugs: 269 - 0:[irc://irc.freenode.grahambinns.com/#%23%23%23%23%23%23%23Segmentation fault (core dumped) [10:20] hey silly question but the rocketfuel scripts upgrade to a special/newer version of bzr right? [10:20] Don't think so. [10:20] G: check the PPA's it adds? [10:21] they don't [10:21] only the bzrlib that LP uses [10:22] oh so, bzrlib gets changed, as in the one in /usr/lib64/python2.7/dist-packages by any chance? [10:22] no, the buildout one [10:22] okay then [10:23] rocketfuel-setup probably adds a bzr daily PPA. [10:23] Or maybe only bzr beta. [10:23] bzr stable, even. [10:23] BZR_PPA="deb http://ppa.launchpad.net/bzr/ppa/ubuntu ${DISTRIB_CODENAME} main" [10:24] wgrant: ahhh thanks, yeah, just cehcked my sources.list [10:25] * G should get back to tackling a couple of LP bugs, but seem to run into a completely seperate issue first [10:36] gmb: Was that topic change intentional? [10:36] gmb: All of it, I mean? [10:37] soren: I think it's a reference to more than 256 crits [10:37] my observations have been each OCR has a different 'joke' to put there [10:37] G: The irc://irc.freenode.grahambinns.com/ bit? [10:37] Ok. [10:38] it nxdomain's so it's not a phishing attempt :) [10:40] soren: Hah, no. I copied and pasted; didn't realise that my IRC client was having a bad day :). [10:40] (Well, probably my proxy...) [10:41] * gmb goes to fix it. [10:41] It used to say: "| 0:[########Segmentation fault (core dumped)" [10:41] oh [10:42] gmb: It used to say: "| 0:[########Segmentation fault (core dumped)" [10:42] soren: I see "| 0:[irc://irc.freenode.grahambinns.com/#%23%23%23%23%23%23%23Segmentation fault (core dumped)" [10:42] * soren hugs topic-diff.pl [10:42] Is that correct? [10:42] No. [10:42] That's what i says now, yes. [10:43] I'd be happy to see the lame attempt at humour removed [10:44] bigjools: Ah, see, I couldn't tell it was supposed to be funny, because bip segfaulted yesterday. I thought it was an error. [10:44] * gmb removes it. [10:44] heh === gmb changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: gmb | Critical bugs: 269 [10:44] Whomsoever can be bothered to add a progress bar can add one at their leisure. [10:45] "[#-] (not to scale)" [10:45] Heh. [10:46] lol [10:46] that's funny :) [10:48] heh, someone should add that :) === al-maisan is now known as almaisan-away [11:03] Argh. Ayiiee. Test doubles don't hold up very well across transaction boundaries. [11:04] wgrant: are you going to approve that meta-lp-deps branch? [11:04] bigjools: No, I don't agree with it. [11:05] We care that rabbitmq-management installs. [11:05] Not what version it is. [11:05] wgrant: in that case, please reply to RT 48032 [11:05] Sure. [11:05] thanks [11:06] * lifeless deletes tests that test operational config. [11:07] ! [11:08] bigjools: oops-tools have tests that there is a particular summary report; the summary reports for an install are done by pointing and clicking in the admin interface, *or* by a django migration [11:08] it should be clear that the latter isn't relevant to trunk :) [11:13] bigjools: Done. [11:13] thanks === matsubara-afk is now known as matsubara [11:42] bin/test is now segfaulting ... [11:42] \o/ [11:42] I'm sorry Dave, I can't let you test that! [11:43] :) [11:55] Set up canonical.testing.layers.LibrarianLayer in 23.685 seconds. [11:55] 3 tests to go. Tomorrow's task. [11:55] *cry* [11:56] TDD is painful with LP, really painful :( [11:57] hmmm bin/test is segfaulting on oneiric and natty [11:57] * nigelb screenshots and frames. === almaisan-away is now known as al-maisan [12:09] theory: there are no new bugs, only more or less obvious duplicates [12:10] Well, that depends on the kind of bugs already filed. [12:10] If you file a bug saying - "LP sucks", everything can dup to it :P [12:10] I believe there's always edge cases and newer ways to break things. [12:16] bigjools: Do you think someone from your squad might be able to look at bug #872086 soon? [12:16] <_mup_> Bug #872086: Distribution:+ppas and Distribution:+questions issue unlimited queries when memo=0&direction=backwards < https://launchpad.net/bugs/872086 > [12:16] bigjools: It only appeared yesterday, but causes appservers to be useless for three minutes, and cronspam. [12:17] I'll schedule it [12:17] Thanks. [12:18] googlebot... awesome [12:18] Yep. [12:18] * bigjools → lunch [12:24] gmb: I've got a nice branch lined up for you :) I lie, it's not nice. (It's not that bad either.) Are you interested? https://code.launchpad.net/~allenap/launchpad/bug-stats-key-error-bug-871076/+merge/78870 [12:24] allenap: Sure. [12:25] Thanks. [13:17] adeuring: Hi, can I ask you a quick question about the code in lib/canonical/launchpad/webapp/batching.py? [13:17] rvba: sure [13:17] I know you've been working in this area lately. [13:18] adeuring: If you go to the definition of reverseSortOrder in that file, [13:18] In there there is a sub function called invert_sort_expression [13:18] yes [13:18] morning deryck [13:18] Morning, adeuring [13:18] The parameter name is 'expr' but it manipulates 'expression'. [13:19] adeuring: Maybe I'm seeing straight but why is it not a problem? :) [13:19] I'm not* seeing straight even [13:21] rvba: i think you are right: s/expression/expr/ would make the function look much more sane. but let me check a bit more... [13:21] adeuring: Thanks for looking into it, I just randomly came across that code and it looked strange ;) [13:22] rvba: yes, the code is ismply nonsense. I am a bit surprised that it worked at all... [13:22] rvba: thanks for spotting this! [13:22] I confess I was surprised too. [13:22] You're welcome. [13:24] adeuring: The only solution for this to work is that this code is never called :) [13:25] rvba: well, it is called in __init__() [13:25] Indeed. [13:27] rvba: >>> [x for x in range(2)] [13:27] [0, 1] [13:27] >>> x [13:27] 1 [13:27] so, expression is visible to the function [13:27] but that's purely accidental.. [13:27] I see, well spotted. [13:34] abentley, adeuring -- https://dev.launchpad.net/Projects/CustomBugListings [13:49] allenap: approved with some comments [13:52] gmb: when we do an expiration countdown for incomplete bugs, how does that work when say only one of the tasks is incomplete? [13:55] bigjools: I have no idea, I'm afraid. You would hope that the countdown would only appear for the bug in that context, but I don't know whether that's the case or not. [13:56] gmb: the countdown is bug-wide it seems, so ... [13:56] well let me explain [13:56] see these 2 bugs [13:56] https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/849414 [13:56] <_mup_> Bug #849414: plymouthd crashed with SIGSEGV in ply_event_loop_process_pending_events()

< https://launchpad.net/bugs/849414 > [13:56] https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/553745 [13:56] <_mup_> Bug #553745: plymouthd crashed with SIGSEGV in ply_event_loop_process_pending_events()

the former has got "expiration in 59 days" [13:56] the latter has not, despite it having 2 incomplete tasks [13:57] I don't know if this is a bug - just looking to triage something [13:57] * gmb looks [13:59] bigjools: I don't think it's a bug. See the conditions on https://help.launchpad.net/BugExpiry. [13:59] The latter has been assigned to someone (several someones) so it doesn't count for expiry. [13:59] ah ok [13:59] * gmb didn't know those conditions until just now :)( [14:00] heh, thanks for finding them, I didn't know that page was there [14:01] gmb: Thanks! [14:01] bigjools: Nor did I. There's a (find out why) link in the expiry notice, but I only spotted it the third time I looked at the bug. [14:02] hidden in plain sight [14:12] * gmb -> late lunch [14:21] deryck, adeuring: allenap presented mustache: http://mustache.github.com/ [14:21] abentley: thanks! [14:27] deryck, adeuring: They call it logic-less templates, but thankfully, they're lying; they support loops and conditionally-rendered blocks. [14:27] abentley, yeah, I thought the same thing when I saw the guy from Yahoo. [14:33] has anyone ever felt the need to check code before committing for code that might've been left around when exploring? I know that bin/lint in launchpad runs pocketlint which would detect things like pdb statements left behind by accident, but could it detect other things like behind perhaps identified with a TODO or FIXME comment? [14:35] cr3, Given the large number of those plus XXX: comments those will be spurious warnings [14:36] cr3, I think a switch is needed to support those kinds of comments so that they only warn when you want to get rid of them [14:36] sinzui: I'm thinking dedicating a particular keyword for warnings that should not be committed, so perhaps keeping XXX and only warning about TODO for example [14:36] TODO would be one I'd be interested in [14:37] I use TODO markers a lot, the bzr "todo" plugin is great [14:38] sinzui: I've often reviewed merge requests, noticed some weird code, commented on the request only to find out some code was left behind by accident. This has a long turnaround time and I wouldn't be surprised it happens regularly, so might be worth considering. [14:38] * jml accepts donations [14:38] bigjools: hm, that might be exactly what I'm looking for. thanks! [14:39] jml: :D === al-maisan is now known as almaisan-away [14:43] cr3, We see them in reviews and ask why the issue in the comment was not address. We often require a bug reported about the issue if the work is incomplete. [14:44] cr3, I think a lot of those kinds of comments are spurious, which is what I think your concern is. Lp has a lot of such comments because the issue described in the comment is not important. [14:59] hum, anybody using balsamiq in oneiric? [15:02] danilos, I was [15:02] * sinzui checks if it still works [15:03] danilos, my old 32bit installation of air + MockupsForDesktop_1_6_50.air works [15:04] jelmer: any idea why this import is failing? https://code.launchpad.net/~tillkruess/humanstxt-wp-plugin/trunk [15:05] bigjools: the repository contains invalid data, which isn't properly encoded and makes us unable to access all history [15:05] jelmer: ok thanks [15:06] sinzui, right, I guess I'll have to investigate the 32-bit installation which has changed in oneiric then === salgado is now known as salgado-lunch [15:18] so, you guys test javascript without a browser, right? how do you do that? [15:18] (and would it work for jquery code?) [15:23] deryck, abel: random thought: mustache rendering would need to use the web service object representation to be reusable, so the server-side implementation could be a web service-consuming micro-service. [15:29] abentley, thinking through that statement…. sorry was on call. [15:30] abentley, so stepping into the territory of "web service consuming micro service" from "another tempting option" makes me slightly nervous. [15:30] deryck: is just random thought. [15:30] abentley, mostly due to keeping this scoped right to deliver on time. [15:31] abentley, right. I'm fine with that as the next logical step for this. [15:44] jelmer: is there anything they can do to fix it, BTW? [15:45] bigjools: removing the invalid data from the repository, which stops the svn libraries from falling over [15:45]