[00:22] StevenK: hi [00:27] lifeless: Hello [00:30] bigjools asked me to chat with you about derivation logic [00:30] and proffer my modest assistance if needed [00:36] wgrant: are you around perchance? [01:38] james_w: hi [01:38] hi lifeless [01:39] I was wondering if there are test helprs for populating ppas already? [01:39] lifeless, SoyuzTestPublisher [01:39] it's not very pleasant though [01:39] the factory has some stuff too [01:40] I'm working on https://bugs.edge.launchpad.net/soyuz/+bug/672371 [01:40] <_mup_> Bug #672371: Archive:+packages timeouts [01:40] I want a query scaling test [01:40] but you don't want "put 200 packages in this PPA"? [01:40] so I need to put some packages (in different staes I guess) into a test ppa [01:40] and I don't care about publishing an archive at all [01:41] archive = self.factory.makeArchive(purpose=ArchivePurpose.PPA) [01:41] for i in range(3): [01:41] self.factory.makeSourcePackagePublishingHistory(archive=archive) [01:42] something like that will give you the db gunk, and not do any actual publishing or anything [01:42] sweet, giving it a spin now. [01:42] bigjools has hinted in the past that using the factory for soyuz is a bad idea, but I don't really understand why [01:43] the factory is a bit monolithing [01:43] s/ing/ic/ [01:43] I'd like to split into different fixtures [01:43] ZOMG [01:43] Difference: queries do not match: 25 != 38 [01:44] adding one package. [01:44] thanks! [01:44] np [01:44] you can obviously change statuses with that [01:44] but you might want to also add a scaling test for binary publications too [01:44] though that might affect the main PPA page rather than +packages [01:44] Its like playing whackamole with dyanmite [01:45] I think there's a makeBinaryPackagePublishingHistory or something too [01:45] as long as we plug each hole, its an upwards trend. [01:45] my first focus is unfucking +packages today [01:48] right, but as you are there a test for binaries not scaling badly on +packages is probably worth 10 minutes [01:48] james_w: the problem isn't the test [01:48] if it passes you can leave it to catch problems in the future, if it doesn't you can decide whether to fix it, or just defer [01:48] james_w: its the fix. [01:49] james_w: I appreciate the moral support, but I'm optimising this for landing, nothing else at this point. [01:49] ok [02:21] james_w: wgrant: Is there any existing class that models 'set of SourcePackageRelease objects' ? [02:21] lifeless, not that I know of, but that doesn't mean there isn't [04:01] \o/ flat query counts on +packages [04:22] whoa 6500 bugs..... O_O [04:30] heh [04:36] lifeless: Right, so I'm looking at this graphing -- looks like the changelog is easily grapable from the librarian without having to pull apart the source package to get it [04:48] whats the processing model for this [04:48] is it per-distroseriesdiff-package [04:48] or are you doing many packages at once ? [05:07] * StevenK peers at the db-devel failure [05:08] lifeless: It will be per spr [05:08] It's been a while since I've played with the librarian, so I'm trying to recall how to get content out of a LFA [05:10] StevenK: look at the merge proposal code [05:17] lifeless: How does that help? [05:25] ouch, http://www.linuxjournal.com/content/ubuntu-bug-reporting [05:31] lifeless: There isn't. [05:51] wgrant: ECONTEXT [05:51] StevenK: the merge proposal code gets the diff from the librarian in-appserver, then marks it up [05:54] lifeless: There is no SPRSet. [05:54] Or anything like it. [05:56] StevenK: What are you graphing changelogs for? [05:56] wgrant: thanks [06:05] wgrant: Find the base version between Ubuntu and Debian [06:06] Right. [06:06] So we will need to fix gina and run my script of dogfood-murder. [06:07] If we want to pull the changelogs directly from the librarian, and I think we do [06:07] well [06:07] Unless you want to be unpacking source packages. [06:07] unpacking sp's is nuts [06:07] Source unpack just to graph versioning makes me cry [06:07] putting this in the db would be better than using the librarian, unless you *know* that you'll only hit 4-5 versions on most packages. [06:08] (because the db runs in-ram, the librarian doth not) [06:08] We can't say for absolutely certainy [06:08] The DB is crazy, though, as changelogs can be many megabytes. [06:08] I imagine we should only need to look at the latest changelog. [06:09] Unless someone's been doing Bad Things. [06:09] No, I can forsee us stepping back a few revisions [06:09] Howso? [06:09] Picture foo 1.4-1 in Debian, and foo 1.4-1ubuntu8 in Ubuntu [06:10] StevenK: The 1.4-1ubuntu8 changelog will have 1.4-1 in it. [06:10] Done. [06:10] One librarian read. [06:12] wgrant: we don't need the whole cl [06:13] wgrant: just the graph pointer to the next version that has a cl prefix [06:13] lifeless: We in theory have something like that with changelog_entry. [06:13] But that relies on people using -v properly. [06:13] Which they don't. [06:15] In the normal case we should need to read one SPR's changelog from the librarian. [06:15] I think. [06:15] Is that really bad? [06:16] well [06:16] its going to be diskio most of the time [06:16] probably tolerable [06:21] nigelb: thanks for pointing that out, I've replied on it [06:21] lifeless: \o/ [06:21] Its nice to tell folks that people are working on the timeouts [06:22] OTOH it's not really nice that it was left to rot for years :) [06:23] well [06:23] I think the coding style being used was a big driver [06:23] Oh yes, certainly. [06:23] without that being identified *and changed* it wouldn't matter how much one tried, it wouldn't be fast. === almaisan-away is now known as al-maisan [07:07] test_bzrsync.py has exploded on db-devel putting us in testfix. [07:27] StevenK: Still around? [07:28] Ah, nevermind. gina is just confusing. [08:45] good morning [08:54] I can't see any particular change that would have caused the bzrsync test failure. [08:56] sweet - http://morepypy.blogspot.com/2010/11/snake-which-bites-its-tail-pypy-jitting.html [08:59] Hola [09:01] hey [09:06] Morning. [09:28] bigjools: Is there a significant penalty in not caching the build behaviour? [09:29] wgrant: given the queries it's running, I expect so yes [09:29] :( [09:29] well, take a look for yourself ... [09:29] Can we use the existing cachedproperty stuff which has proper invalidate hooks? [09:29] that's exactly what I was thinking [09:29] That was all fixed recently to not suck. [09:30] I'm going to go over it with noodles [09:30] A good plan. [09:35] wgrant: actually it's not *quite* the same as a cached property [09:36] or is it ... [09:39] bigjools: Ideally anything that changed the current job would invalidate it. [09:39] But that sounds hard. [09:39] But in the new code we probably invalidate the object lots anyway. [09:39] wgrant: see _setCurrentBuildBehavior which is for that purpose [09:40] wgrant: so my theory is that although the storm properties of self.builder are getting refreshed, the other ones are not [09:40] which makes no sense since self.builder is re-assigned [09:41] but as Sherlock Holmes said ... [09:42] I forget exactly how Storm invalidation works. [09:44] it uses pixie dust [11:12] what's up with the test failure? [12:08] Morning, all. [12:11] morning deryck [12:11] jml, I re-created the b-m problem in a test \o/ [12:11] bigjools: yay [12:11] it's utterly bizarre though [12:11] bigjools: using actual APIs or by poking the db? [12:11] re-fetching the builder object doesn't reset the behaviour [12:12] actual API === jml changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 3 of 10.11 | PQM is open | firefighting: test failure on db-devel | https:/​/​dev.launchpad.net/​ | Get the code: https:/​/​dev.launchpad.net/​Getting [12:12] jml: it's caused by another builder building the job and then when it destroys the buildqueue, the scan of the old builder goes bang === jml changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 3 of 10.11 | PQM is open | firefighting: test failure on db-devel (since Nov 9, 1612UTC) | https:/​/​dev.launchpad.net/​ | Get the code: https:/​/​dev.launchpad.net/​Getting [12:13] bigjools: interesting [12:15] bigjools: so is the problem that another builder builds the job, or that the old builder doesn't reliably handle another builder doing so? [12:16] jml: it could be one of 2 things: [12:16] 1. the job on the old builder is not getting reset properly [12:16] 2. the pseudo-cached current_build_behavior property is not getting reset on the builder object [12:17] I am highly suspicious of the latter, but now I have a test case I can work it out [12:17] bigjools: cool. [12:18] I can just switch it to a @cachedproperty since lifeless fixed that [12:26] jml: right, it's the latter. Re-assigning the builder seems to retain a private property. WTF? [12:27] wallyworld: Have you seen DecoratedResultSet? Does it not fulfill your needs? [12:28] wgrant: i haven't come across that class yet. thanks for the pointer [12:28] i'm clearly still getting across the full api [12:29] wallyworld: It's not actually in Storm core yet, AFAIK. [12:29] wallyworld: It's in the Launchpad tree somewhere. [12:29] lib/canonical/launchpad/components/decoratedresultset.py [12:30] wgrant: cool thanks. i'll take a look. it perhaps should be moved to storm i guess [12:30] Indeed. [12:33] jelmer_: bigjools: My branch has a test failure - I failed to delete the check that the ArchivePublication delegate can return a false list of builds, which should be irrelevant now that its given a complete answer rather than injecting a cheap build callback. [12:33] I've forwarded the failure from ec2 to jelmer [12:33] * lifeless goes back to sleep [12:33] (and I'm on leave tomorrow/friday) [12:35] bigjools: I'm not sure what that means [12:35] jml: me neither, I'm still debugging [12:36] bigjools: The object will just be reretrieved from Storm's cache. [12:37] I'm trying to work out if the current_build_behavior property is retained or recalculated [12:42] lifeless: Thanks, mine is still in progress [12:45] wgrant, jml: [12:45] removeSecurityProxy(getUtility(IBuilderSet)[builder.name])._current_build_behavior [12:45] [12:45] I guess storm is returning not only the cached data but the actual object I already have :/ [12:46] * bigjools plays with cache invalidation [12:46] bigjools: are you sure the thing returned by getUtility(IBuilderSet)[builder.name] is a different object? [12:46] (i.e. id(foo) != id(bar)) [12:47] * bigjools is checking [12:47] jml: it's the exact same object [12:48] even if I invalidate the cache it returns the same object [12:48] how do you invalidate the cache? [12:48] Store.of(builder).invalidate() [12:49] hmm. I wonder what that is supposed to do. [12:49] I guess storm is jsut refreshing the object it already has for performance reasons [12:49] so I should be able to fix this by invalidating that cached property [12:49] * bigjools haxors [12:49] This prevents Storm from returning the cached object without [12:49] first verifying that the object is still available in the [12:49] database. [12:50] it also re-reads the object from the db [12:50] well, it might, but that's not what the docs say [12:50] they're incomplete then [12:51] but then this is storm docs ... [12:52] right, looking at it the implementation it calls _mark_autoreload, which (at a guess) tells storm to reload column values when they are next asked for. [12:54] but there's absolutely no way storm could even know about user-maintained state [12:54] yup [12:55] but the end user has no way of knowing that storm is going to return you the same python object that it already knows about [12:55] so naive code like this will break [12:56] hmm. [12:56] now, how do I define an invalidation hook for storm [12:56] I was just asking that [12:57] self._run_hook(obj_info, "__storm_invalidated__") [12:57] that's in _mark_autoreload [12:57] bigjools: ^ [12:57] just found it :) [12:59] how did this code work at all previously? [12:59] nfi [12:59] really, nfi [13:02] I guess we're out of testfix now. [13:03] * jml pours the first bowl of wrath onto an unsuspecting code base [13:03] hurray, my test passes now [13:08] crap. apparently I have to re-authorize my ec2 app [13:10] leonardr: what does it mean when I have multiple applications with the same name & permission but different dates on https://launchpad.net/~jml/+oauth-tokens? [13:10] jml: it probably means you cleared out your .launchpadlib directory and your client forgot about the earlier token and had to create a new one [13:11] leonardr: ok, that makes sense. should Launchpad clean up old tokens? [13:11] I guess we don't know for sure they are now unused [13:11] or, different computers or what have you [13:12] jml: we've kicked around ideas, but none of them have been airtight enough to implement [13:12] once we release the code for desktop integration, the situation should improve significantly [13:12] since there will be fewer tokens [13:12] leonardr: ahh yes. [13:13] jml: I think my branch might benefit from a quick review, would you care to do the honours please? [13:13] bigjools: sure. [13:13] didrocks: hi [13:14] didrocks: I just landed a branch that removes the need to sign the CoC before uploading to a PPA [13:14] jml: hey! awesome, that will make everything so much easier! :) [13:14] didrocks: I know you don't have much time to work on quickly (unity unity unity unity), but I thought you'd like to know :) [13:15] jml: yeah, that's kind of you to hilight that :) (and you are correct about your assumption :)) [13:15] thanks a lot :) === danilo_ is now known as danilos === Ursinha-brb is now known as Ursinha [13:27] every fricking time I need to do something with datetime I need to look up the API docs [13:28] jml: perhaps you should add another module for dealing with times and dates to Python ? :-P [13:28] good idea! [13:29] but I'll add it straight to the stdlib without actually using it in live code first [13:29] because standardizing on well-tested, commonly-used code is unpythonic [13:29] ah, I see you've got experience in this area === jelmer_ is now known as jelmer [13:54] ding ding ding! [14:21] gmb, question about bug 485627, if you have a sec [14:21] <_mup_> Bug #485627: Prompt user to subscribe when marking a bug as duplicate [14:21] deryck: Shoot. [14:22] gmb, do we now *not* subscribe a user to the master bug via the duplicate? [14:24] sinzui, ping [14:24] deryck: Well, you're still showed as subscribed via dupes in the UI, but I don't think you get notification about the master bug unless you subscribe to it directly any more. [14:24] hi mars [14:24] Hi sinzui. I was hoping you could help me with an account registration question === adeuring1 is now known as adeuring [14:25] sinzui, I just created a second account, using my work address, for some work I am doing. I used the login/register link to create the account - it seems to have gone fine [14:26] gmb, ah, ok. So we have some cleanup around that then. I'm thinking of the bug from jam about not having a direct link any longer. [14:27] deryck: Yes, I think there's some cleanup needed. [14:27] sinzui, I just received a mail that says "If this was you, perhaps you've forgotten your password?", otherwise "If not, someone may be trying to impersonate you.". I have *not* received my mail with my confirmation code and/or link. [14:27] gmb, I think we should drop the subscriber from the web ui, preserve the old text about "the dupe is at LINK", and then add the new additional notice: "You are not subscribed, if you want to, go to LINK" [14:27] mars, are you saying that U SSO did not know about the other address, and Launchpad did not either, so Lp created a profile when U SSO said you logged in? [14:27] mars, okay, [14:27] sinzui, I hit "Log out" on Launchpad before doing this [14:28] mars, U SSO know a lot of email addresses. I believe it knows every email address that Lp knows via replication [14:28] deryck: That would also mean that we don't have to hit the API for subs-from-duplicates for each bug page, which would be nice. [14:28] so you did not register [14:28] gmb, would it? We would still need to show current and past subscribers from dupes, right? [14:29] sinzui, ok. I am worried, because from my perspective as a user, Launchpad just slapped me for trying to register a second account using my existing address. [14:29] gmb, or are we not sending duplicate subscribers emails at all any more? [14:29] mars, you have not talked to Lp! [14:29] deryck: OICWYM. What's a past subscriber from a dupe? Someone who was subscribed via a dupe but now isn't? [14:29] mars, as I keep saying, registration, login, and reset are U SSO. those pages and emails are not Lp [14:30] deryck: Honestly, I'm not acutally sure now. Maybe we are but we're just sending it with the "Subscribe to the master bug" footer. [14:30] sinzui, ok, but I used the green Launchpad login screens on login.launchpad.net - again, from my perspective, I have only been working with Launchpad. [14:31] mars, yes, that is why I keep send emails to fix this. You have not and when users go directly there to register with lp, they are *not* redirected to real Lp to login...the profile is not created [14:32] gmb, ok, so I think we need to find out for sure. and then do cleanup. Let's use bug 673203 to track this. [14:32] <_mup_> Bug #673203: Duplicate email sends link to +subscribe [14:32] Ok [14:33] gmb, since I'm stuck on lazr-js still, would you mind including that in your "bugs I'm working on until deryck is done" list? :) [14:35] deryck: Sure, no worries. Can you add a card for it to the bugs lane? I'll take a look once I'm done with this blasted test that I'm trying to write. [14:35] sinzui, ok. I am sorry to hear the experience has those problems, and glad to hear that you know what is happening. I was just looking for some help finding a way to register my account, not to accuse. [14:37] gmb, sure, thanks!. on the bugs backlog, or the task lane for the story? I'm not picky either way myself. [14:37] mars, visit U SSO and login as old identity, view the email address that you cannot use. logout. register with an unknown email address. [14:37] deryck: Task lane would make more sense, actually [14:37] gmb, ok will add it now [14:37] cool [14:38] * gmb -> afk to run an errand; bbiab [14:38] sinzui, ok, I'll do that. Thank you for your help. [14:57] bigjools: you know that thing with twisted xmlrpc that you had to monkey patch? [14:57] bigjools: I just landed the fix upstream [14:57] jml: \o/ [14:57] I forgot what it was patching now [14:57] the xmlrpc client [14:57] to make sure it disconnects properly [14:57] oh and hugs for fixing glob imports! [14:57] that's the badger [14:58] bigjools: ta, but I really just put the cherry on top of a cake made by others. sinzui's been working at it for months [14:58] my heroes [14:59] gmb, allenap -- checkwatches hasn't run for two days according to the errors emails. Should we be concerned? === matsubara is now known as matsubara-lunch [15:08] jml: i'm on mumble [15:18] deryck: Yeah, probably. [15:18] deryck: Can you direct me to what you're looking at? [15:19] allenap, do you get emails from script-failures? [15:20] allenap, I fwd'ed you a mail. Do you mind chasing it up with a losa? === salgado is now known as salgado-lunch [15:26] deryck: I do get them, but I mark them as read immediately! I keep them only for reference (one which I forgot I had until now). [15:27] deryck: I'll chase it down. [15:27] allenap, thanks, I appreciate it. [15:40] sinzui, you probably saw my request for a reviewing mentor for benji. Someone from Registry would be my first choice, if you or EdwinGrubbs are willing and able. Is that a possibility? [15:43] gary_poster, I will be mentoring jcsackett next week. I will ask EdwinGrubbs. He is at a conference this week [15:43] gary_poster: I can start on it after the openstack conference. [15:43] EdwinGrubbs, thank you! [15:43] and thank you sinzui [15:44] EdwinGrubbs, I just reviewed your branch. [15:44] sinzui: thanks [15:44] I'll reply to my email requesting a mentor. Thanks, I really appreciate it, EdwinGrubbs. [15:49] gary_poster, EdwinGrubbs: hurrah. thanks edwin. [15:49] :-) === matsubara-lunch is now known as matsubara === beuno is now known as beuno-lunch === salgado-lunch is now known as salgado [16:39] Yippie, build fixed! [16:39] Project devel build (207): FIXED in 3 hr 43 min: https://hudson.wedontsleep.org/job/devel/207/ === beuno-lunch is now known as beuno === elmo_ is now known as elmo === benji is now known as benji-lunch === benji-lunch is now known as benji === al-maisan is now known as almaisan-away [18:45] deryck, hi [18:46] jelmer: hi, I'm really not here, but how is it going ? [18:48] hi rockstar [18:48] deryck, how goes the lazr-js battle? [18:48] I hope you have windmill magic in your pocket [18:48] deryck, :( [18:49] It's playing in ec2 again. [18:49] flacoste: do you know? [18:50] rockstar, I think one of the issues was without fetchCSS: false used globally, yui was attempting to go offsite for CSS, this 404s, the test runner got into thread contention, and tests started failing. [18:50] deryck, ah, yeah, I just ran into that here. [18:50] deryck, I think this was a change in 2.2. [18:50] 3.2? [18:51] Yeah, that's what I meant. [18:51] (I'm tired...) [18:52] no worries :-) [18:52] rockstar, how is yui conf? Fun and useful, I hope. [18:54] deryck, very much so. I wish we could have had more people go. I went to a workshop yesterday that gave me the desire to delete most of lazr-js. [18:55] deryck, I'll be typing up a thorough report on the way home. [18:55] yeah, I would have loved to have gone. [18:56] we've learned a lot as we've gone along, but yui devs view js the crockford way. Would be nice to absorb some understanding of that more fully. [18:57] lifeless: last i saw was the tag qa-ok being applied to the bugs [19:01] deryck, funny you should say that... I'm sitting next to the Crock right now... [19:02] (He's wearing purple sneakers) [19:02] all the cool js hackers do [19:03] Well, at least the Yahoos [19:09] Chex: ping, for great justice! (question about lp-forking-server and getting testools upgraded on bzr's pqm) [19:12] flacoste: ok, so we haven't deployed it [19:12] lifeless: i don't think so [19:14] lifeless: not according to LPS [19:15] https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html doesn't show a fix [19:15] and its not in pqm [19:15] and there's no qa-ok on https://bugs.launchpad.net/soyuz/+bug/672371 [19:15] <_mup_> Bug #672371: Archive:+packages timeouts [19:19] flacoste: I promised Lynne I'd really have a day off today.... are you able to figure out where its up to and either deploy 11887 (take the faulty rev off) or get the fix 'out there' ? [19:20] lifeless: 11887? [19:20] 11888 is faulty [19:20] I started a thread on lp-dev about it [19:20] its making ppa/+packages pages timeout [19:21] lifeless: is it deployed? [19:21] yes [19:21] lifeless: ok, i'll handle this [19:22] I'm checking devel in case buildbot is currently munching on it [19:25] lifeless: do you have any scripts to prepare for a nodowntime roll-out? [19:25] flacoste: I've sent a followup mail just now. [19:26] lifeless: adding bug numbers, moving stuff to Fix released, etc.? [19:26] flacoste: none at all; I've filed bugs for the bits I think are reasonable to automate. [19:26] ok, so it's all manual for now [19:26] thanks [19:26] lifeless: enjoy your day off [19:26] thanks [19:26] the thread name is 'possible regression on bug 672371' [19:26] <_mup_> Bug #672371: Archive:+packages timeouts [19:28] jelmer: around? [19:29] flacoste: I'll forward you the test result too === flacoste changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 3 of 10.11 | PQM is open | firefighting: - | https:/​/​dev.launchpad.net/​ | Get the code: https:/​/​dev.launchpad.net/​Getting [19:55] Project devel build (208): FAILURE in 3 hr 16 min: https://hudson.wedontsleep.org/job/devel/208/ [19:55] * Launchpad Patch Queue Manager: [r=jml][ui=none][bug=671242] Ensure that the custom [19:55] _current_build_behaviour property on Builder is invalidated [19:55] when Storm invalidates the database values. Fixes the [19:55] buildd-manager so that it doesn't disable builders erroneously [19:55] due to code tracebacks. [19:55] * Launchpad Patch Queue Manager: [r=gmb][ui=none][bug=667340] Add a new 'fixverified' status mapping [19:55] for Trac external bug trackers. Maps to 'Fix Released'. [19:55] * Launchpad Patch Queue Manager: [r=mars][ui=none][bug=621090] fix content type on two JSON views [19:55] * Launchpad Patch Queue Manager: [r=mwhudson][ui=none][bug=384831, [19:55] 539496] Do not re-export anything from [19:55] lib/canonical/launchpad/interfaces/__init__.py. Explicitly [19:55] register webservice code. [19:55] * Launchpad Patch Queue Manager: [r=mars][ui=none][bug=673015] Allow people to upload to PPAs without [19:55] having previously signed the code of conduct. === matsubara is now known as matsubara-afk === Ursinha is now known as Ursinha-afk [21:03] bye, all. [21:11] thumper: ping [21:11] jml: hi [21:11] jml: I normally have the standup around now, but wallyworld doesn't seem to be here yet === Ursinha-afk is now known as Ursinha [21:11] thumper: that's ok, I need a few minutes anyway [21:14] thumper: i'm here now :-) [21:14] anyone mind if I fix the test failures in devel? === jml changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 3 of 10.11 | PQM is open | firefighting: devel failing, jml fixing | https:/​/​dev.launchpad.net/​ | Get the code: https:/​/​dev.launchpad.net/​Getting [21:14] jml: no... go ahead [21:15] abentley: around? [21:15] thumper: hi. [21:15] abentley: mumble === salgado is now known as salgado-afk [21:19] flacoste: no, I hadn't fixed the test - it was 0130 when I found that it was failing [21:20] lifeless: it's in PQM right now [21:20] flacoste: thanks [21:37] thumper: BTW, I think we should switch the build delay stats to past-six-hours rather than past-24-hours. I.e. data since last sample. [21:38] Heh. I just ran into Mikael in the Yahoo cafeteria. He says Windmill is dead. [21:38] heh [21:38] hmm [21:38] rockstar: was he a windmill author? [21:39] thumper, he was one of them. He doesn't do anything with windmill anymore. [21:39] :( :( [21:39] rockstar: what did he suggest to use? [21:39] Aaron is apparently still taking patches, but isn't maintaining it. [21:39] jml: mumble? [21:39] thumper: sure [21:39] thumper, I quote "Everything we complained about in Selenium is basically fixed now." [21:39] thumper, and YUITest now has a Selenium shim in it as well. [21:40] Although YETI was also brought up [21:44] thumper, I may as well show everyone what I've got now... [21:44] So, we currently have this pretty-overlay widget that's kinda messy but all our overlays inherit from it. It looks like this: http://people.canonical.com/~rockstar/pretty-overlay.png [21:45] In ~20 lines of plugin js and some custom CSS, I've made the standard Y.Overlay do the exact same thing. It looks like this: http://people.canonical.com/~rockstar/overlay.png [21:46] The latter loads from cold cache uncompressed 5x than the pretty overlay does completely compressed. [21:46] Er, 4-5x faster. [21:47] thumper: https://bugs.launchpad.net/launchpad-code/+bugs?field.searchtext=&orderby=-importance&field.status:list=NEW&field.status:list=INCOMPLETE_WITH_RESPONSE&field.status:list=INCOMPLETE_WITHOUT_RESPONSE&field.status:list=CONFIRMED&field.status:list=TRIAGED&field.importance:list=HIGH&field.importance:list=UNDECIDED&field.tag=recipe& [21:52] thumper: e.g. http://paste.ubuntu.com/529601/ [21:55] thumper: https://code.launchpad.net/~testtools-dev/testtools/trunk/+new-recipe [22:01] rockstar, so it sounds like you are saying, it has been two years since we started this, time for a technology refresh? [22:02] rockstar, because everything we started with has been fixed (lazr to make up for gaps in YUI core) or shaken out (windmill v selenium) [22:02] mars, no, more like "we over engineered it, and now it's time to simplify it" [22:02] rockstar, that too :) [22:02] mars, the overlay code is a good example of us not really knowing what the capabilities of YUI were. [22:03] mars, my goal is to shrink the maintenance footprint of our code. [22:03] (because we don't have a lot of resources to maintain javascript) [22:05] mars, did you see my previous statement about windmill? [22:06] rockstar, I did. It does not surprise me. [22:07] mars, yeah, he was talking about the difficulties in doing event driven stuff in python. [22:10] rockstar, I think you are right, going by what you are saying, we should have sent more people. We are new at this: we get a lot out of it compared to, say, going to PyCon. [22:11] PyCon is cool, but what you get out of the conference changes as you gain more experience with the language, tools, and community [22:11] mars, yeah, maybe. I don't think there's much interest in writing javascript on the team though. [22:12] rockstar, I was actually thinking of people from other projects, too. They use YUI too. (I'm surprised Sidnei isn't there) [22:12] Some of that might be that javascript (and YUI in particular) can be REALLY confusing. :) [22:12] mars, sidnei has new twins. I think he's tied up somewhere. [22:12] oh, yeah, I forgot. (not that I would know /anything/ about that little life change...) [22:13] rockstar: event-driven stuff in Python is easy and fun! [22:13] Python is so awesome for events [22:14] jml, not when you're tied to an existing event loop (firefox, in this instance) [22:15] rockstar: well, that's not doing event-driven code in Python, surely [22:16] rockstar: otherwise, I don't see where the difficulty is. it's easy to write code that responds to events from external systems, regardless of how they're written [22:16] jml, yeah, there's definitely some bias there. [22:17] Er, I mean in the case of saying python isn't good for event driven development. [22:19] rockstar: next time someone says that, point them to #twisted :) [22:19] rockstar, well, I'm looking forward to seeing what comes out of this. [22:19] jml, yeah, yeah. :) Basically, he was telling me what I wanted to hear (windmill is dead) so I smiled and nodded to everything else he said. [22:21] rockstar, when can the rest of us expect your trip report? :) [22:21] mars, I'm going to type it up tonight after Douglas Crockford's verbal abuse. [22:22] closing keynote? [22:23] mars, I think it's just a Bayjax meeting that coincides with the end of YUIConf. [22:34] is not an instance of [22:35] what am I missing? that seems nonsensical? [22:35] jml, instance v. class? [22:35] jml: security proxies? [22:35] mwhudson: sterling concept [22:35] * jml tries [22:36] But security proxies are meant to preserve isinstance, aren't they/ [22:36] Er, instanceof. [22:36] wgrant: not instanceof -- isn't that js? [22:36] wgrant: nope, zope has special thingummies [22:37] mwhudson: Uh, yes. Been dealing with too much Java at uni lately. [22:38] http://pastebin.ubuntu.com/529617/ – can someone please eyeball that testfix? [22:42] mwhudson: it was indeed rSP [22:42] argh, my brain is reading that as "the register that contains the stack pointer" [22:43] jml: wow, that assertIdentical looks optimistic [22:44] jml: looks fine, i was vaguely under the impression that we had an assertIsInstance that did that already? [22:44] mwhudson: we do, but trial base class [22:44] ah ok [22:44] mwhudson: I'm fixing that after I fix circular stuff :) [22:44] r=me then, if you like [22:49] mwhudson: thanks. [22:49] * jml submits [22:59] * jml waits for pqm [23:01] jml: I'm looking at the db-devel failure [23:01] thumper: thanks :) [23:01] it seems intermittant [23:01] thumper: yeah, that's my guess. I didn't get it doing a few spins locally. [23:01] I have [23:02] thumper: but I can't find the race in the code [23:02] thumper: cool. you've made more progress than me. [23:02] thumper: also, I can't see anything that's changed recently there. (but I had a pretty shallow & quick poke through the vcs log, so I probably missed something) [23:03] hmm [23:03] it seems the latest testtools is a bit tempermental [23:03] I ran a test with -D to break on failure [23:03] but it broke into the debugger on success [23:05] thumper: I don't know of anything that's changed in testtools along those lines [23:09] bigjools: hi [23:09] bigjools: don't worry about the test failure [23:09] bigjools: http://pastebin.ubuntu.com/529617/ [23:09] bigjools: I've got a fix churning in PQM right now [23:13] * jml continues to sit around, waiting for PQM to churn. === jml changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 3 of 10.11 | PQM is open | firefighting: devel failing, jml fixing; db-devel failing, thumper fixing | https:/​/​dev.launchpad.net/​ | Get the code: https:/​/​dev.launchpad.net/​Getting [23:22] jml: hi [23:23] lifeless: hello [23:23] I've pushed a big chunk of the testrepository test helpers into fixtures [23:23] and I've some matchers to push into testtools [23:23] what do you think of making testtools depend on fixtures [23:24] lifeless: I'm not exactly against it, although doesn't fixtures depend on testtools? [23:24] for its tests only [23:26] lifeless: what do you think of merging them? [23:26] the only thing that makes me hesitate is that fixtures are useful outside of tests [23:26] like we might move matchers out of testtools eventually [23:27] I can imagine the first with less stretching than it takes to imagine the second [23:28] heh [23:29] lifeless: in any case, I'm vaguely positive toward the idea, but I'd need to sleep on it [23:29] lifeless: could I persuade you to push a new release of testrepository into debian sometime soon? [23:29] thats what I'm heading towards [23:30] fixtures is in NEW [23:31] lifeless: yay [23:31] lifeless: I've made a ~testing-cabal team w/ a PPA. I want to be building dailies of stuff into that [23:31] yes [23:31] lifeless: unfortunately, I suck hard at packaging and haven't had a spare moment to actually fix them to not suck. [23:31] you might want to add that team to the recipes beta [23:31] so that I can see it :) [23:32] lifeless: you should be able to see it. launchpad-beta is in recipes beta [23:32] kk [23:32] * jml ec2 submits database-apocalypse [23:33] ah there it is [23:33] \o/ success [23:36] jml: so, we can nuke edge now ? [23:36] lifeless: you tell me :) [23:36] lifeless: you don't need edge to get at recipes [23:37] that's all I know [23:37] So all we need edge for is API scripts for the next 4.5 years :D [23:37] Alternatively we could hunt down edge API scripts using the stats which probably don't exist. [23:38] a redirect in the frontend doesn't sound like much burden [23:38] (assuming scripts will work with that) [23:38] It won't work. [23:39] At least I don't think it will. [23:39] The WADL has edge stuff hardcoded. [23:39] Unless you translate the outgoing WADL too... [23:43] or [23:44] you could just leave api.edge as is, put a redirect up for all the other subdomains and bring the edge machine(s) into the lpnet pool [23:44] True. [23:44] wallyworld: is bug 636930 now fixed in launchpad, or at least inprogress? [23:44] As well as looking for any authenticated edge API requests and severely chastising those users. [23:44] <_mup_> Bug #636930: Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo' [23:45] silly conflict :( [23:45] * jml runs ec2 land again [23:46] jml, i think my dkim branch just needs to be submitted [23:46] it may fail in ec2 [23:46] poolie: cool. [23:46] poolie: you mean upgrading lp to use bzr 2.2.1? [23:46] poolie: I was meaning to ask you [23:46] would you be so kind as to send it for me, and i'll in parallel run the tests here and see what happens [23:46] poolie: I mean, in real time in addition to my earlier askinations [23:46] poolie: will do. you'll be CCd the results of the run [23:46] 'bzr ping lp:bzr' still reports 2.2.0, so I don't think 636930 is fix released yet. [23:47] poolie: spiv: i have tried for several days to land the @%@! fix but we seem to be permanently in textfix mode :-( [23:47] ie my lp-land keeps getting rejected [23:47] poolie: conflicts [23:47] poolie: also, commit message === jml changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 3 of 10.11 | PQM is open | firefighting: db-devel failing, thumper fixing | https:/​/​dev.launchpad.net/​ | Get the code: https:/​/​dev.launchpad.net/​Getting [23:49] jml, ok, it's on my queue to fix them, test, and then i'll let you know [23:50] poolie: thanks. If I hear from you, I'll land it tomorrow [23:54] mwhudson: they won't [23:54] mwhudson: I filed a bug on foundations if you want the gory details [23:55] my current basic plan is - shrink edge as fast as we can [23:55] keep looking at how to fold the machines into the one cluster