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