[00:10] <rockstar> wgrant, removing old code is the easiest way to get a branch landed.  :)
[00:10] <cody-somerville> wgrant, S[SB]PPH is gone?!
[00:10] <wgrant> cody-somerville: Yes, Julian removed them a few months ago.
[00:10] <wgrant> makes everything muuuuch easier.
[00:11] <wgrant> rockstar: True, but it's scattered everywhere.
[00:11] <cody-somerville> hah. sweet.
[00:11] <wgrant> And when I try to remove things, I inevitably end up getting fed up with the shocking Soyuz tests, so rewrite them instead...
[00:14] <jkakar> lifeless: If you can get someone to bump the build priority of the new Storm packages you'll have your release earlier. :)
[00:17] <rockstar> wgrant, yes, I know that dance.
[00:17] <jkakar> I wonder what would happen if each team had to rotate every cycle.
[00:18] <jkakar> All of a sudden Soyuz becomes Code, Code becomes Registry, Registry becomes Translations, etc.
[00:18] <rockstar> jkakar, madness I tell you. Madness.
[00:18] <jkakar> rockstar: Sure, but would it be *good* madness?
[00:18] <rockstar> jkakar, depends what team you end up being on.
[00:19] <rockstar> jkakar, also, ftr, the lines between the code team and the soyuz team have been blurred recently.
[00:19] <wgrant> We managed to fob lots of our code off into collective maintenance at the start of the year.
[00:19] <wgrant> I was pretty pleased.
[00:19] <wgrant> Yes, exactly.
[00:19] <jkakar> rockstar: That's great to hear.
[00:19] <wgrant> jkakar: Not for Code it isn't :P
[00:20] <jkakar> On the Landscape team we have no internal boundaries.  Everyone is expected to know everything (which of course isn't true, but no one can ever say 'Not my problem').
[00:20] <jkakar> wgrant: :)
[00:20] <wgrant> jkakar: How big is the Landscape codebase?
[00:20] <jkakar> I sometimes wonder what would happen if that was the case in Launchpad.
[00:21] <lifeless> in theory we have no/few internal boundaries
[00:21] <wgrant> lifeless: Ha ha ha sure.
[00:21] <lifeless> in practice we do
[00:21] <lifeless> wgrant: jml and I, and I think francis, would like to see less partitioning
[00:22] <wgrant> The team structure is defined to have subteams for each application!
[00:22] <wgrant> That is surely creating boundaries.
[00:22] <lifeless> wgrant: conways law, and yes.
[00:22] <wgrant> lifeless: That's good.
[00:26] <jkakar> wgrant: Landscape server has 235413 lines of Python, Javascript and ZPT.  Landscape client has 44351 lines of Python code.  A secret thing has 19197 lines of Python code.  A total of 298961 lines of code.
[00:26] <jkakar> wgrant: Not that lines of code is really a measure of much.
[00:27] <jkakar> Probably much smaller than Launchpad.
[00:27] <lifeless> nah
[00:27] <lifeless> sloccount of lib/lp and lib/canonical
[00:27] <lifeless> python:      278120 (75.66%)
[00:27] <lifeless> xml:          86102 (23.42%)
[00:27] <lifeless> perl:          3002 (0.82%)
[00:27] <lifeless> sh:             378 (0.10%)
[00:28] <wgrant> 392735 Python, JavaScript and ZPT.
[00:28] <lifeless> its both larger and smaller than it needs to be - larger on the source side, smaller on the tests side
[00:28] <wgrant> Yep.
[00:29] <jkakar> We have ~7900 tests in Landscape, ~1800 tests in Landscape client and about ~700 in secret thing.
[00:29] <jkakar> In general we tend to have 25%-40% more test code than application code.
[00:29] <lifeless> you really should rotate to the bzr team for 2 months
[00:30] <lifeless> :)
[00:30] <jkakar> That would be fun. :)
[00:30] <jkakar> I guess you have a lot more test code than that?
[00:30] <lifeless> 21K tests run in trunk, or there abouts
[00:30] <lifeless> there is a multiplicative effect there due to test scenarios per-backend, but still
[00:31] <jkakar> lifeless: By the way, I've been looking at testscenarios for a project I'm hacking on.  It's really nice.  Thanks. :)
[00:31] <lifeless> jkakar: my pleasure
[00:31] <lifeless> jkakar: I've another one up my sleeve.
[00:31] <lifeless> Just need a weekend to realise it
[00:32] <jkakar> Nice.
[00:32] <lifeless> jkakar: you might like this too - https://code.edge.launchpad.net/~lifeless/launchpad/registry/+merge/31830
[00:34] <jkakar> lifeless: Very nice.  I've been looking at matchers more closely too.  I'm excited, they solve lots of annoying problems.
[00:34] <jkakar> lifeless: Need to integrate them in Landscape still.
[00:35] <lifeless> jkakar: \o/
[00:35] <lifeless> jkakar: assertThat in testtools is:
[00:35] <lifeless>  - small
[00:35] <lifeless>  - BSD/ApacheV2
[00:35] <lifeless> so just grab it and shove it in your base clsas
[00:36] <jkakar> That's my plan. :)
[00:36] <jkakar> In fact, I've been doing that to use it with Twisted.
[00:42] <lifeless> you could put it in twisted ;)
[01:12] <cody-somerville> Has anyone seen Review Board before?
[01:12] <lifeless> yes
[01:13] <cody-somerville> It seems really slick. Is that the direction launchpad reviews are going in?
[01:14] <lifeless> its a bit of an ambiguous question
[01:14] <lifeless> yes, clearly everyone wants to make lp reviews better
[01:14] <lifeless> is it going to be a clone of rb? I doubt it.
[01:15] <jkakar> lifeless: https://edge.launchpad.net/storm/trunk/0.17
[01:16] <cody-somerville> I really like how it lets you embed snippets of the patch in your comment and have it highlighted and lets you comment on the specific comments against a snippet in a comment
[01:16] <lifeless> cody-somerville: feel free to file wishlist bugs for specific things you'd like to see
[01:17] <lifeless> jkakar: hey, can we have a voice chat?
[01:17] <jkakar> lifeless: Sure thing.  Skype?
[01:17] <lifeless> I want to talk through mapping ORM failure modes
[01:17] <lifeless> yes
[01:17] <jkakar> lifeless: I'm 'jkakar' on Skype.
[01:18] <lifeless> you need to click 'allow' not 'sodoff'
[01:18] <lifeless> :P
[01:32] <poolie> hi lifeless, i'm planning to do the next tranche of flags today
[01:32] <poolie> unless there are any priority interrupts
[01:35] <lifeless> poolie: cool
[01:36] <poolie> lifeless: brief call?
[01:36] <lifeless> otp right now
[01:36] <lifeless> after that sure
[02:14] <lifeless> poolie: ok, off the phone, ping me when you want to chat
[02:17] <lifeless> sinzui: bug 593054 - how would you feel if I land a patch dropping the memcache use from it ?
[02:17] <_mup_> Bug #593054: Need to flush caches with modified object <Launchpad Foundations:Triaged> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/593054>
[02:39] <lifeless> poolie: I might go cook some lunch and so on, but I dont' want to block you
[02:39] <poolie> no i'm good now
[02:40] <lifeless> ok. skype ?
[05:06] <thumper> ✁☹
[05:06] <thumper> mwhudson: the merging of the codehosting areas may have landed everywhere except lp.dev
[05:12] <lifeless> poolie: your branch [with my tweaks] fails some tests. forwarding to you
[05:13] <mwhudson> thumper: ?
[05:16] <thumper> mwhudson: using make run_codehosting we get branches in two locations:
[05:17] <thumper>  /var/tmp/bazaar.launchpad.dev/push-branches/
[05:17] <thumper> and
[05:17] <thumper>  /var/tmp/bazaar.launchpad.dev/mirrors/
[05:17] <thumper> or at least pushing puts it in mirrors
[05:17] <thumper> and the makefile makes branches in push_branches
[05:23] <thumper> I'm trying to work out why the scanner is looking in the wrong place
[05:29] <mwhudson> oh oops
[05:30] <mwhudson> i sort of vaguely knew about make-dummy-hosted-branches being wrong
[05:30] <thumper> it could just be the make-dummy... thing that is wrong
[05:30] <thumper> and the reason that the scanner is broke
[05:30] <thumper> is that I've not installed the local launchpad recently
[05:33] <thumper> mwhudson: why is the scanner looking in the wrong place?
[05:33] <thumper> I can't figure it out
[05:33] <thumper> it uses lp-internal
[05:35] <thumper> gah
[05:35]  * thumper smacks head against the table
[05:35]  * thumper still can't see it
[05:37]  * thumper leaves for a bit
[05:41] <mwhudson> thumper: lp-internal maps to http, so that should be served from ../mirrors
[05:44] <thumper> mwhudson: which has me wondering why the scanner can't open it
[05:44] <mwhudson> thumper: what is the scanner saying?
[05:44] <thumper> TransportError: Transport error: Server refuses to fulfill the request (403 Forbidden) for http://bazaar-internal.launchpad.dev/00/00/00/50/.bzr/branch-format
[05:44] <mwhudson> sometimes /var/tmp/bazaar.launchpad.net/mirrors isn't world readable
[05:45] <mwhudson> thumper: ah, bet this is the case
[05:45] <mwhudson> if you can figure out why this happens...
[05:46] <thumper> ah
[05:46] <thumper> (*&%^$#@!#$%^&
[05:52] <thumper> mwhudson: that's it
[05:52] <thumper> mwhudson: I'll fix the config stuff in a different branchj
[06:17] <poolie> thanks lifeless
[07:12] <lifeless> I need a teddy-bear who knows APIs well
[07:12] <lifeless> anyone around ?
[07:13] <lifeless> specifically, I have a property which is exported and I'd like to know how to make it call a function rather than just accessing a property
[08:02] <wgrant> lifeless: What do you mean?
[08:02] <lifeless> wgrant: so, this is 'allmembers'
[08:03] <lifeless> 'allmembers' is exposed as /participation on people/teams
[08:03] <lifeless> for many uses, what the query retrieves today is fine, I don't want to make it greedy automatically.
[08:03] <wgrant>  /participants, you mean?
[08:03] <lifeless> but for this particular case, because its being rendered as json
[08:03] <lifeless> blah yes
[08:03] <wgrant> You need to export a method which does it instead.
[08:03] <lifeless> I want to expand out all the things that it gets so the json rendering etc
[08:04] <wgrant> Then callers have to call the method.
[08:04] <lifeless> wgrant: right, but 1.0 api freeze.
[08:04] <wgrant> You can't, unfortunately, just make the attribute lazy.
[08:04] <lifeless> wgrant: other way around
[08:04] <lifeless> anyhow, I think I have it
[08:04] <lifeless> stop exporting allmembers
[08:04] <lifeless> export allmembers_full or someting 'as' participants
[08:05] <lifeless> have allmembers and allmembers_full both call a common core function with arguments expressing how greedy they want the object evaluation to be.
[08:05] <wgrant> If you export an attribute at all, it will be serialised along with the rest of the representation.
[08:06] <lifeless> only fields
[08:06] <wgrant> Oh, right.
[08:07] <lifeless> this will be a CollectionField
[08:07] <lifeless> so not included
[08:07] <wgrant> Your approach sounds sane.
[08:07] <lifeless> cool, thanks
[08:26] <poolie> i'm getting this error trying to start postgres in a chroot dedicated to launchpad
[08:26] <poolie> [2010-08-06 07:26:08 UTC] FATAL:  could not create shared memory segment: Invalid argument
[08:26] <poolie> [2010-08-06 07:26:08 UTC] DETAIL:  Failed system call was shmget(key=5432001, size=39395328, 03600).
[08:27] <poolie> does this ring any bells?
[08:28] <lifeless> uhm
[08:28] <lifeless> very very vaguely
[08:28] <lifeless> do you have two chroots like that at the same time? likely to fail I think
[08:28]  * lifeless uses vms because of this ;)
[08:29] <StevenK>     warnings.warn(UnreasonableRemoveSecurityProxyWarning(obj), stacklevel=2)
[08:29] <StevenK> UnreasonableRemoveSecurityProxyWarning: Called removeSecurityProxy(<PackageUpload at 0xce434d0>) without a check if this is reasonable.
[08:29]  * StevenK pouts
[08:29] <spm> lifeless: vms as in Virtual MachineS? not VAX-VMS?!??!
[08:29] <poolie> you're showing your age uncle steve
[08:29] <lifeless> spm: have I told you about a classmates sort algorithm
[08:29] <poolie> lifeless: i'm pretty sure nothing else has it bound
[08:29] <lifeless> spm: on the otago uni vax
[08:29]  * spm was a vms sysadmin for 5 years!
[08:30] <lifeless> spm: he wrote a sort, which he called 'randomsort'.
[08:30] <spm> or 6. I forget...
[08:30] <lifeless> spm: what do you think the supervisor process did to it ....
[08:30] <poolie> i'ts possible something else is using a lot of shm
[08:30] <spm> promoted to always runnable and DOS'd itself!
[08:30] <lifeless> \o/
[08:30] <lifeless> yes, he got slapped :)
[08:31] <spm> vms shell script killer 101: 10: i=i+1;  20: goto 10. <== server dies.
[08:31] <spm> istr that little gem was fixed in the early 90's, with whatever version came out then. but don't recall details.
[08:31] <lifeless> this was 93 :P
[08:32] <spm> 94 is still early! ;-)
[08:33] <spm> I think DEC had the optimistic viewpoint of their mostly boriing corporate customers - if you're dumb enough to that to yourself; sucks to be you.
[08:33] <adeuring> good morning
[08:33] <spm> heya adeuring!
[08:34] <StevenK> Right, now tests I didn't write fail due to that warning. :-(
[08:34] <wgrant> StevenK: The warning shouldn't be making them fail...
[08:35] <spm> StevenK: if any consolation, staging is now kaput; and one of the edge servers has also died; I'd suggest in a near identical way to staging. Personally I think it's all your fault; but have no proof... yet.
[08:35] <StevenK> Error in test lp.archiveuploader.tests.test_ppauploadprocessor.TestPPAUploadProcessorQuotaChecks.testPPASizeQuotaSourceWarning
[08:35] <StevenK> Traceback (most recent call last):
[08:35] <StevenK> ...
[08:36] <StevenK> UnreasonableRemoveSecurityProxyWarning: Called removeSecurityProxy(<PackageUpload at 0xce434d0>) without a check if this is reasonable.
[08:36] <wgrant> spm: Is that due to the vostok changes?
[08:36] <spm> wgrant: bingo
[08:36] <StevenK> Vostok is so not my fault
[08:36] <lifeless> is too
[08:36] <spm> sure it is. I said so. QED. so did Rob, QED x 2.
[08:36] <StevenK>  /ragequit
[08:36] <spm> rofl
[08:37] <spm> is there a fix for that in the pipeline? or do I need to hand revert staging back to a level of workingness?
[08:40] <wgrant> spm: mwhudson has a fix. It was apparently in EC2 at 8am.
[08:40] <wgrant> But hasn't shown up in devel..
[08:40] <spm> woot
[08:40] <wgrant> Oh, wait.
[08:40] <wgrant> I think it did land.
[08:40] <spm> i recall him talking about something, but never did get the details
[08:40] <wgrant> devel r11307
[08:42] <spm> 304 is what hit edge
[08:43] <wgrant> That's current stable.
[08:43] <wgrant> It's merging oddly.
[08:43] <wgrant> Two stable->db-devel merges, less than an hour apart.
[08:43] <wgrant> I don't see how that could happen.

[08:45] <poolie> lifeless/others, when you develop lp in a vm, do you simply keep your source tree within the vm?
[08:46] <lifeless> yes
[08:46] <lifeless> I use ssh -A
[08:46] <lifeless> and virsh start/shutdown
[08:46] <poolie> and run your editor etc in the vm too?
[08:46] <lifeless> yes
[08:46] <lifeless> of course, as I use vim, not gvim, normally, this is no change for me ;)
[08:51] <lifeless> mwhudson: /var/tmp/vostok-archive
[08:51] <lifeless> mwhudson: why is 'make' making that?
[08:56] <wgrant> Oh, are there lucid and non-lucid builders both blessing devel and db-devel at the moment?
[08:59] <lifeless> that seems likely
[08:59] <lifeless> also fail
[08:59] <lifeless> can you tell mars ?
[09:10] <mthaddon> wgrant: there are lucid and non lucid builders that are both tracking devel and db-devel, but in terms of whether we're in "testfix" mode, we only care about the lucid ones
[09:11] <wgrant> mthaddon: But both seem to be able to bless devel for merging into db-devel.
[09:12] <mthaddon> hmm, interesting - I think that's probably true, yeah
[09:23] <bigjools> wgrant: did you get my PM about that failing test in your branch?
[09:29] <wgrant> bigjools: I did. I fixed it, and it's landed.
[09:30] <wgrant> Thanks.
[09:32] <bigjools> greatr
[09:51] <lifeless> stub: is there a wiki page about the workflow for doing db patches?
[09:51] <stub> Yes. schemachanges or something. Its linked off the processes area I think.
[11:03] <bigjools> wgrant: are you still working on https://code.launchpad.net/~wgrant/launchpad/rescue-aborted-and-robbed-builders/+merge/22289
[12:02] <deryck> Morning, all.
[12:04] <jml> morning
[12:11] <lifeless> hai and hai
[12:11]  * lifeless hopes mars pops in soon
[12:29] <wgrant> bigjools: Didn't I throw a comment on that this morning?
[12:29] <wgrant> It bitrotted completely post-Wellington, so someone else should take it.
[12:29] <bigjools> ok
[12:30] <bigjools> can you mark it abandoned?
[12:30] <bigjools> wgrant: also looking at your ddebs for PPAs branch
[12:30] <bigjools> does this need a buildd rollout?
[12:31] <wgrant> bigjools: The buildd change was rolled out months ago.
[12:31] <bigjools> ok
[12:31] <wgrant> Can you reject my MP? I can't do that.
[12:31] <bigjools> done
[12:31] <wgrant> Thanks.
[12:31] <bigjools> I need to address that problem soon, it's a royal PITA
[12:32] <wgrant> Yes.
[12:32] <bigjools> wgrant: I don't supposed you'd be able to create some upload scenarios to QA your dependency wait changes?
[12:33] <wgrant> bigjools: Like, say, lamont's slony package?
[12:33] <wgrant> That's one that should already be there.
[12:33] <wgrant> But I could create another if you want.
[12:33] <bigjools> I need it on dogfood
[12:34] <bigjools> so I can run buildd-retry-depwait.py
[12:36] <wgrant> bigjools: I guess you'll need to set all the existing depwait builds to something else, or you're going to have a rather flooded build farm...
[12:37] <bigjools> wgrant: that's already sorted, I ran it a couple of days ago and then deleted the queue
[12:37]  * bigjools taps side of nose sagely
[12:37] <wgrant> But for easy setup, create a PPA with normal dependencies and copy slony1-psql8.3 from https://dogfood.launchpad.net/~lamont/+archive/psql8.3/+packages
[12:37] <bigjools> ok
[12:37] <wgrant> It will depwait, since it needs debhelper 7, and that's only in hardy-backports.
[12:38] <wgrant> It's being retried every time the script runs at the moment.
[12:44] <wgrant> That's a lot of manual builders.
[12:44] <wgrant> Is glib still screwed?
[12:58] <lifeless> maxb: gnight - would love it if you could drop me a mail saying where I could help with the sheperd project
[12:58] <maxb> lifeless: tab completion fail?
[13:00] <lifeless> maxb: bah, yes
[13:00] <lifeless> mars: ^
[13:06] <james_w> bigjools: am I ok to land https://code.edge.launchpad.net/~james-w/launchpad/stop-publishing-nagging/+merge/31851 ?
[13:15] <jcsackett> anyone get an error on "Getting distribution for testtools==0.9.6dev91" when running "make build" ?
[13:16] <jelmer_> jcsackett: you might have to run ./utilities/update-sourcecode
[13:21] <jcsackett> jelmer_, that updated some things but the error remains. :-/
[13:21] <jcsackett> thanks for pointing that out though, didn't realize that script was there.
[13:22] <jelmer_> jcsackett: Do you have a testtools_0.9.6dev91.tar.gz file in download-cache/dist ?
[13:23] <jcsackett> no, jelmer_,  it's 0.9.2; does that indicate update-sourcecode didn't run properly?
[13:24] <jelmer_> jcsackett: I'm not sure, I think it might perhaps just update the bzr checkouts in sourcedeps/.
[13:24] <jelmer_> jcsackett: You might want to try running "bzr up" in download-cache
[13:25] <jelmer_> jcsackett: rocketfuel-get (if you use the standard lp directory layout in ~/launchpad/{lp-branches,lp-sourcedeps}) will also do all these things for you.
[13:25] <jcsackett> jelmer_: ah, okay. i'll try that. thanks!
[13:28] <jcsackett> jelmer_: looks like that did it (it's at least past where it was erroring before). thanks, again.
[13:45] <bigjools> james_w: yes, PQM is not closed yet
[13:45] <james_w> bigjools: I was more asking from a soyuz standpoint
[13:45] <bigjools> ah sorry
[13:45] <james_w> jml asked me to double-check with you
[13:46] <james_w> also, when it's not release crunch I would like to discuss Soyuz and the factory with you
[13:46] <bigjools> yes PackageUpload is only ever written to in zopeless scripts
[13:46] <bigjools> so it's fine to remove its proxy
[13:47] <bigjools> james_w: that would be in a week's time then :)
[13:57] <jtv> henninge: I'm fazed.
[13:57] <jtv> henninge: Scenario one:
[13:57]  * henninge has 3 minutes to go ....
[13:57] <jtv>         old_entry = queue.addOrUpdateEntry(
[13:57] <jtv>             template.path, '# Content here', False, template.owner,
[13:57] <jtv>             productseries=template.productseries)
[13:57] <jtv>         new_entry = queue.addOrUpdateEntry(
[13:57] <jtv>             template.path, '# Content here', False, template.owner,
[13:57] <jtv>             productseries=template.productseries, potemplate=template)
[13:57] <jtv> Two entries.  No worries.
[13:58] <jtv> Scenario two:
[13:58] <jtv>         old_entry = queue.addOrUpdateEntry(
[13:58] <jtv>             pofile.path, '# Content here', False, template.owner,
[13:58] <jtv>             productseries=template.productseries)
[13:58] <jtv>         new_entry = queue.addOrUpdateEntry(
[13:58] <jtv>             pofile.path, '# Content here', False, template.owner,
[13:58] <jtv>             productseries=template.productseries, pofile=pofile)
[13:58] <jtv> Boom!
[13:58] <jtv> Crash!
[13:58] <jtv> Violates unique constraint.
[13:58] <jtv> The only thing I can think of is that pofile is not part of the constraint...
[13:58] <henninge> jtv: pofile is not taken into account.
[13:59] <henninge> jtv: that is the reason (I figures) why that wordpress-ckb.po did not get approved yesterday.
[13:59] <jtv> Well this particular problem happens while creating the entry.
[13:59] <henninge> jtv: When I went to the approval form, I still had to pick the template - although the entry already said "will be im ported into ..."
[14:00] <jtv> AFAIK potemplate is normally null for translation uploads.
[14:00] <henninge> jtv: right
[14:00] <jtv> Anyway, the constraint indeed does not care about pofile.
[14:00] <jtv> So that rules it out as one of the two possible causes of the bug I'm working on now, which is a bit of a relief.
[14:01] <henninge> jtv: right, that's why the two entries are identical to it
[14:03] <henninge> jtv: but your question is answered, right?
[14:04] <jtv> henninge: yes, I answered it by explaining the problem.  Thanks.  :)
[14:39] <jtv> danilos: https://code.edge.launchpad.net/~jtv/launchpad/bug-613821/+merge/31957 —I can't set the review type to "code" right now.
[14:40] <jtv> danilos: I'd be much obliged if you move the kanban card about as well…
[14:41] <danilos> jtv, I will, thanks
[14:43] <jtv> danilos: I'll go do non-work stuff now, but will check back from time to time.  If/when you feel it's ready, please land it for me…  I'm also running all Translations tests on it so we have reasonable certainty that it won't fail in EC2.
[14:44] <danilos> jtv, did addOrUpdateEntry signature change? (or is it just whitespaces?)
[14:44] <jtv> danilos: whitespace.
[14:44] <danilos> jtv, cool
[14:44] <jtv> I promise.
[14:46]  * danilos rechecks
[14:48] <danilos> jtv, does _getMatchingEntry return only an already approved entry? (i.e. it will not return "itself")
[14:49] <jtv> danilos: it's only called when looking for the more specific match that the approver's pofile/potemplate guess will produce.
[14:50] <jtv> So it won't produce the entry that you're already looking at: you'd be looking for an entry with the same pofile/potemplate, and in that case the caller shortcuts.
[14:51] <danilos> jtv, it'd be nice to return an explicit False in _attemptToApprove when entry.status != NEEDS_REVIEW
[14:51] <jtv> danilos: whoops, sorry :)
[14:54] <danilos> jtv, also, your comment about the 'checking at the very end if it was already approved' confused me a bit :)
[14:55] <jml> deryck, ready when you are.
[14:55] <danilos> jtv, old code was not even considering that problem, it was checking if approval succeeded instead
[14:55] <deryck> jml, ok, 3-4 minutes still 'til I'm ready.  Mumble?
[14:55] <danilos> jtv, basically what you do with a check on the returned value from _attemptToApprove
[14:55] <jml> deryck, sure.
[14:56] <danilos> jtv, anyway, looks good other than that minor point above, r=danilo
[14:56] <jtv> danilos: thanks.  I meant the part where it checked at the end whether the entry's status was APPROVED.  Not too sane.  :-)
[14:57] <jtv> danilos: could you land it for me?
[14:57] <danilos> jtv, right, but that's your "if success" check, roughly the same thing
[14:58] <jtv> danilos: not entirely, which shows that this needed cleaning up.  Basically, in the old code, if the status is APPROVED then how did you get to that point?  By wasting time on an entry that was already approved.
[14:59] <danilos> jtv, right, I am saying that you are adding a totally unrelated fix and your comment about how it's just moving a check to a different place confused me :)
[14:59] <danilos> jtv, it's not moving a check, it's a new check that didn't exist before, and you still do a similar check for exactly the same reasons old code did :)
[15:00] <danilos> jtv, anyway, can you please set the commit message to what you feel is appropriate? :)
[15:00] <jcsackett> hi, sinzui.
[15:00] <sinzui> hj jcsackett
[15:00] <jtv> danilos: there's two different checks here.  One is "does this entry still need review?" and the other is "did I make any progress?"  I moved the former up to before the attempt to approve the entry.
[15:01] <jtv> danilos: I can try to edit the commit message… the UI wouldn't let me earlier, probably because I'm working through my phone.
[15:01] <danilos> jtv, where was that "former" check before?
[15:01] <danilos> jtv, ah, ok, I'll take care of that; have you fixed the "return False" and pushed that?
[15:01] <sinzui> bigjools, ping. do you have time to talk about bug 607879 with jcsackett and myself
[15:01] <jtv> danilos: fixed yes, just checking that it is indeed pushed.
[15:01] <_mup_> Bug #607879: https://bugs.edge.launchpad.net/~person/+participation timeouts <timeout> <Launchpad Registry:In Progress by jcsackett> <https://launchpad.net/bugs/607879>
[15:02] <jtv> danilos: the old check was:
[15:02] <jtv>            if entry.status != RosettaImportStatus.APPROVED:
[15:02] <jtv>                 there_are_entries_approved = True
[15:02] <bigjools> sinzui: Sure.  I am feeling feverish, but I'd probably make the same sense as if I wasn't.
[15:03] <sinzui> bigjools: jcsackett and I may ask for an RC for this oops. It is the leading oops in the registry domain.
[15:03] <danilos> jtv, hum, I read that as the same check you did, except that I misread the '!=' part
[15:03] <danilos> jtv, it seems you are changing the semantics of the method, now it returns
[15:03] <jtv> danilos: never mind, it's all horrible
[15:03] <danilos> True when there's something approved, and it used to return True when there was something it didn't approve
[15:03] <sinzui> bigjools, We need to stormify two methods, and one will require updating the callsites to deal with the changed output
[15:04] <jtv> danilos: only in the case where, while you were approving, an entry changed to some state other than APPROVED through external forces.
[15:05] <sinzui> bigjools, So I think I have forewarned you about our goals for today
[15:05] <jtv> (From NEEDS_REVIEW)
[15:05] <danilos> jtv, I seem to be reading this wrong
[15:06] <danilos> jtv, so, if an entry stayed NEEDS_REVIEW (i.e. we didn't find what to approve), we used to set there_are_entries_approved to True (yes, the var name is wrong)
[15:06] <bigjools> sinzui: anything that fixes an oops is likely to get an RC from me :)
[15:06] <jtv> danilos: well maybe I am, because it is messy.  But old situation: go through all the motions of approving, then check that the entry isn't approved already, and if not, set its status as Approved.
[15:06] <jcsackett> bigjools: fantastic. :-)
[15:06] <sinzui> bigjools, thanks.
[15:06] <danilos> jtv, oh, not really, you are right
[15:06] <jtv> danilos: see?  The old code was carefully designed to confuse and disorient intruders.
[15:06] <danilos> jtv, anyway, it is horrible code
[15:06] <jtv> Now that the Cold War is over, we can ease away from that.  :)
[15:07] <danilos> jtv, heh, yes, a nice improvement there
[15:07] <bigjools> sinzui, jcsackett: you're welcome.  Let me know how you get on.  I may be taking a few hours off and coming back later, I feel like death.
[15:07] <danilos> jtv, anyway, thanks for the fix, I'll get it through ec2 and land
[15:07] <danilos> bigjools, don't go!
[15:08] <jtv> danilos: thanks.  FWIW it got through at least all the Translations pagetests and doctests and all the windmill tests I observed, as well as lp.translations.tests
[15:08] <bigjools> danilos: can I help? :)
[15:09] <jtv> bigjools: wait!  What _does_ death feel like?  We're all not quite dying to know.
[15:09] <danilos> bigjools, no, no, I am good, I am just sad to see you go, get drunk and all those things
[15:10]  * bigjools raises scythe and points at jtv
[15:11]  * jtv ducks
[15:11] <bigjools> danilos: I wouldn't be able to drink if I wanted to, my throat is on fire
[15:14] <danilos> bigjools, oh well, get some rest man, I am sure you'll be back to check on PQM has-closed midnightish :)
[15:14] <bigjools> you'd think :)
[15:18] <mars> wgrant, still around?  You meantioned something about both builders blessing devel and db-devel?
[15:19] <bigjools> mars: apparently that was the case earlier, I think mthaddon is aware?
[15:20] <mthaddon> bigjools: not really - I haven't looked into it at all
[15:20] <bigjools> oh ok, I thought wgrant had told you
[16:45] <jml> jelmer_, what should I do?
[16:46] <jml> jelmer_, trigger a rebuild or actually investigate the source of failure?
[16:46]  * jml suspects an erratic test.
[16:46] <jelmer_> jml: Perhaps trigger a rebuild first?
[16:46] <jelmer_> could the mocking about with the buildbots and their recent restart perhaps be related?
[16:47] <jml> 4 hrs, 4 mins, 56 secs at 20:52:00
[16:47] <jml> jelmer_, probably not.
[16:48] <jml> I suspect the root cause of the problem is TacTestSetup being terrible.
[16:48] <jml> which is actually a mask for a deeper problem with Twisted
[16:48]  * jml frowns
[16:49] <jelmer_> oh, db-devel just broke too, but with different errors
[16:49] <jml> yeah, but danilos warned us about that.
[16:50] <danilos> jelmer_, jml: the fix for that is already in db-devel so I am just forcing a build
[16:51] <danilos> (the same will happen on lucid-db-lp which will actually get us into testfix mode again)
[16:51] <jml> danilos, sweet.
[16:52] <danilos> (this should at least minimize the testfix mode for everyone, and again, I apologize for your potentially failing db-devel ec2 test runs)
[17:15] <sinzui> Anyone available for a quick vote on milestone caching? The choices are remove it all, or leave it for anonymous only
[17:19] <danilos> sinzui, my vote would be that whoever goes and does it decides what to do :) (i.e. weights the pros and cons on both: there's no perfect answer, so voting won't really help much)
[17:21] <sinzui> I prefer keeping anon cache. they cannot change something to see it change. The tests need minor updates to record the cache type.
[17:56] <mars> wgrant, I think we figured out the db-devel landings: I /think/ PQM stopped processing submissions for about 5 hours, so both db-devel landings ended up in the queue, landing right beside each other.
[18:09] <jelmer_> sinzui: I think caching for anonymous users makes sense, as a developer it's confused me a few times
[18:09] <sinzui> thanks jelmer
[18:34] <jml> grr... how do I use pip to install a package from a tarball.
[18:36] <benji> jml: you can probably tell it the directory with the tarball in it is your index
[18:36] <jml> benji, thanks.
[18:36] <benji> jml: oh, wait, it's easier than that: "pip install path/to/mypackage.tgz"
[18:36] <benji> from http://guide.python-distribute.org/usage.html#installing-from-a-tarball
[18:36] <jml> benji, but after my frustrated outburst I just untarred it and installed it with good ol' python setup.py install.
[18:37] <benji> heh
[18:37] <jml> benji, thanks. good to know both the doc & the command for the future
[19:39]  * rockstar lunches
[19:50] <jkakar> deryck: btw, I release Storm 0.17 yesterday.
[19:51] <jkakar> deryck: Do you need anything else before you can upgrade the version of Storm Launchpad is using?
[19:51] <jkakar> deryck: The release is here: https://edge.launchpad.net/storm/trunk/0.17
[19:51] <deryck> jkakar, nope, that's perfect.  Getting my branch blessed now to update us.
[19:52] <jkakar> deryck: Awesome!
[20:18] <sinzui> Does anyone know how to make a view render() with ANONYMOUS in a unit test? passing principal=None does what I expect to the request, but render fails wanting a logged in user
[20:21] <salgado> sinzui, principal=UnauthenticatedPrincipal, maybe?
[20:22] <sinzui> salgado, None cause this to be set:
[20:22] <sinzui> request.setPrincipal(
[20:22] <sinzui>             getUtility(IPlacelessAuthUtility).unauthenticatedPrincipal())
[20:22] <sinzui> salgado,  I think the request is correct, but render() ...
[20:23] <sinzui> oh, maybe I need to login as ANONYMOUS as well as call render with principal=None
[20:24] <salgado> isn't your view expecting a user to be logged in?  iow, is it not a launchpad.AnyPerson view?
[20:26] <sinzui> It is a milestone view and I am trying to update the test to show memcache is only enabled for anonymous uers
[20:28] <sinzui> woot!
[20:29] <sinzui> salgado, I had to login(ANONYMOUS), I was actually logged in as another user from the test setup. I had written the create_initialize_view to have none as the principal...and assumed the latter was the issue
[21:51] <lifeless> mars: hi?
[21:53] <kiko> lifeless, would you care to look at some bzr bugs loic filed and see what you think?
[22:01] <lifeless> url me up
[22:03] <kiko> https://launchpad.net/bugs/593560
[22:03] <_mup_> Bug #593560: Slow performance for many operations on the gcc code import branches <udd> <Bazaar:Confirmed> <https://launchpad.net/bugs/593560>
[22:03] <kiko> https://launchpad.net/bugs/605067
[22:03] <_mup_> Bug #605067: want option to allow uncommit but disallow changing mainline <amd64> <apport-bug> <maverick> <Bazaar:Confirmed> <bzr (Ubuntu):Confirmed> <https://launchpad.net/bugs/605067>
[22:03] <lifeless> so the second I'd already seen, I agree it would be good
[22:03] <lifeless> probably fairly easy too
[22:04] <lifeless> the first bug I've seen too
[22:05] <lifeless> its a bit of a problem bug because its very very wide
[22:05] <kiko> yes, it's annoying
[22:05] <lifeless> we've talked just about the new-tree creation time
[22:06] <lifeless> which is being addressed - john & martin were doing a patch @ the rally to disable accelerator trees (which in this case are a pessimisation), and john has been working on performance on the gcc tree ever since
[22:06] <lifeless> it might be good to file a series of targeted bugs
[22:06] <kiko> lifeless, oh, that's really good to hear -- I think he and loïc didn't sync up then
[22:06] <lifeless> and andrew has just landed a patch that also helps as well
[22:07] <lifeless> by being leaner on the ie objects
[22:07] <kiko> yeah, the one that mark wrote to us about :)
[22:07] <lifeless> right
[22:07] <lifeless> jam's work loads the dirstate faster and reduces memory load from the chk pages
[22:07] <lifeless> its probably going to be 2.3 only
[22:52] <kiko> lifeless, do you know when that's due?
[22:52] <lifeless> 2.2 was just released
[22:52] <lifeless> so 2.3 betas will be coming out soon, and 2.3 itself 6 months
[22:56] <kiko> hmm
[22:56] <kiko> "that's a long time to wait" :-)
[22:57] <lifeless> well
[22:57] <kiko> lifeless, I had one user, ams_cs, who had a commit take 30 minutes the other day, and a few take a couple of minutes
[22:57] <lifeless> you can track betas
[22:57] <kiko> I was surprised -- do you think there's anything pathological he's doing?
[22:57] <kiko> yeah, I should tell them to
[22:57] <lifeless> uhm, its possible that that 30 minute was a complete repack
[22:57] <kiko> yes, that's what he said he thought it was
[22:57] <lifeless> which happens when you click over to a new power-of-10 commits
[22:57] <lifeless> so, if he hit the 1000000
[22:58] <kiko> aha