[00:03] thnaks [00:05] * lifeless whines about BranchCollection more [00:07] lifeless: I'm chanelling thumper, but "Fix it, dear Elisa" ? [00:08] StevenK: https://bugs.launchpad.net/launchpad/+bug/745310 [00:08] <_mup_> Bug #745310: Person:+branches timeout < https://launchpad.net/bugs/745310 > [00:08] wgrant: http://pastebin.ubuntu.com/587111/ makes me sad. It's obvious what it should be, but why was it the other ... [00:09] StevenK: blame [00:09] blame says jelmer and a 10k rev no [00:10] So it's been like that for a while ... [00:10] Oh, this is in archivepublisher, not python-debian. [00:10] Huh. [00:10] Yes [00:11] Well, the test docstring is reasonably clear.. [00:11] wgrant: I should commit that change and re-ec2? [00:11] StevenK: its overly generic [00:11] StevenK: access patterns for product scope vs person scope are not efficiently reusabke [00:12] StevenK: It was changed as part of his port to python-debian. So just fix it. [00:12] but our code structure is so heavily geared for code reuse, I suspect i need to entirely ditch the layers to fix it. [00:14] wgrant: You think ec2 or it's safe to lp-land? (That was the only failure.) [00:14] * StevenK glares at Tasque [00:15] StevenK: It's already been through ec2? lp-land. [00:15] Which just SEGV'd. Orsum. [00:16] wgrant: Yes, so doing so. [00:17] cjwatson: Your branch failed ec2. The test deb didn't have the necessary Pre-Depends (I've fixed that), but python-apt doesn't support data.tar.xz. [00:17] Or multiarch ... [00:37] huwshimi: Have you had a chance to look at my JS suggestions for your branch? [00:41] wgrant: I had a quick look at it. I will have a look again in a minute. It is certainly cleaner than what I pushed. Generally this kind of node creation is very resource expensive (hence why people often do it with strings or arrays), but I'm more than happy to merge your changes. [00:42] huwshimi: Yeah, I imagine it could be slightly more expensive. [00:42] wgrant: I'm not sure what it's like with YUI. It might be fine [00:52] wgrant: oh blasted thing [00:52] wgrant: Debian was going to work around that, IIRC [00:52] wgrant: where's the relevant code? [00:53] cjwatson: apt_inst.debExtract(deb_file, tar_checker.callback, file) [00:53] nascentuploadfile.py, around like 734 [00:53] *line [00:53] IIRC that was blocked on adding xz to python [00:53] or something joyous like that [00:54] though IIRC there was going to be a workaround with a subprocess [00:54] * cjwatson hunts down where he saw that [00:54] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=556407 [00:54] Oh, right, I remember something like this. [00:54] But it was a while ago. [00:55] debExtract not working is lame, though. [00:55] It attempts to gunzip it instead. [00:55] gzip is the default, I guess. [00:55] that really shouldn't be that desperately hard to fix. [00:55] * cjwatson goes looking [00:56] (though don't expect a solution tonight, it's late) [00:56] "Early" [00:56] Sure, thanks. [00:56] :-) [00:57] oh, should be fairly trivial [00:57] else if(strcmp(".lzma", &Chunk[strlen(Chunk)-5]) == 0) [00:57] Comp = "lzma"; [00:57] that kind of thing [00:57] Right, but what handles Comp? [00:58] * StevenK waits for devel to be repacked [00:59] ExtractTar in apt-inst, and it's just a program name [00:59] Oh, that's easy, then. [00:59] actually I think it might need a slight tweak in apt [01:00] but still, nothing especially hard [01:00] I might make mvo do it [01:00] Handy having Platform at your disposal :) [01:00] he could probably do it twice as quick and once on Sundays [01:00] Yup. [01:05] The changes to apt and python-apt will need to be backported to Lucid though, right? [01:05] Ja. [01:07] Updating python-debian to revision 186 [01:07] Text conflict in lib/debian/debian_support.py8ing stream:Estimate 11/41 [01:07] bzr fail. [01:07] lucid-cat plus ppa:launchpad, right? [01:07] But I suspect it's my fault. [01:08] cjwatson: Yeah, it will need to hit both [01:35] thumper: btw, select expressions can be used with with now in storm [01:36] oh cool [01:36] With('name', Select(..)) [or get it from a result set or whatever) === Ursinha is now known as Ursinha-afk [01:55] Damn it, db-devel, stop failing [01:56] shell_6 [test no test results failed] [42 seconds] [01:56] Wheeee [01:57] Ahh, xfvb, my old nemesis [02:06] Error 324 (net::ERR_EMPTY_RESPONSE): Unknown error on lpbuildbot :( [02:07] lifeless: For which page? [02:07] the build that died [02:07] Hm. It worked for me [02:08] >< 117 / 41 Person:+branches [02:18] lifeless: By the number of soft timeouts I presume it's real. [02:18] And a regression. [02:19] wgrant: yes, its the bug I'm bitching about [02:19] Ahh [02:19] we use the same code to query for merge proposals in one scope [02:19] and unscoped for a person [02:19] /totally/ different criteria [02:32] Project devel build #589: STILL FAILING in 5 hr 0 min: https://lpci.wedontsleep.org/job/devel/589/ [03:16] can has review https://code.launchpad.net/~lifeless/launchpad/bug-745310/+merge/55459 [04:15] lifeless: It looks good, but is it possible to check in a test that it isn't going to generate a bong query for the general case? [04:17] StevenK: if we could define the general case, perhaps [04:17] Person:+branches sounds like a good one [04:17] its a special case [04:18] the schema is not optimised for querying [04:18] lifeless: I'm just concerned that you're fixing a fix, and there is no tests to confirm it isn't noddy. [04:18] we're going to have to touch this again and again and against [04:18] StevenK: I'm not sure that it isn't noddy [04:19] lifeless: Okay, so your general plan is for you or someone to iterate over it? [04:19] StevenK: without about 100GB of data, I can't prove it one way or another [04:19] StevenK: thats what we've been doing for all timeout fixes so far; checking that query X is issued is easy, being sure that query X is what we need is hard [04:19] lifeless: r=me [04:20] in fact, I can go futher [04:20] the query here *will* be noddy, just less noddy than the one optimised for product/package scopes [04:20] StevenK: thanks [04:20] Oh, sigh [04:20] I voted on my own MP, not yours [04:21] StevenK: -lol- [04:21] StevenK: its still noddy because it unions two querie together that probably are faster done directly. [04:21] StevenK: which speaks to the heart of why I don't like (having taken my time to think about this) the 'Collection' approach. [04:22] well, this part of the implementation [04:23] I'm not ready to critique the entire thing yet, just speaking out of frustration [04:24] lifeless: Swap you: https://code.launchpad.net/~stevenk/launchpad/dsd-invalid-versions/+merge/55461 [04:24] It's a little larger than yours, so not quite a fair swap :-) [04:37] lifeless: Thank you for the review. [04:40] StevenK: which LP configs does cron.publish-ftpmaster run under? dogfood, staging, qastaging, production, ftpmaster, ftpmaster-publish, …? I need to add to those configs. [04:40] Possibly only to some. [04:40] ftpmaster and ppa [04:40] I think [04:41] jtv: lp-production-crontabs will help [04:41] Ah, of course. Thanks. [04:42] jtv: But certainly dogfood, so that will need fixing too [04:43] StevenK: BTW you mean lp-crontabs, right? [04:44] Oh, it _contains_ a dir lp-production-crontabs. [04:44] Ah no, I am fatally confused. [04:44] jtv: What do you need to add to those configs? [04:44] The stuff I added in https://code.launchpad.net/~jtv/launchpad/db-bug-55798/+merge/55174 [04:44] jtv: Only ftpmaster runs cron.publish-ftpmaster. Although dogfood *can*, we mostly maintain its config locally. [04:45] Er, ftpmaster-publish, not ftpmaster. [04:46] Then we may want to set up, configure, and maintain a pair of run-parts directories for publish-ftpmaster runs there. [04:46] jtv: Those things really don't belong in the tree :/ [04:47] That's why it's configurable. [04:47] Why is one fo them publish-distro.d, and the other finalize.d? [04:47] Better names welcome. [04:48] It's just that I couldn't bring myself to call one pre-publication.d when it runs _after_ publish-distro. [04:48] In fact I rather got the impression (also based on what you said) that that one might properly belong in the publish-distro script itself. [04:50] Also, PublishFTPMaster is terrible name, but I can't think of anything better since publish-distro is inappropriately taken. [04:50] PublishDistribution [04:50] No, too confusing until we fix publish-distro [04:51] ThePublisherOfDoomDeathAndDestruction is apt [04:51] Yes. [04:51] hahahahah, apt! [04:51] This does explain why I had such trouble coming up with good names and docstrings, I think. [04:51] StevenK: do I sense a bit of "See I am become Death, the destroyer of Windows" there? [04:52] jtv: You've a function in PublishFTPMaster to append -distscopy, but you don't seem to use it everywhere. [04:52] No, I was channeling something [04:52] wgrant: oh, thanks—I'll check [04:53] wgrant: I do see it used [04:53] jtv: But not everywhere. [04:53] True. Am fixing. [04:54] Found 1 place that neglected to use it. [04:54] jtv: Also, ARCHIVE_SUFFIXES is surely duplicating something esle. [04:55] Again, true. [04:55] pocketsuffix, I think. [04:56] Ah, no, that's different of course. [04:56] But highly similar. [05:20] Wheee. [05:21] Now buildbot is failing like Jenkins is. [05:21] Difference: True != False: memcached is live but should not be. [05:21] Ah, lucid_lp this time. [05:21] It's because the slave was killed badly when the master was restarted. [05:21] spm: Hi, lucid_lp needs a memcached massacre. [05:22] spm: Might as well bounce all the slave bits there. [05:22] Since the build has failed. [05:35] lifeless: I note you're up for QA [05:36] StevenK: Could you review lamont's buildd changelog entry? [05:36] https://code.launchpad.net/~lamont/launchpad/lp-buildd-76/+merge/55378 [05:36] Ah, thanks [05:36] Lookink [05:37] wgrant: All done. [05:37] Thanks. [05:38] lifeless/StevenK: Could one of you mentor https://code.launchpad.net/~huwshimi/launchpad/ajax-time/+merge/55257? [05:43] wgrant, re your recent post, did you ever see http://haml-lang.com/ [05:45] Huh, interesting. [05:51] Noooooo [05:51] huwshimi, ? [05:51] i don't mean the ruby bit, just the syntax [05:51] It's an interesting idea. [05:51] I'm not sure if it's good or not. [05:51] wgrant: okidoki [05:51] poolie: Oh, I've just had fun times with haml in the past [05:51] fun or 'fun'? :) [05:51] i'm not sure either [05:52] getting away from the specific syntax of xml may be good [05:52] From The Register: MySQL.com hacked via... SQL injection vuln [05:52] From the URL, I was hoping it would be a programming langauge that was a homage to Mark Hamill. [05:52] StevenK: Stones, glass houses. [05:52] :) [05:52] :-( [05:52] So I was already disappointed without trying it! [05:52] :) [05:53] (Not sure how you'd make such a language, but if people can manage to put nearly 3000 toothpicks in their beard and post the video to the internet then surely anything is possible) [05:53] poolie: Yes, non-xml templating languages are good [05:54] Actually, this sounds useful: http://www.theregister.co.uk/2011/03/30/dynatrace_ajax_firefox4_ie/ [05:54] it reminds me a bit of latte, which i used years ago [05:54] wgrant: had some network trouble earlier… I unified the ARCHIVE_SUFFIXES across two old modules that did it ad hoc (and removed it from mine which turned out not to need it any more). Did you say anything after that? [05:54] jtv: No, that was all I saw with a quick glance. [05:55] poolie: I think haml goes to far. It is actually really nice for writing HTML in, but I think it abstracts too far from HTML [05:58] Also, it says "markup haiku." Don't we normally like our formal languages to avoid the kind of linguistic ambiguity that's the whole point of haikus? [05:58] It's Ruby, what do you expect? :) [05:59] for the real 60s retro flavour suggested by the theming it ought to be all caps :) [06:01] jtv: it's poetry, so beauty is truth, truth beauty, etc. [06:02] I'll leave that to the test suite, thank you very much :) [06:02] wgrant: the entire buildbot whatsit is stabbed. have deliberately not restarted the existing builds, so you'll need to force when ready. [06:02] I'm hungry for Japanese food now. === jtv is now known as jtv-eat [06:04] spm: Both slaves are clean? [06:05] in that I shut down everything that was running. yes. afaik, we don't do any cleaning beyond that? [06:05] Well, there's non memcacheds or anything left on either slave? [06:05] if we have to, that's a pretty awesome bug given the purpose. [06:05] s/non/no/ [06:09] spm: you used to have a script for pqm [06:09] spm: that would kill /every/ process running in a chroot [06:09] spm: that would be the thing to run [06:10] sure. either way, the processes are wiped and restarted. [06:13] Thanks. [06:13] Forcing. [06:13] Hopefully for the last time. [06:17] StevenK: Hi. [06:17] wgrant: Hm? [06:18] i-528A0905 needs killing for the same reason. [06:18] It was cursed by db-devel build 503. [06:19] Project devel build #590: ABORTED in 3 hr 46 min: https://lpci.wedontsleep.org/job/devel/590/ [06:19] Thanks. [06:19] And slave killed. [06:19] Shall I request a build of devel, or something should come along soon? [06:20] Nothing will be around for at least 4 hours. [06:20] Please force. [06:20] Just devel or both it and db-devel? [06:20] wgrant: can you look at the soyuz ppa +subscribers on qastaging [06:20] qa for 741092 - I don't admin any private ppas [06:21] StevenK: I think db-devel is fine, so no need for a build there. [06:21] lifeless: We have these people called losas, who can fix that for you [06:21] StevenK: we we're also trying not to interrupt when we don't need to [06:21] StevenK: Also these people called wgrant, though. [06:21] 38 queries/external actions issued in 0.43 seconds • [06:21] wgrant: Okay, devel is waiting for Jenkins to start a build slave. [06:21] StevenK: because they have a backlog longer than ours per-head [06:21] 38 queries/external actions issued in 0.30 seconds • [06:21] StevenK: Thanks. [06:21] wgrant: nifty [06:21] lifeless: So, it is too fast. [06:21] StevenK: that's a pack of lies. we are not people, and resent being so labelled. [06:22] ohI'msorry [06:22] spm: How would you prefer to be addressed? [06:22] Demigod? [06:22] Haha [06:23] * spm tears up another of wgrant's cake IOU's. [06:27] StevenK: Could you review https://code.launchpad.net/~wgrant/launchpad/packageset-owner-preservation/+merge/55466? [06:29] wgrant: r=me [06:30] StevenK: Thanks. [06:31] * StevenK glares at patch-2208-59-0.sql, mawson and lifeless [06:32] StevenK: why? [06:32] Because it's taken seven minutes to apply so far [06:32] It might be a while. [06:32] is it doing stuff [06:32] As well as breaking the build several times :P [06:32] or is it deadlocked because you didn't shut everything down ? [06:33] Everything ought to be stopped [06:38] it has to rewrite 250MB [06:38] so it should be pretty snappy [06:38] check top, iotop, etc [06:38] mawson can not be described as snappy [06:39] It's still running UPDATE [06:40] which one [06:40] I have no idea, I'm going by ps output [06:43] select current_query from pg_stat_activity; [06:43] should give you exactly 2 rows [06:43] StevenK: speaking of qa -Revision 12689 [06:45] lifeless: There is only one UPDATE in -59 [06:45] StevenK: this will tell you if anything else is hanging around that could be blocking it [06:46] lifeless: https://pastebin.canonical.com/45423/ [06:47] StevenK: cool [06:48] So I just have to wait? [06:48] And wait. [06:48] Haha [06:53] So the BugTask.heat update is too slow for a standard rollout? [06:54] stub: This is mawson, so the data means nothing [06:54] k [06:54] * stub waits for the staging update [06:54] stub: I missed a bit, then we've had continual buildbot fail [06:54] and I mean continual [06:54] \o/ [06:55] I think four or five db-devel builds have died in various ways so far today. [06:55] stub: should we try manually, expedite rollback if needed? [06:55] stub: as in , ask for staging to be quiesced, and you pump it through slon? [06:56] If we do it manually, we need two losa interrupts (one to apply, one to rollback). If we do it with the standard update, we may need one (to rollback, if necessary) [06:57] spm: ^ up for it? [06:58] Hmm.... what I *can* do is time how long it takes to do the UPDATE on a slave. I just need to roll it back before I commit and break replication. [06:58] yes, but no. currently mid a security update on an LP service and hoping to get the u1 migrtaion actually started in the next hour before I EOD [06:59] stub: can't do that with out the new column ? [06:59] 2011-03-30 05:25:26 INFO Applying /srv/launchpad.net/codelines/trunk/database/schema/patch-2208-59-0.sql [06:59] 2011-03-30 05:58:54 DEBUG Committing changes [06:59] lifeless: begin; add column; update; rollback [06:59] 2011-03-30 05:59:00 INFO 2208-59-0 applied just now in 0.0 seconds [06:59] FAIL [07:00] so, 25 minutes [07:00] on mawson - should be ok. [07:00] The fail is the 'in 0.0 seconds' [07:01] Do we still have sparklines in Launchpad? [07:01] I doubt it [07:01] Dunno why you would get 0.0 on mawson - that code was tricky. Might be an edge case with a single db patch on unreplicated env? [07:02] We pulled sparklines [07:02] huwshimi: ...why [07:02] stub: Could be. [07:03] lifeless: I just found a bug about them and was wondering if I should kill it [07:03] lifeless: bug #383924 [07:03] <_mup_> Bug #383924: Sparklines displayed over row below in Opera < https://launchpad.net/bugs/383924 > [07:03] kill it [07:04] They were pulled temporarily in July 2009 due to a bug. [07:04] They were to be returned within two months. [07:05] wgrant: I guess no-one missed them then ;) [07:05] lifeless: https://bugs.launchpad.net/launchpad/+bugs?field.searchtext=sparkline&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_p [07:05] atch=&field.has_no_package= [07:05] lifeless: Kill them all? [07:06] bug 284400 seems like a reasonable defect [07:06] <_mup_> Bug #284400: "Package bugs" page has no indication of how numbers have changed

< https://launchpad.net/bugs/284400 > [07:06] the others seem to be implementation bugs about the sparklines we had [07:07] we might want sparklines for 284400, but I doubt it, context doesn't really fir [07:07] *fit* [07:08] huwshimi: did you end up getting the url? [07:09] lifeless: Nope. I haven't landed the first lot yet [07:09] please file a bug or something if you need server side changes whipped up for you [07:10] lifeless: It feels like getting the url from header is a big hack. I might ask around first [07:11] It is a big hack, but I don't think you have much choice. [07:11] http://stackoverflow.com/questions/4230876/re-associate-ajax-call-with-original-url-using-jquery [07:12] huwshimi: we might already set Location [07:13] though that can be legitimately different [07:13] http://forum.jquery.com/topic/jquery-ajax-response-url is relevant [07:13] 'If it was really important, you could do some voodoo with sending [07:13] along the current URL as a custom response header' [07:13] :P [07:15] lifeless: OK you win :) [07:19] lifeless: What exactly do I need to ask to be done? Is it unhelpful if I just ask for a new header? [07:19] that would be fine [07:20] you need 'a sensible url to show in the ajax timeline put in the response sent to every ajax request' [07:20] and we can probably sensibly say 'api requests on non api domains are ajax requests' [07:21] the submission url with parameters is probably sensible on all ajax requests [07:23] D: [07:24] stub: I see that you found zope.tal about as extensible as I did. === almaisan-away is now known as al-maisan [07:25] wgrant: I don't remember. I had that part of my brain removed. [07:25] Nah nah nah can't hear you... [07:26] I am glad there is precedent :) [07:31] lifeless: Would this be low priority? [07:31] It's at least High, because it's hindering performance improvements. [07:31] And it's easy. [07:32] wgrant: OK :) [07:32] huwshimi: I would say high [07:32] Huh, that monkeypatch worked, and stuff doesn't even OOPS. [07:32] Incredible. [07:32] and then suggest you bat your eyelids at wgrant :P [07:32] lifeless: That was the plan. [07:32] * wgrant declares structure obsolete. [07:33] * huwshimi bats eyelids at wgrant [07:33] * huwshimi is not sure if he's doing it right [07:37] OK people, how do I land a branch that has no bug it is addressing? "ec2: ERROR: Branch doesn't have linked bugs and doesn't have no-qa option set." [07:37] huwshimi: File a bug, or --no-qa [07:37] Add --no-qa [07:37] Or file a bug, as wgrant says [07:37] Depending on how qa-worthy it is. [07:38] if you want the ability to say 'oh fuck this broke things' [07:38] file a placeholder bug [07:38] ok maybe I'll file a bug [07:38] if you reckon it doesn't need checking on qastaging, use --no-qa [07:39] I don't really want to break things [07:39] huwshimi: breaking things is a little orthogonal :P [07:40] wow [07:40] some folk really do get confused [07:41] lifeless: Well this way I can make sure it doesn't go live if it does break things right? Or did I misunderstand? [07:41] huwshimi: it gives you another set in the process [07:41] huwshimi: the question is, will you notice something on qastaging that you wouldn't notice on your machine [07:42] lifeless: I guess probably not. [07:43] lifeless: But if that was the case then what's the point in qastaging? [07:43] huwshimi: its entirely up to you; we try hard to be able to rollthings back easily [07:43] huwshimi: many things will only show up on qastaging [07:44] huwshimi: for instance, db permissions; scaling; icing changes [07:53] buildbot seems to be happy this time. [07:53] I guess there'll be a UPS failure in the DC soon. [07:56] Who's a little ray of sunshine today. [07:56] Shh === StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews [08:05] Has the timeout been tightened again? I can no longer view my code page, it now consistently times out. [08:05] jelmer: Known regression. [08:05] Fix waiting for buildbot. [08:05] StevenK: Ah - thanks. [08:31] jtv: https://code.launchpad.net/~stub/launchpad/drop-branchrevision-id/+merge/55480 is where I got to. Unfortunately, after that patch I end up with a primary key on branchrevision that cannot be dropped because 'constraint does not exist', so I think there are some other links lurking in the schema we haven't tracked down yet. [08:32] lifeless: Are you checking other callsites before you add preloading? [08:32] wgrant: briefly yes [08:32] p-r-f is broken because ProductSet.all_active is trying to access emailaddresses. [08:32] wgrant: oh gawd [08:32] Yes. [08:34] wgrant: I didn't see that call site at all [08:34] wgrant: is it not under lib/ ? [08:34] lifeless: I bet it iterates over ProductSet. [08:34] wgrant: OTOH the +all page loads snappily now [08:35] Heh [08:35] Indeed. [08:35] uhm [08:35] products = getUtility(IProductSet) [08:35] for product in products: [08:35] i'm inclined to broaden its access [08:35] it should [08:35] bah [08:36]