[00:26] <lifeless> wgrant: no, they aren't.
[00:26] <lifeless> he was going to.
[00:26]  * wgrant blames email.
[01:54] <thumper> wgrant, StevenK: ping
[01:54] <lifeless> flacoste: when you get up
[01:54] <lifeless> https://chinstrap.canonical.com/~stub/splitit/4vs5/diff_shipit-20090810T_212109_vs_204654/
[01:54] <thumper> do either of you know where build queue entries are kept?
[01:55] <wgrant> BuildQueue, you mean?
[01:55] <lifeless> flacoste: the request response time degrades terribly as load goes on in that benchmark - we'd want it to stay flat
[01:56] <thumper> wgrant: perhaps
[01:56] <lifeless> flacoste: according to that , we'd be able to run at 30-40 concurrent users max on that config
[01:56] <wgrant> thumper: What are you looking to do, exactly?
[01:56] <thumper> wgrant: I'm chasing down some weird old buildfarmjobs
[01:56] <thumper> wgrant: there are some entries there that aren't being dispatched
[01:56] <thumper> wgrant: and I'm wondering why
[01:56] <wgrant> thumper: These aren't the same ones that don't have a specific_job?
[01:57] <thumper> wgrant: there are 15 old recipe buildfarmjob rows, 12 of those don't have a sourcepackagerecipebuild, 3 do
[01:57] <thumper> I'm wondering what happened to those 3
[01:58] <wgrant> thumper: SourcePackageRecipeBuildJob links SPRBs to Jobs. BuildQueue.job then references that Job.
[01:58] <wgrant> So there are three rows that you need to look for for each of those three builds.
[01:59] <thumper> so to go from the buildfarmjob to the buildqueue you need to go through 5 tables?
[01:59] <thumper> that sounds freaking insane
[01:59] <wgrant> The links that I just referenced are all scheduled for demolition.
[02:00] <wgrant> BuildFarmJob is going to replace all of them.
[02:00] <thumper> wgrant: so BuildFarmJob is the new goodness?
[02:00] <wgrant> thumper: That's right.
[02:01] <thumper> wgrant: and sourcepackagerecipebuild is staying?
[02:01] <wgrant> Now Translations is on it, I just need to find a free weekend and delete the rest.
[02:01] <wgrant> Right.
[02:01] <wgrant> SourcePackageRecipeBuild*Job* is dying.
[02:01] <thumper> ok
[02:02] <thumper> but builds are being dispatched through the buildjob right now?
[02:03] <wgrant> Yes.
[02:03] <thumper> but not for much longer?
[02:03] <wgrant> Correct. Soon only BuildFarmJob, PackageBuild and SourcePackageRecipeBuild will be involved.
[02:03] <thumper> ok
[02:03] <wgrant> The BuildQueue and SourcePackageRecipeBuildJob tables will vanish, and everyone will be a lot less confused.
[02:03] <thumper> and no links to the Job table at all?
[02:03] <wgrant> Once we have everything sitting well-abstracted on top of it, BuildFarmJob will probably migrate to storing most of its data in a Job.
[02:03] <thumper> cool
[02:03] <wgrant> But that's not a significant change, so hasn't been thought about too much yet.
[02:03] <thumper> thanks for the help
[02:04] <wgrant> I decided that having BFJ store things in a Job from a start would be even more confusing: it would mean having two Jobs for every build farm task during the migration period.
[02:06] <thumper> so...
[02:06] <thumper> these other three rows have no sourcepackagerecipebuildjob links
[02:06] <wgrant> You're not checking on staging, are you?
[02:06] <thumper> hence not being built?
[02:07] <thumper> I am right now
[02:07] <thumper> but I can fling the query at spm
[02:07] <wgrant> The staging restore dequeues builds. I don't know if it deletes SPRBJs too.
[02:07] <wgrant> But it definitely deletes the BuildQueues.
[02:12] <poolie> so generally speaking i feel i should add fixtures rather than add to the LaunchpadObjectFactory
[02:12] <poolie> is that true?
[02:12] <thumper> poolie: who said what about the factory?
[02:14] <thumper> poolie: can you give me an example?
[02:14] <poolie> sorry, my recollection of it is vague
[02:14] <poolie> i thought that abentley said it was quasi-deprecated?
[02:14] <poolie> or not a good pattern?
[02:14] <wgrant> Sampledata is deprecated.
[02:14] <poolie> the example is if i want a thing to establish feature rules for testing
[02:14] <wgrant> The factory is very much not.
[02:15] <thumper> wgrant: in the end, the BuildQueue rows are missing for the respective jobs
[02:15] <wgrant> thumper: Do they have SPRBJs?
[02:15] <thumper> wgrant: yes
[02:15] <thumper> wgrant: and Jobs
[02:16] <wgrant> thumper: There's nothing special about the three?
[02:16] <thumper> wgrant: not that I can fathom without actually looking :)
[02:16] <thumper> wgrant: they are from july
[02:16] <wgrant> It could just be a botched deletion, I suppose.
[02:17] <thumper> yeah, I suppose
[02:17] <wgrant> If it hasn't happened in three months...
[02:58] <james_w> are daily recipe build jobs being created?
[03:32] <poolie> https://bugs.edge.launchpad.net/launchpad/+bug/649500 is amusing
[03:33] <wgrant> I think I saw a bug about that a while ago.
[03:33] <wgrant> The issue has certainly been present forever.
[03:34] <poolie> can i have just features/browser.py, or should it be a submodule?
[03:34] <poolie> ah i see there are some precedents for a plain file
[03:34] <wgrant> Bug #640435
[03:34] <_mup_> Bug #640435: branch name conflicts with zope.ManageContent <oops> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/640435>
[03:34]  * mwhudson wtfs at poolie's bug
[03:35] <poolie> i guess it's inherited from some builtin zope thing
[03:35] <poolie> is it a cms or a framework? who can tell
[03:36] <mwhudson> ah yeah
[03:36] <wgrant> Well, the ZTK was meant to fix that duality.
[03:36] <wgrant> I think it has.
[03:37] <mwhudson> j'accuse zope.app.publisher
[03:38] <poolie> yep
[03:38] <wgrant> Er.
[03:39] <wgrant> Why do we use that?
[03:39] <rockstar> \o/
[03:39]  * rockstar conquers buildout
[03:39] <poolie> specifically BrowserSkinsVocabulary
[03:39] <wgrant> I would have thought all our needs would be in zope.publisher.
[03:39] <poolie> it doesn't seem to add anything we do want
[03:40] <wgrant> lib/canonical/launchpad/doc/zcmldirectives.txt:#        <class 'zope.app.publisher.browser.viewmeta.SimpleLaunchpadViewClass'>,
[03:40] <wgrant> WTF?
[03:40] <wgrant> I get the feeling that I don't want to look at that file.
[03:40] <mwhudson> well hehy, if we can fix a bug by dropping a dependency
[03:41] <wgrant> We still import a whole lot of stuff from it.
[03:41] <wgrant> But I'm fairly sure it was all moved to other packages ages ago.
[03:42] <wgrant> Oh look, zope.app.publisher imports them from zope.browserpage.
[03:42] <mwhudson> wgrant: certainly looks like it
[03:42] <wgrant> Hm.
[03:42] <wgrant> But we still need it for XML-RPC :(
[03:45] <mwhudson> it's probably not very hard to write a zcml directive that unregisters the offending view
[03:46] <wgrant> I'd personally prefer to see if we can stop needing IMethodPublisher, since that's our remaining dependency on zope.app.publisher. There must be a replacement...
[03:47] <mwhudson> it
[03:47] <mwhudson> seems pretty tiny
[03:47] <wgrant> It really is.
[03:48] <wgrant> Hm. Looks like z.a.p might provide the xmlrpc:view ZCML directive.
[03:48] <wgrant> So it may be harder to excise.
[03:48] <wgrant> Why is that in there, I wonder...
[03:50] <wgrant> Ah, the ZTK steering committee appears to have just not yet decided where to put it.
[03:50] <wgrant> Grar.
[03:52] <wgrant> Hmm.
[03:52] <wgrant> What happens if we just remove the zope.app.publisher ZCML inclusion?
[03:52] <wgrant> And import just the zope.app.publisher.xmlrpc
[03:52]  * wgrant tries.
[03:54] <wgrant> That seems to have worked.
[03:56] <mwhudson> i wonder if there's some way of finding all the places where we import from deprecated locations
[03:56] <wgrant> Given the recent ZTK reshuffles, that's probably most of our imports...
[03:57] <wgrant> All the xmlrpc tests are happy with my fix, and the webapp seems to work.
[03:58] <wgrant> I'm not sure how, though.
[03:58] <wgrant> Something else must be pulling in the zope.browserpage and co.
[04:18] <thumper> lifeless: got any ideas about https://bugs.edge.launchpad.net/launchpad-code/+bug/537116 ? I don't know where to start looking.
[04:18] <_mup_> Bug #537116: bzr branch from launchpad disconnected after exactly one hour <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/537116>
[04:24] <lifeless> thumper: his firewall perhaps ?
[04:24]  * lifeless shoots first, asks questions later
[04:24] <lifeless> we could try and reproduce
[04:25] <lifeless> I suspect something at his end though, because e.g. pulls of LP can be an hour and work
[04:42] <poolie> there's no timeout on our end?
[04:43] <poolie> it's plausible it's his firewall
[04:43] <poolie> a bit strange if it kills an actually active socket though
[04:44] <lifeless> spm: do we have anything that would kill a bzr serve process / ssh connection after 1 hour ?
[04:44] <spm> I can think of several possibilities, but don't *know* which is likely.
[04:45] <spm> i'd be asking for a snoop that shows the termination. that may be a clue.
[04:45] <mwhudson> we have code in launchpad that's supposed to kill _idle_ connections after an houe
[04:45] <mwhudson> *hour
[04:45] <poolie> as far as whether it's killed by a reset or socket close
[04:46] <poolie> mwhudson: where is that code?
[04:46] <mwhudson> poolie: not sure now since jml shuffled this area
[04:46]  * mwhudson pokes
[04:46] <poolie> if it was an econnreset it would be more likely to be a router intervention, i think
[04:46] <poolie> but it's just an early eof, which could be anything
[04:47] <poolie> perhaps is slightly more likely to be app code than networking
[04:47] <mwhudson> poolie: lp.services.sshserver.service
[04:47] <mwhudson> poolie: line 150-ish
[04:49] <mwhudson> oh right
[04:49] <mwhudson> well he's definitely being cut off by the idle_timeout
[04:49] <mwhudson> but what's happening is that the branching runs for an hour
 poolie: line 150-ish <== was that from memory? or did you look it up? ;-)
[04:49] <mwhudson> then the connection goes idle
[04:49] <mwhudson> then an hour after that he's disconnected
[04:49] <mwhudson> spm: i looked it up :-)
[04:50] <spm> :-)
[04:50] <mwhudson> poolie: there is also a bug in conch's ssh key renegotiation
[04:50] <mwhudson> that usually kicks in after a gigabyte of traffic
[04:50] <mwhudson> he doesn't seem to be close to that though
[04:52] <poolie> aside from anything else we should upgrade the origin branch
[04:56] <poolie> well, it would be an incredible coincidence for that to happen after an hour
[04:57] <poolie> but perhaps there's a time-based renegotiation too?
[04:57] <poolie> do you have a bug number for that?
[04:58] <spm> it wouldn't be some reverse speed of light problem maybe? http://www.ibiblio.org/harris/500milemail.html
[04:59] <mwhudson> poolie: yes, but i can't find it
[05:03] <thumper> poolie: I'm contacting the project owner
[05:03] <thumper> web2py owner that is
[05:07] <poolie> spm if we have users more than one light-hour away, uh..
[05:07] <poolie> i'll be impressed
[05:07] <spm> you never know......
[05:08] <poolie> about 1e9 km
[05:09] <lifeless> tcp over spaceship would be painful
[05:09] <lifeless> talk about slow start
[05:10] <spm> lifeless: you've not seen that rfc? it's an update on 1149
[05:10] <lifeless> carrier pigeon?
[05:10] <mwhudson> http://twitter.com/#!/colmmacuait/status/25352220323
[05:11] <poolie> nice
[05:11] <spm> lifeless: indeed
[05:11] <spm> bwhahaha
[05:11] <poolie> so in a bit of poking around i can't see anything in conch to do with automatically renegotiating keys, based on either traffic or time
[05:11] <poolie> it may well be there but i don't see it
[05:11] <mwhudson> poolie: it's client side
[05:12] <nigelb> spm: heh, that was a good one about 500 miles
[05:13] <spm> nigelb: *very* old favourite. The Story Of Mel, is another
[05:13] <nigelb> spm: Story of Mel?
[05:13] <spm> http://www.pbm.com/~lindahl/mel.html
[05:14] <poolie> mwhudson: and not implemented by conch as a client?
[05:14] <mwhudson> poolie: probably not
[05:14] <poolie> mwhudson: but ok, i can see how openssh might ask  for a new key after a few gb and then that could cause trouble with the server
[05:14] <poolie> but that's almost certainly not what we're seeing here
[05:14] <mwhudson> this is infuriating, i spent quite a while looking at this and writing it up and now i can't find it
[05:14] <mwhudson> poolie: right
[05:14] <poolie> mwhudson: i'm trying to branch from there
[05:15] <mwhudson> poolie: i think openssh's default is 1 gig
[05:15] <mwhudson> you can change it
[05:15] <poolie> my connection is faster so it may just complete
[05:15] <poolie> says "depending on the cypher 1-4GB"
[05:16] <poolie> spm I watched "Colossus: The Forbin Project" last night
[05:16] <poolie> had to bite my tongue a lot
[05:16] <poolie> "ffs it never works first time"
[05:18] <spm> poolie: I've never heard of that one! I shall have to chase!
[05:18] <poolie> visually beautiful
[07:38] <stub> lifeless: https://bugs.launchpad.net/bugs/637507 if you haven't seen it. I don't understand the low level stuff or the risks, but sounds like something we might want to do across the board.
[07:38] <_mup_> Bug #637507: Uploads with extra data in the .tar.gz rejected unnecessarily <boobytrap> <soyuz-upload> <Soyuz:Triaged by jelmer> <https://launchpad.net/bugs/637507>
[07:38] <lifeless> stub: hey
[07:38] <lifeless> stub: see the cassandra mail?
[07:39] <lifeless> stub: sigpipe handling; yes, it should really be reset by subprocess automatically.
[07:39] <stub> lifeless: yes, and pfibiger pinged me this morning.
[07:40] <lifeless> stub: a wrapper for it would be useful
[07:40] <stub> lifeless: I have to think about the timing for the cassandra - my lease on a new house starts the same day.
[07:41] <lifeless> meep
[07:41] <stub> lifeless: knowing the location would be helpful - short haul might be ok
[07:41] <lifeless> us I believe
[07:41] <stub> lifeless: I was told 'up to mariana'
[07:41] <lifeless> ah, interesting
[07:42] <stub> u1 is us centric though, so probably dullas again
[07:42] <lifeless> would taipei count as short haul ?
[07:42] <stub> yes
[07:42] <stub> I suggested Taipei. 'We should all get to Taipei' I recall from a keynote.
[07:43] <stub> Only problem with Taipei is I would want to take a holiday there and I can't ;)
[07:43] <lifeless> heh
[08:24] <wgrant> Why is Dallas so popular?
[08:31] <lifeless> cheap, reasonably central
[08:31] <lifeless> (I guess, I have no knowledge)
[08:33] <lifeless> wgrant: hey, do you happen to know the name of the signal raised in +filebug w/apport ?
[08:33] <wgrant> lifeless: Signal?
[08:42] <lifeless> event
[08:42] <lifeless> thingy dookhicky
[08:42] <wgrant> lifeless: To do what?
[08:42] <wgrant> I don't know of a special event.
[08:53] <adeuring> good morning
[08:57] <michaelh1> Hi there.  I've started getting 'Errors in work item definitions' from 'Launchpad work item tracker <noreply@launchpad.net>'
[08:57] <michaelh1> emails.  How can I stop them?
[08:57] <lifeless> michaelh1: thats not an lp service, for all that its using the launchpad.net domain
[08:58] <lifeless> last i heard Martin Pitt was running it
[08:58] <lifeless> bigjools: hi; CPing your thing ?
[08:58] <lifeless> [thats code for 'had a good weekend?']
[08:58] <michaelh1> Right, I'll track pitti down...
[09:00] <bigjools> moin
[09:03] <lifeless> wgrant: this is what I was meaning
[09:03] <lifeless> http://pastebin.com/SHStVhUv
[09:04] <lifeless> though, that may not be enough
[09:04] <lifeless> I think I need to get a profile
[09:04] <lifeless> (can apport be pointed at staging?)
[09:05] <poolie> do i need an __all__ even in tests?
[09:06] <StevenK> poolie: Only if they export something
[09:07] <poolie> thanks
[09:10] <mrevell> Mornin'
[09:10] <poolie> hi there
[09:14] <wgrant> lifeless: APPORT_STAGING=1 ubuntu-bug linux
[09:14] <wgrant> IIRC
[09:16] <lifeless> the main reason we need __all__ is the import fascist requires that imports be in it
[09:16] <lifeless> this is a bit silly
[09:16] <lifeless> because you can do module._thing
[09:16] <poolie> you mean it doesn't really guard against using private interfaces?
[09:17] <lifeless> right
[09:17] <lifeless> it doesn't seem to have any functional benefit
[09:18] <wgrant> I think it's a handy check.
[09:18] <wgrant> If it works.
[09:18] <wgrant> But I don't think it does.
[09:18] <wgrant> it hasn't whinged at me much lately.
[09:18] <wgrant> Not being very fascist at all.
[09:18] <lifeless> I question the value now that security is on the model
[09:19] <lifeless> s/ now/ particularly now/
[09:19] <wgrant> It makes some attempts at preserving layering.
[09:20] <poolie> assuming people actually respond by changing the layering, not just updating the paperwork
[09:21] <lifeless> wgrant: with the assumption that the layering is useful; the primary differences between view and model code are:
[09:21] <lifeless>  - some model code is db backed
[09:21] <lifeless>  - model code wasn't allowed to cache for a while
[09:21] <lifeless>  - model classes get interfaces (high overhead) and security (useful where it matters)
[09:22] <poolie> re bug 646563, is it really true that login(something); getUserBrowser() doesn't give you a browser as that user?
[09:22] <_mup_> Bug #646563: want a way to make a TestBrowser logged in as a particular user <testing> <Launchpad Foundations:New> <https://launchpad.net/bugs/646563>
[09:22] <lifeless> the first item is a performance problem, the second isn't relevant anymore and the third adds a good 15+ percent to the code base, but *mostly* is just boilerplate.
[09:22] <jml> let's not forget that the import fascist also prevents us from using storm sorting in view code
[09:22] <lifeless> jml: yes, an import 'benefit', that one.
[09:23] <lifeless> jml: if you wanted to remove it, I'd be fine with that.
[09:23] <jml> lifeless: landscape has an importguardian that's, well, better
[09:23] <lifeless> jml: I remain fundamentally unconvinced that this is appropriate for python, at all.
[09:23] <jml> lifeless: last time I tried this, I went to split that out into lazr.importguardian, but got blocked on new lazr packages being very hard to make
[09:23] <lifeless> poolie: yes, its true.
[09:24] <lifeless> jml: why shouldn't we just remove it?
[09:24] <wgrant> What does the guardian do?
[09:24] <jml> lifeless: don't know, basically
[09:25] <jml> wgrant: I can't remember the details beyond "like the fascist, but nicer; let's you import for sorting"
[09:25] <wgrant> Why were they both created in the first place?
[09:25] <jml> ahh, now _that_ is a historical question
[09:25] <jml> so the answer is clearly "for historical reasons"
[09:25] <wgrant> Heh.
[09:25] <poolie> i have code to add getUserBrowserAsTeamMember in https://code.edge.launchpad.net/~mbp/launchpad/flags-gui/+merge/36415
[09:26] <poolie> i might just move that to BrowserTestCase as part of this same mp?
[09:26] <wgrant> poolie: Is that really worth its own method?
[09:26] <jml> I suspect it was to stop programmers from doing bad things like circumventing the interface/security code
[09:26] <poolie> wgrant: how would you write a test that needs a logged in user?
[09:26] <wgrant> (as opposed to getUserBrowser(getTeamMember(blah)))
[09:26] <lifeless> frankly, that sort of thing, unless there is a really big win, just annoys me
[09:27] <lifeless> poolie:
[09:27] <poolie> wgrant: that doesn't seem to work
[09:27] <jml> lifeless: well, yes :)
[09:27] <lifeless> user = self.factory.makePerson(password='test')
[09:27] <lifeless> browser = self.getUserBrowser(user=user)
[09:27] <poolie> right, then add them to those teams
[09:27] <poolie> it's only 5 lines but assuming it doesn't exist already, it seems reusable
[09:27] <lifeless> I think its a bit of a kludge
[09:28] <lifeless> how about this
[09:28] <lifeless> getUserBrowser(user=user) resets the users password if its wrong
[09:28] <lifeless> or
[09:28] <lifeless> how about we make the default password in makePerson be 'test'
[09:28] <lifeless> uhm
[09:28] <lifeless> I'm not against a convenience helper gluing stuff together
[09:28] <jml> anyway, I must ablute. back later.
[09:28] <poolie> mm, or i could add a teams=None parameter to getUserBrowser
[09:28] <lifeless> I think I'm mainly reacting to the fact that one is needed here.
[09:29] <lifeless> poolie: I don't understand why team membership and browser instance creation are coupled.
[09:29] <lifeless> they seem like vastly different concerns.
[09:29] <lifeless> if you did this:
[09:29] <poolie> getUserBrowser creates a new person
[09:29] <lifeless>  - change makePerson to use 'test' as the default password
[09:30] <lifeless> then you can do the following:
[09:31] <lifeless> then gUB will 'just work'
[09:31] <lifeless> and if you want a team relationship you can make that and pass in a user (and again it will just work)
[09:32] <poolie> i'm reluctant to change something called by so many tests as makePerson
[09:33] <lifeless> and yet that is what makes it valuable to change
[09:33] <lifeless> losa ping; I'd like to request profiling on staging please
[09:34] <mthaddon> lifeless: is it urgent - working on something just at the moment
[09:35] <lifeless> mthaddon: I can't claim urgent, but its 2130 for me, if I can get this before I head to sleep I may be able to confirm/deny a theory for the +filebug timeouts.
[09:35] <lifeless> and kick it over to deryck for further examination
[09:36] <mthaddon> can you file an RT and I'll get to it a little bit later on (if you can include the info that's needed to hand over to deryck)?
[09:36] <poolie> another option would be to stash the unhashed password on the object
[09:36] <lifeless> mthaddon: no, the info is me analysing kcachegrind
[09:36] <lifeless> mthaddon: which is what the profile would give me; if you get a timeslice ping me
[09:37] <lifeless> mthaddon: if you don't ping, thats fine, I'll do with someone tomorrow morning.
[09:37] <mthaddon> lifeless: k, will do - how long of a timeslice would you need?
[09:37] <wgrant> lifeless: Do we not have a URL trigger for that yet?
[09:37] <lifeless> mthaddon: you edit one config file and restart the appserver; I go play until I have the data; then you revert the config file and restart, and trigger your rsync that copies the profile files to sodium.
[09:38] <lifeless> wgrant: we do, but because its not secured it requires a config change to enable it.
[09:38] <wgrant> lifeless: ... ah. Useful.
[09:38] <lifeless> wgrant: next step is a featureflag to enable it, and a group scoped to 'launchpad'
[09:40] <lifeless> sorry, a scope, which looks up the ~launchpad group.
[09:41] <lifeless> mthaddon: http://pastebin.com/yTp0TL1D is the change; I'm sure this is in LOSA docs already
[10:08] <mthaddon> lifeless: diff applied and staging restarted
[10:11] <lifeless> thank you
[10:13] <lifeless> mthaddon: thanks; revert it anytime you like; and please kick off the rsync of the profiles (AFAIK its not cronned; maybe it is but just very infrequent)
[10:13] <lifeless> mthaddon: no rush
[10:23] <poolie> lifeless: realize it's dead late but if you sometime want to do a meta-review on https://code.edge.launchpad.net/~mbp/launchpad/flags-gui/+merge/36415
[10:23] <poolie> that could be good
[10:23] <poolie> especially as to whether the ui is adequate to start with
[10:25] <poolie> we could do that thursday
[10:33] <lifeless> poolie: it sounds fine to me
[10:33] <poolie> mthaddon: when things are not on fire, perhaps you would like to comment on the devops-usability of that mp
[10:33] <poolie> s//of the feature proposed in that mp
[10:33] <poolie> thansk
[10:33] <poolie> i'm a bit impatient to get it done
[10:33] <lifeless> poolie: its better than sql, so I'd just land it
[10:33] <poolie> yeah :)
[10:33] <poolie> i appreciate the reviews though
[10:48] <lifeless> bigjools: so, are you going to CP 11566 and 11579 (IIRC) today?
[10:48] <bigjools> lifeless: jelmer is preparing a CP, yes
[10:49] <bigjools> not sure of the revnos
[10:51] <lifeless> great
[10:51] <lifeless> we noted that one of the bugs is not qa'd
[10:51] <bigjools> which?
[10:51] <lifeless> bug 128259
[10:51] <_mup_> Bug #128259: Buildmaster should not call "uploader" script for processing incoming binaries <buildd-manager> <qa-needstesting> <soyuz-build> <Soyuz:Fix Committed by jelmer> <https://launchpad.net/bugs/128259>
[10:52]  * bigjools f ixes that
[10:55] <bigjools> pylint blows
[10:56] <jml> yes
[10:57]  * bigjools considers fixing the lint make target
[10:57] <jml> if I cared a little bit more, I'd write a Python formatting checker/fixer that was as fast as pyflakes
[10:57] <bigjools> it really hates our new import style
[10:57] <jml> and then nuke pylint with great nuking
[10:58] <bigjools> we should just get rid of pylint
[10:58] <bigjools> it's worse than useless
[10:58] <jml> no arguments here.
[10:59] <jml> the reason I want a formatting checker/fixer is I'm sick of thinking about formatting.
[10:59] <jml> but that doesn't block removing pylint
[10:59]  * bigjools blinks
[11:00] <bigjools> urgh, a shell script
[11:36] <jml> I'm closing my mail & IRC clients for a bit to get some work done. Call my phone if you need me.
[12:03] <deryck> Morning, all.
[12:29] <wgrant> bigjools: The publisher will no longer die if there's an unconfigured series, will it?
[12:29] <bigjools> wgrant: no idea
[12:30] <wgrant> Yeah, it looks like it was fixed a couple of months ago.
[12:31] <wgrant> (#ubuntu-devel just mentioned that they couldn't target specs to natty yet)
[12:40] <jelmer> wgrant: That was one of the booby trap issues I fixed last release IIRC
[12:40] <jelmer> bug 55288
[12:40] <_mup_> Bug #55288: publisher gets very unhappy about unknown distroreleases <boobytrap> <oops> <qa-ok> <soyuz-publisher> <Soyuz:Fix Released by jelmer> <https://launchpad.net/bugs/55288>
[12:41] <bigjools> \o/
[12:41] <wgrant> That's the one.
[12:42] <wgrant> Also, I hate ISPs.
[12:42] <wgrant> My international routing has just collapsed for the fourth time this evening.
[12:42] <wgrant> 70% packet loss FTW.
[14:01] <stub> gmb: https://code.edge.launchpad.net/~shttps://code.edge.launchpad.net/~stub/launchpad/trivial/+merge/36853
[14:04] <gmb> stub: I'll take a look now, thanks.
[14:04] <gmb> stub: s/rouge/rogue in your commit message :)
[14:06] <stub> blah. twiddled in the web.
[14:10] <gmb> stub: r=me
[14:33] <adeuring> Hi deryck, could you please run this query on staging: https://pastebin.canonical.com/37772/ (or an EXPLAIN ANALYZE)?
[14:33] <deryck> Hi adeuring.  Sure.
[14:37] <deryck> adeuring, so you want the explain analyze mostly?  Or just need the query run?
[14:38] <adeuring> deryck: I think the EXPLAIN ANALYZE is more interesting :)
[14:38] <deryck> ok
[14:39] <bigjools> I am so utterly frustrated with the slow test suite
[14:40] <deryck> adeuring, http://pastebin.ubuntu.com/502120/
[14:40] <adeuring> deryck: thanks!
[14:40] <deryck> bigjools, I feel you.  Combined with fails in ec2 and buildbot and it takes *for* *freakin* *ever* to land anything.
[14:40] <adeuring> so, fast enough :)
[14:41] <deryck> adeuring, well, for now.
[14:41] <bigjools> deryck: stop feeling me :)
[14:41] <deryck> heh
[14:41] <bigjools> deryck: yeah, we have to do something.  I will bring it up in tomorrow's call.
[14:41] <adeuring> deryck: yes, but the old query needed 177 seconds or so
[14:41] <deryck> adeuring, ah, yes.  So that's much better.
[14:41] <adeuring> erm, 17 seconds...
[14:42] <deryck> bigjools, thanks for bringing it up.  I agree.  We can't keep putting it off.  Something has to be done.
[14:42] <bigjools> quick someone, do Something!
[14:43] <bigjools> deryck: I have an idea but we can discuss tomorrow
[14:43] <deryck> excellent.
[14:48] <jml> mrevell: https://bugs.launchpad.net/bugs/649764
[14:48] <_mup_> Bug #649764: Getting started documentation is not very searchable <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/649764>
[15:15] <bac> hi mars, did you ever get your clean install of maverick and did you see the authentication window when running windmill tests?
[15:16] <mars> bac, I got my maverick install running, I have not tried the tests
[15:16] <bac> mars: ok, i'm curious to see what you find when you run them.
[15:17] <mars> is the Tomboy notes indicator applet messed up for anyone else?
[15:17] <mars> it is showing a bunch of blank separator lines
[15:32] <mars> maxb, can we call the new PPA "graveyard"? :)
[15:32] <maxb> heh
[15:33] <maxb> Is production still PostgreSQL 8.3 at this point?
[15:34] <mars> I'll check
[15:35] <cr3> leonardr: hi there, I'm getting "TypeError: Could not serialize object <object> to JSON", is there a practical way to debug that?
[15:37] <mars> mthaddon, what version of Postgres are we running right now?  I can't dig up the wiki page for it :(
[15:38] <mars> maxb, I'm +1 on the PPA idea, but I do not have the rights to create it
[15:41] <maxb> No rush, we can wait for consensus and then get one of the (rather few) team admins to do it
[15:44] <leonardr> cr3: is this when you invoke a named operation? if so, what does your python method return?
[15:45] <bigjools> hmmm, when running the test suite locally, the windmill tests pop up a browser that seems to stall on some sort of auth dialog
[15:45] <cr3> leonardr: this is in my own code, not launchpad, and yes, this is when I invoke a named method called createTestRun which returns an object which implements ITestRun
[15:46] <mars> bigjools, yes, a known problem on Maverick
[15:46] <bigjools> mars: ah ok
[15:46] <mars> bigjools, I can look at it now that I am actually running said distro :)
[15:46] <cr3> leonardr: aha, when calling simplejson.dumps(test_run, cls=ResourceJSONEncoder), I get: TypeError: can't compare offset-naive and offset-aware datetimes
[15:46] <bigjools> it's amazing how much of our stuff breaks with each new Ubuntu release :(
[15:46] <cr3> leonardr: I seem to be getting somewhere :)
[15:48] <leonardr> cr3: good, that's what i was going to suggest
[15:48] <leonardr> 'couldn't serialize' is masking some other error
[15:57] <mars> bac, bigjools, bug 649886
[15:57] <_mup_> Bug #649886: Windmill tests throw login window popups on Maverick <build-infrastructure> <Launchpad Foundations:New> <https://launchpad.net/bugs/649886>
[15:57] <bigjools> mars: cool thanks
[15:57] <bac> thanks mars
[15:57] <mars> close to bug 650,000
[15:57] <_mup_> Bug #650: broken package dependency's (i think :S still learning) <acroread (Ubuntu):Invalid> <https://launchpad.net/bugs/650>
[15:58] <bigjools> lifeless: when you're awake, I'm interested to understand why you're importing stuff from the soyuz module into the bugs module in one of your changes.  It causes circular imports in the test runner unless it's invoked with -t
[16:00] <cr3> leonardr: oddly, running simplejson.dumps(test_run, cls=ResourceJSONEncoder) the first time returns a typeerror but running the second time works fine :(
[16:01] <leonardr> cr3, let me see your test code?
[16:01] <leonardr> check to see if the dump process modifies any of the attributes of your object
[16:01] <bigjools> deryck: hi, got a sec?
[16:02] <deryck> bigjools, getting on call.
[16:02] <bigjools> deryck: np, it can wait
[16:08] <cr3> leonardr: argh, found the problem: setting a DateTime(allow_none=True) column to datetime.now(pytz.UTC) isn't the same as setting it to UTC_NOW :(
[16:10] <leonardr> cr3: different things get set in the database?
[16:11] <cr3> leonardr: not sure, let me have a look
[16:16] <cr3> leonardr: looks like the same thing is landing in the database, the only perceptible difference is that the datetime object contains a timezone when set explicitly in now()  but not when retrieved from the database
[16:16] <leonardr> cr3: is the object with the timezone being stored in memory and reused later? the problem is being caused by mixing them
[16:16] <leonardr> or are you comparing the datetime object from the database to datetime.now?
[16:18] <cr3> leonardr: I'm not sure where the datetimes are being compared, not in my code for sure. it seems to be either by storm or lazr
[16:19] <deryck> bigjools, hi.  I can chat now if you still need.
[16:19] <bigjools> deryck: I'm otp now :)
[16:20] <deryck> heh
[16:20] <deryck> ok, we'll try later then :-)
[16:21] <leonardr> cr3: try stepping through simplejson.dumps()
[16:31] <sinzui> ls
[16:31] <sinzui> oops
[16:37] <jpds> sinzui: No OOPS ID?
[16:39] <sinzui> jpds, I was attempting to list a dir in my terminal, xchat had focus
[16:39] <jpds> ;-)
[16:42] <cr3> leonardr: turns out the problem goes deep into the zope browser absoluteurl routine, which calls upton the __name__ attribute of my object which returns self.name which probably triggers something in storm, like cash refresh or somesuch
[16:44] <cr3> leonardr: in that particular context, just calling self.name causes the typeerror (I'm using storm from trunk)
[16:55] <bigjools> deryck: ok I'm free now if you are
[16:56] <deryck> heh
[16:56] <deryck> bigjools, I'm about to jump on my standup
[16:56] <bigjools> lol
[16:56] <deryck> bigjools, I can do bottom of the hour, but then I have another call at the top of the next hour.
[16:57] <bigjools> deryck: perhaps I can do it real quick on mumble right now?  it won't take long
[16:57] <deryck> sure.
[17:00] <bigjools> deryck: bin/test -vv test_deathrow
[17:02] <mars> apport: "Your system encountered a serious kernel problem."  :(
[17:07]  * bigjools is totally loving lp-open
[17:07] <bigjools> bzr lp-open that is
[17:07] <jml> \o/
[17:08] <bigjools> although sometimes I hanker for an IDE
[17:09] <mars> nice, I didn't know about that command
[17:09] <mars> bigjools, here is what I am using: http://www.openkomodo.com/
[17:10] <bigjools> interesting
[17:11] <bigjools> can I keep my vim editor embedded? :)
[17:11] <mars> hmm, it has a full vim emulation mode - embedding, I don't know about that
[17:11] <bigjools> argh my eyes, TCL
[17:11] <bigjools> well if it reads my current vim config...?
[17:26] <bigjools> grrr fscking testfix mode
[17:31] <jml> I'm off. See you all tomorrow.
[17:31] <bigjools> nn jml
[17:34] <EdwinGrubbs> sinzui: do you know why the error_dir is always set to none for new sections in schema-lazr.conf? It seems like that means every new section will require a change to the production config to set the error_dir. Otherwise, exceptions will be lost when it raises an exception that error_dir was not set.
[17:37] <deryck> leonardr, ping
[17:38] <sinzui> EdwinGrubbs, the ErrorLogger uses the default from its section, then updates the information is present in the section it is running all
[17:39] <sinzui> EdwinGrubbs, also, lifeless refactored error reporting to use a separate logging service that manages the dir, so it is often inconsequential.
[17:40] <leonardr> deryck,. hi
[17:41] <deryck> hi leonardr.  I have an issue that I think involves the JavaScript API client, LP.client.
[17:41] <deryck> leonardr, can I explain to you and get your feedback on it?
[17:41] <deryck> I need help working out what's happening :-)
[17:41] <leonardr> ok, sure, maybe mars can help if i can't
[17:41] <deryck> ok
[17:41] <mars> ?
[17:42] <mars> deryck, this the firebug return values thing?
[17:42] <deryck> mars, this is the comment posting issue I mentioned before.
[17:42] <deryck> yes
[17:42] <deryck> mars, leonardr, see bug 541993, especially my comment at comment #15.
[17:42] <_mup_> Bug #541993: Adding comments to a bug shows [Object object] instead of comment <comment-handling> <javascript> <ui> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/541993>
[17:42] <mars> deryck, I didn't ask before, but do you see the behaviour on launchpad.dev?
[17:42] <deryck> yes
[17:47] <mars> deryck, ok, have to go to lunch due to circumstances here, but some thoughts: it could be comment.js is listening for the wrong XHR events, and you are encountering race conditions as a result
[17:47] <deryck> mars, ok, let's catch up more after your lunch.  I have to do a call shortly too.
[17:52] <EdwinGrubbs> sinzui: ok, it looks like lp.services.job.runner.JobCronScript is doing something wrong by calling errorlog.globalErrorUtility.configure(self.config_name), since it blows up if error_dir is not specified in the config for the cronjob.
[17:53] <sinzui> EdwinGrubbs, sounds like an undocumented requirement
[17:58] <EdwinGrubbs> sinzui: hmmm, it seems like the JobCronScript should just have an if-statement that only runs configure if error_dir is not None for its specific section.
[18:00] <sinzui> EdwinGrubbs, I think that is a sound suggestion if there is not a reason error_dir can be the default. I suppose a lot of use case for jobs describe non-webapp processes
[18:01] <sinzui> EdwinGrubbs, if the process is considered to be the webapp, then I agree the default error_dir should be used
[18:23] <cr3> is there something in launchpad, perhaps under lazrjs, to render a table from a restful call?
[18:24] <mars> cr3, in soyuz for the PPAs, I think.
[18:25] <cr3> mars: thanks for the lead, I'll look around there
[18:26] <mars> cr3, lib/lp/soyuz/javascript/lp_dynamic_dom_updater.js /might/ have some useful code
[18:28] <mars> cr3, line 86 has an example usage.  Search for the symbols in our .pt template files for real-world usage
[18:38] <sinzui> flacoste, are we talking today?
[18:44] <flacoste> sinzui: we should!
[18:44] <flacoste> sinzui: mumble?
[18:45] <mars> rockstar, ping, I am looking at deryck's problem with the bug comment async-post code, and wondering if your yui 3.2.1 branch may fix the issue.  Is that branch usable (or landed?)
[18:45] <rockstar> mars, I'm working on it right now.
[18:45] <rockstar> mars, I don't think a new yui is going to fix the issues though.
[18:45] <sinzui> flacoste, mumble
[18:45] <deryck> Hi mars.  When you said you thought we might be listening for the wrong XHR event.  Is there a way to globally log every event fired?  A flag to Y.Event or some such?
[18:46] <mars> rockstar, ok, I am wondering if it is a race condition with XHR event handling - Y.io is one possible culprit
[18:46] <bdmurray> sinzui: from your comments on my +subscriptions branch I get the impression that after clicking Continue on the +subscribe page the user should be returned back to +subscriptions is that right?
[18:46] <rockstar> deryck, there is, but it gets noisy.  Set your log level to "debug"
[18:46] <mars> deryck, yes, you can log everything.  Fire up launchpad.dev, it will be easiest that way
[18:46] <rockstar> Er, filter.
[18:46] <sinzui> bdmurray, yes
[18:47] <rockstar> mars, I really suspect the problem to be in the lp.client
[18:47] <bdmurray> sinzui: okay and that should be possible by setting next_url for the form?
[18:47] <mars> rockstar, it could be there too, yes.  I am looking at the code, and it is a bit hairy
[18:47] <sinzui> bdmurray, yes, or by using the redirect mixin
[18:47] <rockstar> mars, yeah, I recall BjornT futzing with it a bit at the last lazr-js sprint.
[18:48] <rockstar> mars, I'm currently in the process of getting all the python logic out of lazr-js and into a new library.
[18:48] <sinzui> bdmurray, I think the mixin also provides a cancel link
[18:48] <mars> rockstar, awesome :)
[18:48] <bdmurray> sinzui: okay, thanks
[18:48] <mars> deryck, ok, pointed question to diagnose this: what is the content-type header for the named operation, and it's HTTP status?
[18:49] <mars> deryck, for the response
[18:49] <mars> deryck, I am looking at line 186 of client.js, and how the callback argument changes type depending on the HTTP headers
[18:50] <deryck> mars, text/plain;charset=utf-8 with an X-Content-Type-Warning that it was guessed.  And status is 201.
[18:50] <mars> deryck, ok, and the following response?  201 is continue, so there should be a 200 right after it
[18:50] <deryck> rockstar, so how do I sent my log level to debug for YUI?
[18:51] <rockstar> deryck, in the YUI_CONFIG, set your filter: "debug"
[18:51] <deryck> mars, 200 for application/json
[18:51] <rockstar> deryck, that will get noisy as hell though.
[18:51] <deryck> that's what I want. :-)
[18:51] <rockstar> deryck, it's like a monkey paw though.  You'll get what you want, but at a cost you may not want to pay.
[18:52]  * mars gestures towards the firebug console filter field
[18:53] <rockstar> mars, yeah, but the sheer amount of events that fire just on the startup of the page is HUGE.  :)
[18:55] <mars> deryck, you could always hack the page template to use the io-debug.js file directly.  As long as it appears after event.js then it will work as expected
[18:55] <mars> as long as it appears after io-base.js <=
[18:57] <deryck> ok, thanks.
[18:59] <mars> argh, this code twists your brain.  There are a lot of callbacks in here
[19:00] <mars> it's like reading a twisted mix of functional, procedural, and prolog
[19:00] <deryck> yup
[19:01] <deryck> mars, rockstar -- so nothing extra from this diff:  http://pastebin.ubuntu.com/502236/  What did I do wrong?
[19:01] <mars> deryck, in the net tab, are you sure io-debug is in use?
[19:02] <mars> second, client.js does not make use of the LPS config var
[19:02] <mars> third, rockstar spoke of the YUI_CONFIG setting - that is new to me
[19:02] <mars> well, new in that I have only heard passing mention of it
[19:03] <deryck> I'm definitely using io-debug.js.  I see a get for:  https://bugs.launchpad.dev/+icing/rev11594/yui/io/io-debug.js
[19:03] <deryck> But I think I need this filter in LP.client, as you note.
[19:04] <deryck> hmmm, still no luck.  I'll wait on rockstar to see how I've misused this.
[19:06] <mars> deryck, so I have a hack that may help narrow things down.  Try running your test with this patch: http://pastebin.ubuntu.com/502239/
[19:09] <deryck> mars, are line 8 and 9 really different?
[19:09] <mars> deryck, whitespace
[19:09] <mars> editor did that
[19:09] <deryck> ok
[19:10] <deryck> mars, what should I be looking for here?  patch applied.  Same behavior by posting a comment.
[19:11] <mars> deryck, ok, that is a nod towards the problem being in the result processing and not the event order
[19:11] <deryck> ok
[19:11] <deryck> mars, I don't think it's event order.  Unless it's something to do with the client patching on.success.
[19:12] <mars> yep
[19:12] <mars> but this rules that out
[19:13] <sinzui> flacoste,  RT#41631
[19:13] <_mup_> Bug #41631: deskbar didnt recognize short nautilus bookmarks <deskbar-applet:Fix Released> <deskbar-applet (Ubuntu):Fix Released by desktop-bugs> <https://launchpad.net/bugs/41631>
[19:14] <lifeless> moin
[19:19] <mars> morning lifeless
[19:19] <achuni> morning lifeless
[19:21] <mars> deryck, does this patch work? http://pastebin.ubuntu.com/502247/
[19:23] <deryck> mars, trying now....
[19:24] <mars> neat, YUI has touch gestures capability
[19:24] <deryck> mars, doesn't fix the "object Object" dom update.  Does add more logging, obviously.
[19:24] <mars> hehe
[19:25] <mars> deryck, ok, was the log output useful?  Or was it just a bunch of "object Object" junk?
[19:25] <deryck> mars, yeah, object object or object XMLHttpResponse stuff.
[19:26] <achuni> hi! buildbot question... prod_lp threw a "substantiate failed" recently and the whole thing was restarted, but it hasn't picked up the branch I had landed since then.  Is it just a matter of waiting, or should I use the /force form?
[19:26] <mars> deryck, ah, see, that is useful - you now know where it changed from the response to the wrapped value
[19:27] <mars> achuni, if you landed it before the restart, then yes, someone needs to force the build
[19:27] <achuni> mars: yup, in fact I was concerned the land was what caused it to fail, but lifeless pointed out "substantiate failed" wasn't due to the code itself
[19:28] <mars> nope, that is the network reminding us it is still there laughing at us
[19:28] <achuni> :)
[19:28] <deryck> mars, copied from firebug output: http://pastebin.ubuntu.com/502252/
[19:29]  * achuni tries a bit of force then
[19:34] <mars> deryck, so it is this line: representation = Y.JSON.parse(response.responseText);
[19:35] <achuni> mars: yay, substantiate success, building now. thanks!
[19:35] <mars> achuni, np
[19:36] <mars> deryck, what is the whole stack of code supposed to return?  A JS Resource object?
[19:37] <lifeless> any soyuz folk still here ?
[19:38] <deryck> mars, insert_comment_HTML expects a string as it's first argument, which should be the xhtml returned in the get response.
[19:39] <mars> ok
[19:40] <mars> deryck, uh, why is the content type application/json then?
[19:41] <deryck> mars, not sure.  When I do this with my debugger statement in the middle method trick and wait a beat or two.... the final GET has a content type of application/xhtml+xml and there is no "representation" log line.
[19:41] <mars> deryck, let me rephrase that: so the content type is application/json - are you getting back a JSON object holding XHTML as the response body, or XHTML as the response body?
[19:41] <deryck> mars, see above from me
[19:42] <mars> weird
[19:44] <deryck> mars, maybe this will make it clearer:  http://pastebin.ubuntu.com/502262/
[19:44] <deryck> mars, the middle method sets the accept parameter to get xhtml, but this only works with the debugger line set.
[19:44] <mars> well, it beats jumping around the file like I've been doing :)
[19:46] <mars> deryck, and the Accept header in the request is correct?
[19:46] <mars> deryck, with and without the debugger line
[19:47]  * deryck confirms or denies....
[19:49] <deryck> mars, yes, accept header is right, with or without debugger statement.
[19:49] <mars> k
[19:53] <deryck> mars, I see no difference in the request headers (debugger or not).  The response headers are different.  With debugger there is a Keep-Alive and Connection header.
[19:53] <mars> interesting
[20:00] <lifeless> matsubara: tudo bem
[20:00] <matsubara> lifeless, oi, tudo bem e contigo?
[20:01] <lifeless> Hah, thats exhausted my pt - whats 'contigo'?
[20:02] <lifeless> matsubara: you were working on feature flag controlled timeouts
[20:02] <lifeless> matsubara: hows that going? do you need a hand?
[20:03] <matsubara> lifeless, I'll get back to work on that this week. I put it on hold due to the sprint last week.
[20:03] <matsubara> lifeless, "oi tudo bem e contigo?" means "hi, I'm fine, you?"
[20:04] <lifeless> matsubara: no worries; I'll be in sydney tomorrow, so to be sure it gets in before we freeze, if its still pending tomorrow can you please push up your WIP and I'll tag-team with you on it
[20:06] <lifeless> matsubara: thanks [language help :)]
[20:07] <matsubara> lifeless, ok. I'll ping you tomorrow
[20:08] <lifeless> matsubara: I'll be starting late because of the plane trip - about 9am sydney time - I wouldn't want to hold you back late @ work
[20:08] <mars> deryck, that really sounds like a browser-based issue of some sort, either caching or... getting the wrong response for a request.
[20:09] <mars> deryck, for the response with the incorrect information, is there a body?  What happens if you enable the "Show XMLHTTPRequest" in the Console options tab?
[20:10] <deryck> mars, I have that enabled.  It gets the JSON representation of the comment in the wrong response (i.e. without debugger statement); otherwise, it gets the xhtml representation.
[20:10] <mars> deryck, try shutting that feature off
[20:12] <deryck> mars, that works now.
[20:12] <mars> deryck, one of these then: http://code.google.com/p/fbug/issues/list?can=1&q=xhr+-lite+show+xmlhttprequests&sort=-id&colspec=ID+Type+Status+Owner+Test+Summary&cells=tiles
[20:13] <deryck> mars, but I have the same issue on my phone, in a chrome based browser.
[20:14] <mars> deryck, ok, so just to confirm: the bug appears when that Firebug console option is enabled, and the bug disappears when it is not enable?
[20:15] <deryck> mars, indeed, that is correct.  And it appears consistently against staging on my phone, and I have no developer options for the browser to toggle on and off.
[20:15] <deryck> mars, so I agree it seems Firebug is causing us to get the cached XHR.  Chrome on the phone must do the same.
[20:15] <mars> .oO( whaaaa! )
[20:16] <deryck> You're too l33t for me.... is that crying, wailing, or sudden inspiration?
[20:17] <mars> the first two
[20:17] <deryck> ok
[20:17] <mars> I should have written 'whhaaaagggghhh!'
[20:18] <mars> deryck, out of curiosity, what does your phone say about this page? http://www.mnot.net/javascript/xmlhttprequest/cache.html
[20:18]  * deryck reaches for phone
[20:19] <lifeless> achuni: hi
[20:19] <lifeless> achuni: what rev of devel did you land your shipit sourcedeps.conf change on ?
[20:19] <mars> deryck, what browser phone?
[20:19] <mars> deryck, grammar fail
[20:19]  * achuni checks
[20:20] <mars> deryck, what version of the browser do you have on your phone?
[20:20] <achuni> lifeless: 11642
[20:20] <lifeless> achuni: cool, thanks.
[20:20] <achuni> np
[20:20] <lifeless> achuni: you may not be aware but we're overhauling our code->live story a lot at the moment.
[20:20] <deryck> mars, cache control headers are all fail on the phone.
[20:21] <lifeless> achuni: so I'm checking that my assumptions about our use cases are right.
[20:21] <deryck> mars, it just says "Web version 7" nothing more specific.  It's chrome, obviously, since it's an android phone.
[20:21] <achuni> lifeless: ah where should we get the updates about that from?
[20:22] <mars> deryck, that page I gave you tells you the browser user agent up at the top of the page
[20:22] <deryck> ah
[20:22] <lifeless> achuni: the dev list
[20:22] <mars> I have "Testing Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.3 (KHTML, like Gecko) Chrome/6.0.472.63 Safari/534.3"
[20:22] <mars> on the desktop
[20:23] <deryck> mars, Version/4.0 Mobile Safari/530.17.
[20:23] <achuni> k
[20:23] <lifeless> achuni: changes that are deployed are in the wiki naturally (e.g. /LEP/ReleaseFeaturesWhenTheyAreDone lists its progress, and the private wiki pages will be changing soon, but they are active not planning/discussion)
[20:31] <lifeless> jml: could you package up your difftodo plugin? or get someone in #bzr to do that?
[20:31] <deryck> a ha.  Now I get why this doesn't fail for the code team.
[20:32] <mars> deryck, ?
[20:33] <deryck> mars, because they build a new URL when getting the fragment, so they're not susceptible to caching.
[20:34] <rockstar> deryck, sorry, went to eat food.
[20:34] <mars> yeah
[20:34] <rockstar> deryck, did you figure out your issue?
[20:34] <deryck> boo-yah!  I have a winner.
[20:34] <mars> was wondering that
[20:35] <mars> deryck, not that for your phone, "If the browser cache does not pay attention to these directives, it can't be controlled by authors."
[20:35] <mars> *note
[20:35] <mars> except if you rotate the URL
[20:35] <deryck> exactly. :-)
[20:37] <deryck> mars, rockstar -- and here's the fix:  http://pastebin.ubuntu.com/502284/
[20:37] <mars> congrats.  That was a difficult one
[20:37] <rockstar> deryck, what. the. hell.
[20:37] <rockstar> deryck, it's caching a 404?
[20:37] <mars> lol
[20:38] <deryck> rockstar, firefox with firebug and mobile safari use the cached version of the resource.  Have to fake them out.
[20:38] <lifeless> 404's are cachable.
[20:38] <rockstar> deryck, holy hell.
[20:38] <lifeless> in a negative sense
[20:38] <deryck> it's not really a 404 :-)
[20:38] <lifeless> squid does this all the time.
[20:38] <rockstar> lifeless, yes, we see this negative affect in deryck's bug.
[20:38] <deryck> no, there's no 404 there.
[20:38] <deryck> it's the same resource.  the query param is ignored.
[20:38] <rockstar> deryck, what's at the the end of the resource then?
[20:39] <deryck> it's basically -- ?foobarjunk
[20:39] <rockstar> deryck, if you just get it without the query param, what would you get?
[20:39] <mars> rockstar, two bugs: first, Firebug was caching the 404 because the "Show XMLHTTPRequests" option was enabled in the Console tab - shutting it off fixed it in FF
[20:39] <deryck> rockstar, the cached version
[20:39] <rockstar> deryck, and that cached version is what?
[20:40] <mars> rockstar, second bug: iPhone does not obey any cache headers according to http://www.mnot.net/javascript/xmlhttprequest/cache.html, so deryck had to force it to stop caching using url rotation
[20:40] <rockstar> deryck, weren't you seeing this bug in Chrome as well?
[20:40] <deryck> rockstar, it's mobile safari, not chrome.  Samsung sluts.
[20:40] <deryck> :-)
[20:41] <rockstar> deryck, yeah, but I'm pretty sure I've seen this bug since I started using Chromium exclusively.
[20:41] <rockstar> mars, have you filed a bug with firebug?
[20:41] <deryck> rockstar, it has to be caching issues either way.  I'm pretty confident of the fix after chatting with mars for so long.
[20:42] <rockstar> deryck, oh, I don't doubt that this would fix it.  The fact that it occurs at all is craziness.  :)
[20:42] <deryck> rockstar, this is an argument in favor of code team way of appending +fragment to a resource url to fetch the fragment new.
[20:42] <deryck> rockstar, yeah, it's silly.
[20:42] <mars> rockstar, ugh, no.  I'm too burned after this to do so, and that tab is known to have issues. FB 1.6b1+ should fix it though
[20:42] <rockstar> deryck, yeah, normally, we do ++fragment.  The double plusses indicated visually that it's a fragment.
[20:43] <lifeless> Gotta love mnot. The man is a god.
[20:43] <rockstar> mars, okay, I'll file the bug.  I was futzing with Firebug source the other night, so I may be able to provide some more details.
[20:44] <mars> rockstar, ok.  Apparently they also really like to look at bugs with test cases, but that means you'd have to write something with web.py (or cgi) to recreate the 404
[20:44] <mars> rockstar, or we could ask deryck to test in firebug 1.6b1
[20:44] <_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:In Progress by sabdfl> <
[20:44] <deryck> rockstar, they have a few that hint at the issue.  but they seem to lack a single case of it, as mars notes.
[20:44] <deryck> b1?  really mup?
[20:45] <rockstar> mars, deryck, yeah, I think writing the test case will indicate exactly what the problem is.
[20:45] <deryck> 6b1
[20:45] <deryck> bug 1.6b1
[20:45] <_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:In Progress by sabdfl> <
[20:45] <deryck> heh
[20:45] <mars> firebug 6000.1
[20:45] <_mup_> Bug #6000: vice 1.16-4 FTBFS <vice (Ubuntu):Fix Released by motu> <https://launchpad.net/bugs/6000>
[20:45] <rockstar> deryck, mup is short for muppet, which, AIUI, is not a term of endearment, especially when coming from elmo.
[20:46] <deryck> sorry, I'm punching after this afternoon.
[20:46] <rockstar> deryck, :)
[20:46] <deryck> Glad to have a fix I can use, though.
[20:46] <rockstar> deryck, you'll be happy to know I'm currently massaging lazr.jstools into lazr-js.
[20:47] <deryck> nice!  I am happy.
[21:01] <deryck> I'm out.  Later on, everyone.
[21:02] <abentley> rockstar: but elmo is a muppet on Sesame Street!
[21:03] <rockstar> abentley, don't tell HIM that.  :)
[21:03] <rockstar> Might as well tell the dude he's adopted.
[21:04] <lifeless> \o/ /tmp directory leak in the test suite found :)
[21:22] <flacoste> lifeless: is the token-based private librarian deployed?
[21:23] <flacoste> thumper: hi, since my call with gary isn't happening, i'm available earlier
[21:23] <lifeless> flacoste: no, losa in progress
[21:23] <thumper> flacoste: ok
[21:24] <lifeless> flacoste: we're bringing it up on staging first, obviously. Once its qa'd and we've checked we don't (for instance) blow out the session db size, we'll configure it in prod.
[21:24] <lifeless> flacoste: and after that flick the switch.
[21:24] <flacoste> lifeless: ok
[21:24] <lifeless> flacoste: there is, as far as we know, no code to write.
[21:25] <lifeless> flacoste: and the code is in all branches; its totally deployment & config.
[21:30] <bdmurray> sinzui: here is a diff of what I had to do to get continue to redirect to +subscriptions - https://pastebin.canonical.com/37799/.  Does that seem reasonable to you?
[21:34] <sinzui> bac: branch-listing.pt may render faster if we used "sprite branch" instead to using an <img> element 75 times
[21:35] <bac> sinzui: good point
[21:44] <sinzui> bdmurray, that looks good
[21:44] <bdmurray> sinzui: in line 33 there is a change to display the bug number as it would be weird to say "this bug" on +subscriptions that seems okay too?
[21:45] <sinzui> bdmurray, yes
[21:45] <bdmurray> sinzui: great, I'll go see if there are other tests I need to fix up and push it
[21:53] <rockstar> mars, does jslint REALLY require bzrlib?
[21:54] <rockstar> mars, actually, I should say, "could we accomplish the same thing without bzrlib?"
[21:58] <cr3> hi folks, what's the lazr-js/build directory used for? I see it created in the jsbuild_lazr Makefile target, but not used afterwards
[21:58] <lifeless_> sinzui: so, memcache and efficiency
[21:58] <lifeless> there's a design tension in our use of the DB and out use of memcache.
[21:58] <lifeless> we try to do a few very efficient queries to the DB to get data.
[21:59] <lifeless> and then we do memcache interception of the iteration in the page template.
[21:59] <lifeless> But the DB work is already done.
[21:59] <cr3> nevermind, found it: lib/canonical/launchpad/icing/lazr -> ../../../../lazr-js
[21:59] <lifeless> So the only saving memcache offers is over the tal rendering.
[22:00] <sinzui> I expected to save cost on renders a lot of bugs decorated with badges and users/teams links that also have icons
[22:00] <sinzui> s/renders/rendering/
[22:01] <lifeless> sinzui: it beggars the imagination that an RPC to get 30 bytes of data could be faster than generating those bytes from the live objects we've already retrieved from the database.
[22:01] <lifeless> sinzui: I mean, if its true we have serious efficiency issues in the rendering stage that we -have- to fix to have fast memcache-misses.
[22:02] <lifeless> sinzui: grabbing a whole rendered table in one hit could well be faster than rendering.
[22:02] <lifeless> sinzui: grabbing a single row would be highly questionable, grabbing a single cell implausible.
[22:03] <wallyworld___> morning
[22:05] <lifeless> win 66
[22:06] <bac> hi lifeless got a minute?
[22:06] <lifeless> sure
[22:06] <sinzui> lifeless, I see two cases of cache:private in registry still. the one I intended to get rid of caches a milestone in a table row when shown on a series or +milestones page. I intended to cache the entire listing for anon only.
[22:06] <lifeless> sinzui: caching the entire listing is ok, but we cache anon *pages* in squid anyway.
[22:06] <lifeless> sinzui: so I wonder what incremental benefit memcache will have there.
[22:06] <sinzui> ha.
[22:07] <lifeless> bac: whats up?
[22:10] <rockstar> abentley, make-super-duper-clean-no-srsly is really effective when using buildout.
[22:11] <abentley> rockstar: this is "rm * -R; bzr revert"?
[22:11] <rockstar> abentley, yes.
[22:11] <abentley> rockstar: hehe.
[22:11] <rockstar> cr3, hi
[22:15] <cr3> rockstar: hi there
[22:17] <rockstar> cr3, I see you are futzing with lazr-js.
[22:19] <rockstar> cr3, I'm making some changes to pull the build-type code out into a separate package.  Will that cause problems for you?
[22:20] <cr3> rockstar: probably, but I could follow the evolution in the launchpad build scripts
[22:21] <cr3> rockstar: thanks for the heads up though, at least I won't be too surprised when something suddenly fails to build :)
[22:21] <rockstar> cr3, okay.  Yeah, the launchpad build script stuff is the last place that's going to change.  I'm currently massaging lazr.jstools back into lazr-js.
[22:27] <cr3> rockstar: while you have your hands in that code, might you happen to know why SRC_DIR seems to be set to src-py/lazrjs instead of src-js/lazrjs in build.py?
[22:27] <rockstar> cr3, setuptools, I think.
[22:28] <rockstar> cr3, this oddity is one of the reasons I'm abstracting these tools.
[22:29] <cr3> rockstar: setuptools indeed, setting the wrong directory for some reason... lets see how I can workaround that
[22:29] <rockstar> cr3, you'll also notice __init__.py in src-js/lazrjs
[22:29] <rockstar> cr3, why do you need to work around it?
[22:30] <cr3> rockstar: or make setuptools behave to have the proper path
[22:31] <rockstar> cr3, everything is hairy right now, but it should all work.  If it's not working, I'd be curious to know why not (and maybe a pastebin of the error)
[22:32] <cr3> rockstar: there's no error message really, I buildout lazr-js from trunk (called toolchain) which results in the path build/source-dependencies/lazr-js/trunk/src-py in the build/parts/scripts/site.py
[22:32] <cr3> rockstar: note that this is not in the launchpad codebase though, just using lazr stuff in another project
[22:32] <rockstar> cr3, ah, use make.
[22:32] <rockstar> cr3, ah, okay.
[22:33] <cr3> I'll give the beta lazr-js tarball a try instead of building from the trunk, one moment...
[22:33] <rockstar> cr3, yeah, uh, I guess my work would make it easier for you, but I'm still massaging it all together.
[22:33] <rockstar> cr3, there is only trunk.
[22:33] <rockstar> cr3, ignore any other branches.
[22:33] <rockstar> Otherwise, you will be misled.
[22:33] <rockstar> At some point, I will clean that up.
[22:34] <cr3> rockstar: this is the branch I'm using: https://code.edge.launchpad.net/~launchpad-pqm/lazr-js/toolchain
[22:36] <rockstar> cr3, yeah, that's right.
[22:36]  * cr3 builds with tarball and crosses fingers
[22:38] <lifeless> argh, stab stab stab layers.
[22:40] <lifeless> and woo
[22:40] <lifeless> I've finally figured out why we get multiple librarians running
[22:41] <cr3> rockstar: tarball works fine, problem solved :)
[22:41] <rockstar> cr3, yay!
[22:41] <cr3> rockstar: another advantage is that I can relax when your changes kick in since I now have a working snapshot of lazr-js
[22:42] <rockstar> cr3, yup.  You can easily upgrade lazr-js without having to worry about the python dependencies as well.
[22:47] <bac> hi james_w, you still around?
[22:47] <james_w> hi bac
[22:48] <bac> james_w: you've got quite a few approved branches that need landing.  is there something blocking you?
[22:49] <lifeless> thumper: ping
[22:49] <lifeless> thumper: nvm
[22:52] <james_w> bac: nothing except my lack of time
[22:53] <bac> james_w: i understand.  you've done a lot of really good work that it would be nice to get landed.  let me know if i can help.
[22:54] <james_w> bac: I count three, are there more than that somewhere?
[22:55] <bac> james_w: yes, just those three
[22:55] <james_w> bac: ok, I'll merge them up and try and land one now
[22:55] <bac> thanks james_w
[23:10] <lifeless> mwhudson: hey
[23:10] <mwhudson> lifeless: hi
[23:10] <lifeless> mwhudson: so I found more nasty nasty dirt landing this patch you reviewed monday
[23:10] <lifeless> I'd like a casual eyeball over the incremental
[23:11] <mwhudson> lifeless: ok
[23:11] <mwhudson> lifeless: link?
[23:11] <lifeless> http://bazaar.launchpad.net/~lifeless/launchpad/test/revision/11644
[23:11] <lifeless> is the only non-obvious commit
[23:15] <mwhudson> lifeless: unnique is a typo
[23:17] <mwhudson> lifeless: "so store a valid path temporarily" -- i think you mean invalid path?
[23:17] <lifeless> valid - its a string
[23:18] <lifeless> as opposed to correct
[23:18] <mwhudson> ah
[23:19] <lifeless> clearly confusing, will rephrase
[23:19] <mwhudson> thanks
[23:19] <lifeless> s/valid/plausible
[23:33] <lifeless> mwhudson: that was all ?
[23:33] <mwhudson> lifeless: yes
[23:33] <lifeless> thanks
[23:33] <lifeless> you can see the hair I'm uncovering
[23:34] <mwhudson> yeah, it's awesome that you're doing this
[23:34] <lifeless> I'm struggling to decide whether to fix layers
[23:34] <lifeless> or just bring testresources in.
[23:35] <mwhudson> lifeless: i think i said to jml when you got the TA position that one of the reasons I was glad was that you were much less likely to get discouraged by this sort of thing than a typical human being :-)
[23:35] <lifeless> I am the hulk in this respect.
[23:35] <lifeless> fueled-by-anger
[23:39] <jml> lifeless: jkakar & I have discussed rage-driven development
[23:39] <lifeless> nice
[23:40] <mwhudson> i occasionally find code that i wrote and remember how extremely angry i was when i wrote it
[23:41] <lifeless> so what I actually meant was that my motivation increases the more problematic stuff I run into.
[23:41] <lifeless> not that I feel /angry/ as such.
[23:43] <mwhudson> right, that's a more useful effect
[23:57] <poolie> hello jml, mwhudson
[23:58] <jml> hi everyone. I'm not really here.
[23:59] <poolie> suits you :-P