[01:09]  * wallyworld needs to go buy coffee
[02:14] <wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/die-spr-spn/+merge/105597 may be of interest, if you want a break from auditing. Or it can wait for OCR.
[02:16] <StevenK> wgrant: I'm not auditing, I'm glaring at PackageUpload, hoping it will spontaneously combust.
[02:17] <wgrant> Heh
[02:19] <StevenK> wgrant: Looks excellent, r=me
[02:20] <wgrant> StevenK: Thanks.
[04:30] <lifeless> StevenK: how is auditor coming along ?
[04:36] <StevenK> lifeless: I have an auditorfixture project up on LP, and I was trying to get that working last Monday. I'm about to start poking again.
[04:38] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/populate-spph-pu/+merge/105601 if you can
[04:43] <wgrant> StevenK: Is that a 2.7 vs 2.6 email spacing change I see there?
[04:44] <StevenK> wgrant: Ah, is that why that test was failing?
[04:44] <StevenK> Let me revert that bit.
[04:45] <wgrant> StevenK: Also, what about PCJs?
[04:45] <StevenK> wgrant: I was going to ignore them for now.
[04:46] <wgrant> I wouldn't.
[04:46] <wgrant> That's just asking for trouble.
[04:49] <StevenK> wgrant: Why not? It's a copy, not a new source upload.
[04:52] <wgrant> StevenK: It's still something that gets approved by an archive admin and creates an SPPH
[04:52] <wgrant> And it has a PU
[04:53] <StevenK> May have an PU, based on the code.
[04:54] <wgrant> If it's been approved it has a PU
[05:12] <wgrant> StevenK: Did you know that some tests change SPR.spn? :)
[05:14] <StevenK> Oh, twitch.
[05:15] <StevenK> Soyuz, where immutable means only on production.
[05:27]  * StevenK stabs PCJ.
[06:12] <StevenK> wgrant: http://pastebin.ubuntu.com/986687/ :-(
[06:14] <wgrant> StevenK: Hm?
[06:14] <StevenK> wgrant: Trying to write a test using PCJ to check the PU is actually set.
[06:15] <wgrant> I suspect that your test is buggy.
[06:16] <StevenK> At the moment, it creates a PCJ and then calls .run()
[06:18] <wgrant> StevenK: Perhaps the PCJ is not meant to be proxied.
[07:50] <adeuring> good morning
[10:41] <jamestunnicliffe> Hi, I am trying to QA https://bugs.launchpad.net/launchpad/+bug/998052 and I have a demo page at https://qastaging.launchpad.net/~linaro-infrastructure/+upcomingwork running
[10:41] <_mup_> Bug #998052: Upcoming Work View now showing all desired work items <qa-needstesting> <Launchpad itself:Fix Committed by dooferlad> < https://launchpad.net/bugs/998052 >
[10:42] <jamestunnicliffe> I would like to have https://blueprints.qastaging.launchpad.net/linaro-infrastructure-misc/+spec/setup-freescale-click-through retargetted + approved. I can change who owns the blueprint, but as soon as I do, I lose the ability to approve it.
[10:42] <jamestunnicliffe> Anyone have super-powers who could do that?
[10:45] <jamestunnicliffe> Sorry, wrong language, re-target the blueprint. It is supposed to be a duplicate of https://blueprints.launchpad.net/linaro-android/+spec/setup-freescale-click-through
[10:46] <wgrant> jamestunnicliffe: Why does that need superpowers?
[10:47] <jamestunnicliffe> Once I re-target to another project I don't have a button to set the "Direction" field.
[10:47] <jamestunnicliffe> wgrant: I think that Direction needs to be set to approved for it to show up on the page I am testing.
[10:49] <wgrant> I don't see how the target is relevant here.
[10:50] <wgrant> What behaviour are you trying to verify?
[10:51] <jamestunnicliffe> https://qastaging.launchpad.net/~linaro-infrastructure/+upcomingwork should show approved blueprints that involve people from linaro-infrastructure
[10:52] <rick_h_> morning party people
[10:52] <wgrant> https://qastaging.launchpad.net/~linaro-infrastructure/+upcomingwork already shows the one you linked.
[10:52] <wgrant> I don't see how the target is relevant to this.
[10:52] <jamestunnicliffe> wgrant: yes, but if I retarget...
[10:52] <jamestunnicliffe> wgrant: hang on
[10:53] <wgrant> Oh, the milestone?
[10:53] <jamestunnicliffe> yep
[10:53] <wgrant> The target could refer to the product, the series, or the milestone :)
[10:53] <jamestunnicliffe> wgrant: :-) Sorry, getting used to the language!
[10:54] <jamestunnicliffe> So, now https://blueprints.qastaging.launchpad.net/linaro-android/+spec/setup-freescale-click-through is a Linaro Android blueprint, but not showing up on  https://qastaging.launchpad.net/~linaro-infrastructure/+upcomingwork
[10:55] <jamestunnicliffe> I think the blueprint just needs approving (I could be wrong)
[10:55] <wgrant> So, you can probably convince a WebOps  to poke these things for you.
[10:55] <wgrant> Although the premise of both of those blueprints is quite nauseating.
[10:55] <jamestunnicliffe> don't shoot the messenger - I just present the data.
[10:56] <wgrant> webops: Can you help jamestunnicliffe with poking a few blueprint fields on qas?
[10:58] <wgrant> Ah, lunch has taken gnuoy.
[10:58] <wgrant> jamestunnicliffe: It could be a while.
[10:58] <jamestunnicliffe> wgrant: No worries. Thanks for helping.
[11:02] <jamestunnicliffe> webops: Change to ^^ request. https://qastaging.launchpad.net/linaro-android/+milestone/12.05 just needs a due date at the end of the month.
[11:09] <danilos> jamestunnicliffe, fwiw, BPs don't need to be approved, but they need to be assigned to someone in the team and targetted to a milestone with a date set in the future
[11:09] <jamestunnicliffe> danilos: Yea, I looked at the source and found that out, hence the change to the above request :-)
[11:12] <wgrant> jamestunnicliffe: Anyone in ~linaro-maintainers should be able to change that.
[11:12] <wgrant> Or ~linaro-drivers
[11:12] <danilos> jamestunnicliffe, I've changed the milestone for a BP there
[11:13] <danilos> jamestunnicliffe, fwiw, for qaing this, you could have simply assigned a workitem or two to someone outside the team
[11:15] <danilos> jamestunnicliffe, it also looks qa-ok to me, I used wgrant as the outside-the-team assignee, and it looks fine
[11:16] <jamestunnicliffe> danilos: Yea, I did, and that worked, but I wanted to be paranoid and examine a BP that was for another team to show that we see the remote blueprint as expected.
[11:17] <danilos> jamestunnicliffe, right, but that's a different functionality and should already be working: if it's not, it's nothing this fix broke :)
[11:17] <jamestunnicliffe> danilos: Clearly I like doing more work than I need to :-)
[11:18] <danilos> jamestunnicliffe, that's ok, there's always more work to do
[11:18] <danilos> jamestunnicliffe, just in case, I tested that too, and now the outside contributor doesn't show up, which is fine :)
[11:18] <danilos> jamestunnicliffe, I think you can mark the bug as 'qa-ok' now
[11:19] <jamestunnicliffe> danilos: Will do.
[11:20] <wgrant> Thanks guys.
[11:22] <danilos> yw
[12:54] <rick_h_> anyone have a hint why my tests that assert an exception is raised come out of the test runner as errors?
[12:54] <rick_h_> https://pastebin.canonical.com/65934/ for instance
[12:57] <rick_h_> I get the error with either the assertRaises or the with ExpectedException usage
[13:01] <wgrant> rick_h_: That's a security proxy blocking your attribute access. You'll want a 'with person_logged_in(someone):' around it.
[13:03] <wgrant> rick_h_: Oh, bah, I see you're actually checking for that.
[13:03] <rick_h_> wgrant: right, I've got 5 tests that are checking access expecting the exception but showing Error in the test runs
[13:03] <wgrant> rick_h_: But the security proxy raises the exception when you try to getattr transitionToStatus.
[13:03] <wgrant> Not when you call transitionToStatus
[13:03] <wgrant> rick_h_: What are you trying to do?
[13:04] <rick_h_> that's right, let me look closer. I know I fixed one of these with the context manager, but that one is failing the same way
[13:04] <wgrant> transitionToStatus should be callable by any logged in user.
[13:04] <rick_h_> wgrant: this is me trying to finish getting the bugtask tests moved over. Some were doctests, some were existing.
[13:04] <wgrant> So it shouldn't raise Unauthorized.
[13:04] <rick_h_> wgrant: so they're existing tests, I know a couple are around setting something private.
[13:04] <wgrant> You want to use the context manager here.
[13:04] <wgrant> Ah
[13:05] <rick_h_> I'll poke at them closer, thanks for the reminder on the "exception in getattr vs the actual access" kind of thing from once before
[13:05] <wgrant> rick_h_: Any logged-in user can edit tasks filed on distros as long as the bug
[13:05] <wgrant> is not marked private. So, as an anonymous user, we cannot edit
[13:05] <wgrant> Is that the test you've ported?
[13:05] <wgrant> anything:
[13:06] <rick_h_> wgrant: so one of them is this one: https://pastebin.canonical.com/65939/
[13:06] <wgrant> That exception there is triggered by not being logged in and accessing transitionToStatus. So I'd either drop the test or say "self.assertRaises(Unauthorized, getattr, distro_task, 'transitionToStatus')"
[13:07] <wgrant> Also, why are you destroying the doctest?
[13:07] <rick_h_> and gets this: https://pastebin.canonical.com/65940/
[13:07] <rick_h_> wgrant: LoC credit I needed for that work around the bug nomination timeout work
[13:08] <wgrant> As much as I hate doctests, splitting them up into unit tests without refactoring the rest of the existing unit tests generally just results in longer code and 10x or worse slower tests.
[13:08] <rick_h_> moving doctest to unit test and cleaning up dupe tests between existing model/test_bugtask
[13:08] <wgrant> If you're doing that too, excellent :)
[13:08] <rick_h_> wgrant: yea, there's definitely some disjoint since the doctests all work around the fixture db data while the unit tests tend to factory
[13:08] <wgrant> Right, and per-test DB setup is not trivial, either.
[13:09] <wgrant> It would be fine if our unit tests were unit tests.
[13:09] <wgrant> But they're not.
[13:09] <rick_h_> so not sure it'll be as pretty as it should be, but need to move on past this atm and these last few errors around the exceptions are killing me
[13:09] <rick_h_> need more coffee for my monday morning I guess
[13:09] <rick_h_> wgrant: oh definitely agree on that point :)
[13:09] <wgrant> rick_h_: https://pastebin.canonical.com/65939/ doesn't work?
[13:10] <rick_h_> wgrant: right, it's throwing: https://pastebin.canonical.com/65940/
[13:12] <wgrant> rick_h_: What if you drop the '' in the ExpectedException?
[13:12] <rick_h_> wgrant: let me run that again, I think I tried it, but maybe not on this test, without success
[13:14] <rick_h_> wgrant: yea, same error
[13:14] <rick_h_> I'm tempted to throw it at an ec2 test and see if it's just something strange locally since it really doesn't make a ton of sense
[13:14] <wgrant> rick_h_: What if you use the assertRaises/getattr example I gave above?
[13:14] <rick_h_> wgrant: will try that
[13:17] <rick_h_> wgrant: so https://pastebin.canonical.com/65942/
[13:17] <wgrant> rick_h_: Are you sure you have the right Unauthorized?
[13:17] <wgrant> It's not an HTTP Unauthorized or something?
[13:18] <wgrant> You want zope.security.interfaces.Unauthorized
[13:18] <rick_h_> wgrant: oooooh, crap you're right.
[13:18] <rick_h_> from lazr.restfulclient.errors import Unauthorized
[13:18] <wgrant> Heh
[13:18] <wgrant> That would do it.
[13:18] <rick_h_> see, more coffee...I knew it
[13:18] <rick_h_> dude, thanks, been staring at this for a chunk of time this morning
[13:19] <wgrant> np, i think everyone's fallen into that trap a few times...
[14:12] <jcsackett> rick_h_: so, you asked me to check out the watch_jsbuild thing last week. i can tell you that it appears to not do anything on my machine. it notes changes, but doesn't rebuild anything.
[14:12] <jcsackett> am i misunderstanding its use?
[14:13] <rick_h_> jcsackett: no, it should auto copy your file to the build dir, minify it, etc
[14:13] <rick_h_> on save
[14:13] <rick_h_> jcsackett: I'll try to check it out and test, I know I was using it at one point
[14:15] <jcsackett> rick_h_: hm, actually, may be caching issues.
[14:15] <jcsackett> in which i case, i apologize for besmirching your work. :-P
[14:16] <rick_h_> jcsackett: heh, well the thing to do is ls the build dir and you shuold see the filetimes update
[14:16] <rick_h_> at bare min
[14:22] <jcsackett> rick_h_: hrm, yeah, i don't think i'm seeing that. i *do* get a message of "new path /builddir/path/to/file/i/edited/"
[14:23] <jcsackett> anyway--no big, just letting you know since you were curious last week. i may have time to poke at it myself, cause it would help a lot of the work i'm doing. :-)
[14:23] <rick_h_> jcsackett: k, I'll give it a quick go and dbl check nothing broke it recently
[14:39] <rick_h_> jcsackett: hmm, working here. http://paste.mitechie.com/show/665/
[14:39] <rick_h_> jcsackett: wonder if it's some subdir issue? You working in a different file location?
[14:49] <jcsackett> rick_h_: i suppose it could be. my working path is lib/lp/app/javascript/banners.
[14:50] <rick_h_> jcsackett: so the 'new file' path was build/js/lp/app/banners/somefile.js ?
[14:51]  * jcsackett nods
[14:51] <jcsackett> make jsbuild grabs it properly--they work off different path definitions?
[14:51] <rick_h_> just that it maps from source tree to build tree
[14:51] <rick_h_> notice that it's lp/app/banners (sans /javascript)
[14:52] <jcsackett> right, i meant do the two make commands work off different definitions.
[14:52] <jcsackett> like, could watch not be finding things exaclty the same way as jsbuild
[14:53] <rick_h_> no, but if the JS files were in a strange place (used to have things not in $Module/javascript) it could go into a strange place
[14:53] <rick_h_> so just making sure your new files are in the "normal" JS paths now
[14:59] <jcsackett> rick_h_: by normal, do you mean everything should be module/javascript/jsfile? or is module/javascript/subdir/jsfile valid?
[15:00] <rick_h_> jcsackett: subdir is fine
[15:00] <rick_h_> I just mean it's not module/geodata/javascript/something.js
[15:00] <jcsackett> rick_h_: ok. then the code i'm working on should be fine.
[15:00] <jcsackett> rick_h_: anyway, like i said, not hugely important now. i've made a note for myself that these files aren't auto building right, and i'll look into it later. thanks!
[15:00] <rick_h_> jcsackett: right, sounds like it should be ok
[15:00] <rick_h_> jcsackett: yea, just wanted to let you know my quick test did work
[15:05] <sinzui> danhg. Do you want to talk about text changes?
[15:07] <danhg> hey sinzui - sure, are you free in 45 mins?
[15:07] <sinzui> yes
[15:24] <deryck> rick_h_, I moved the last convoy card to done-done. nothing left there for opening for ~launchpad, right?
[15:24] <rick_h_> deryck: correct
[15:24] <rick_h_> welcome to combo loader everyone bwuhahaha
[15:42] <rick_h_> abentley: ok, I think I've got this ready to go: https://code.launchpad.net/~rharding/launchpad/diedoctests_bugtask/+merge/105502https://code.launchpad.net/~rharding/launchpad/diedoctests_bugtask/+merge/105502
[15:43] <rick_h_> abentley: let me know where to send the 'oversized diff' beverage payment
[15:43] <abentley> rick_h_: ACK.  I'll have a look in a couple of minutes.
[15:49] <abentley> adeuring: Could you please review https://code.launchpad.net/~abentley/lazr.jobrunner/add-missing-jobs/+merge/105680 ?
[15:49] <adeuring> abentley: sure
[15:49] <abentley> adeuring: Thanks.
[16:02] <adeuring> abentley: connection.drain_events(timeout=.1 ** 100) scared me at first glance: seemed to be a huge number ... until i spotted the tiny '.' ;) what about '0.1 ** 100' ?
[16:02] <abentley> adeuring: sure.
[16:06] <adeuring> abentley: r=me. nice & useful stuff!
[16:06] <abentley> adeuring: Thanks!
[17:23] <stub> gary_poster: Have you been using amd64 or i386 when that textsearching.txt failure has occurred?
[17:24] <gary_poster> stub, I saw your bug comment.  the test machines all run amd64.  I don't know what benji is running (back tomorrow). I have no idea why you can't dupe.  I'll ask Benji to try and dupe what you've done and then gradually add the other workarounds lxc needs to work for other tests to see if one of them triggers anything.
[17:25] <gary_poster> I think he sees it once every 5 or 10 runs
[17:25] <stub> gary_poster: It could be load, which will be a right bugger to replicate :-/
[17:26] <stub> I suspect I am running on cheaper and slower toys
[17:26] <gary_poster> stub, load: yeah, that would kinda suck.  I think benji's laptop is not a scream machine.
[17:26] <gary_poster> It was fast three years ago I think
[17:26] <gary_poster> 2.5
[17:27] <stub> so my desktop may be better
[17:27] <gary_poster> yes
[17:27] <stub> my spinning metal platter is my bottleneck I think
[17:28] <gary_poster> hm.  stub, benji might have been using mxc-start-ephemeral
[17:28] <gary_poster> lxc
[17:28] <gary_poster> that would get rid of the spinning platter
[17:28] <stub> Ok. If you have any thoughts, I can try things again tomorrow.
[17:29] <gary_poster> ack, stub.  I'll hold off bothering you about it further till benji and I consult.  thanks again.
[17:29] <stub> I know not this ephemeral wizardry but can work it out tomorrow if that looks like a trigger.
[17:29] <stub> k
[17:29] <gary_poster> cool
[18:40] <lifeless> gary_poster: you could give stub access to the dc test machine, perhaps
[18:56] <gary_poster> lifeless, good idea, thanks.
[19:16] <sinzui> abentley, what is the ETA for celery running in production?
[19:18] <abentley> sinzui: abel is working on getting the necessary changes deployed.  It may already be done, or may be done tomorrow.
[19:18] <sinzui> abentley, rock
[19:18] <sinzui> thank you
[19:18] <abentley> sinzui: np.
[19:19] <abentley> sinzui: It's actually deployed on production, but the fast-lane/slow-lane wasn't configured properly, so jobs that took too long would go into the ether.
[19:19] <abentley> sinzui: That's what abel's fixing.
[19:19] <sinzui> excellent/ Thank you for the explanation.
[19:21] <abentley> rick_h_: I think we should file a bug that these unit tests are still doctestty, tag it tech-debt and add FIXMEs to the relevant TestCase classes.  That would make me feel better about approving this.
[19:22] <rick_h_> abentley: ok
[19:23] <abentley> rick_h_: Do you know our https://dev.launchpad.net/PolicyandProcess/XXXPolicy ?
[19:23] <rick_h_> abentley: I've seen it, not had a big cause to use it. So I will review
[19:30] <abentley> rick_h_: target_uses_malone was already sufficiently unit-tested?
[19:30] <rick_h_> abentley: looking
[19:31] <rick_h_> abentley: there's a negative test case in assertBugTaskIsPendingBugWatchElsewhere
[19:31] <rick_h_> abentley: it's not completely the same, but the initial test seemed rather superficial so yes, considered it a match
[19:31] <abentley> rick_h_: cool.
[19:36] <abentley> rick_h_: similar_bugs already unit-tested?
[19:36] <rick_h_> abentley: looking
[19:37] <gary_poster> lifeless, testr is behaving a bit strangely in the DC, but they are not using the versions of testr and its dependencies that we are, so I'm not sure if it is simply that problem.  In any case, it would be great to have the releases of subunit, testrepository, and testtools done for now and for the future.  I saw that the last subunit build failed in the testing cabal's PPA.  Do you know anything about that?  Should
[19:37] <gary_poster>  I trying pinging jelmer, or should I try assigning someone from my squad to help?  And finally, were you planning on trying to get a precise SRU for these changes because it fixes tag handling in many ways?  That would be the easiest sell for IS, I think.
[19:37] <lifeless> OTP sorry
[19:38] <abentley> rick_h_: login_foobar is only used once.  Is it needed?
[19:38] <rick_h_> abentley: hmm, looks like I lost similar bugs somehow. Wonder if it didn't make the split between bugtask and bugtaskset. Will find a home
[19:39] <rick_h_> abentley: I thought that was removed...me looks for login_foobar again
[19:39] <gary_poster> np, will step away myself.  biab.  FWIW, the strange behavior: I get a seemingly full test run, with a nice big list of subunit output and a failure correctly rendered, but testr failing gives me simply "id=3, tests=0" even though I know we had lots of tests and at least one failure.
[19:39] <abentley> rick_h_: near TestCountsForProducts
[19:39] <gary_poster> lifeless, when you are off the phone, that was directed at you too ^^  :-)
[19:39] <rick_h_> abentley: ah in the bugtaskset, no, it's not. I removed it from the bugtask because of infrequent use and missed the other file
[19:47] <allenap> deryck[lunch]: When you're back, perhaps you or another Orange could take a look at https://code.launchpad.net/~allenap/postgresfixture/it-begins/+merge/105708? I won't be around to field questions, but I'll address them in my morning.
[20:17] <deryck> allenap, sure, I'll take a look
[20:17] <bac> lifeless: when you're available i'd like to get some advice on bug 998040.
[20:17] <_mup_> Bug #998040: lp.codehosting.tests.test_bzrutils.TestGetBranchStackedOnURL.testGetBranchStackedOnUrlNotStacked(RemoteBranchFormat-v2) fails rarely/intermittently in parallel tests <paralleltest> <Launchpad itself:Triaged> < https://launchpad.net/bugs/998040 >
[20:22] <rick_h_> abentley: I've pushed changes with the various items we chatted about + the simillar bugs add in. Diff is updating. https://code.launchpad.net/~rharding/launchpad/diedoctests_bugtask/+merge/105502
[20:22] <rick_h_> abentley: I'm hitting EOD and need to get the boy, let me know of anything else and I'll update and try to get out in the morning.
[20:22] <abentley> rick_h_: I don't think there was anything else.  similar_bugs was the blocker.
[20:23] <rick_h_> abentley: ok, cool
[20:24] <rick_h_> abentley: thanks for catching that one btw.
[20:24] <abentley> rick_h_: Note that with these changes, your LoC only decreases by 61.
[20:24] <rick_h_> abentley: right, they start at line 1943
[20:26] <rick_h_> abentley: but according to the https://dev.launchpad.net/PolicyAndProcess/MaintenanceCosts/HitList just converting doctest to unit tests is considered some form of LoC credit and just should just offset things with https://code.launchpad.net/~rharding/launchpad/bugnom_874250/+merge/105317
[20:28] <abentley> rick_h_: Oh, that's not what I thought was meant by that.  I thought that converting doctests to unit tests was expected to decrease LoC.
[20:29] <rick_h_> abentley: ah, see I read that as reducing doctests was good form of reducing maint. w/o necessarily reducing lines of code
[20:29] <rick_h_> since resetting up data/etc that doctests do throughout might actually lean towards an increase in LoC
[20:29] <abentley> rick_h_: In any case, it squeeks by.
[20:29] <rick_h_> :)
[20:30] <rick_h_> ty much for suffering the long review, appreciate it a ton
[20:30] <abentley> rick_h_: Nope, bad math on my part.  67 > 61.
[20:36] <lifeless> gary_poster: hi, off the phone
[20:37] <lifeless> bac: you're in the queue
[20:37] <lifeless> gary_poster: I'd be delighted to see an SRU, I wasn't planning on doing one myself.
[20:37] <rick_h_> abentley: ok, I'm out. If you get a sec to check and flip the needs fixing bit appreciate it
[20:37] <lifeless> gary_poster: I do think you should get the latest testr etc, in the DC you can run them unpackaged to eliminate them as issues.
[20:38] <lifeless> gary_poster: (install to ~/local/python etc, then add that to PYTHONPATH & away you go)
[20:38] <lifeless> bac: hi hi
[20:38] <bac> hi lifeless
[20:39] <bac> so i've been looking at bug 998040 but cannot reproduce it.  i was wondering if you had any thoughts on the cause
[20:39] <_mup_> Bug #998040: lp.codehosting.tests.test_bzrutils.TestGetBranchStackedOnURL.testGetBranchStackedOnUrlNotStacked(RemoteBranchFormat-v2) fails rarely/intermittently in parallel tests <paralleltest> <Launchpad itself:Triaged> < https://launchpad.net/bugs/998040 >
[20:40] <lifeless> gary_poster: on subunit w/python3 - I'm not sure whats up there, Jelmer was hoping to look at it this week. If you want to ask someone to do so that would be grand; make distcheck was broken in trunk, so there was an issue with the 0.0.8 tarball, but trunk should be better, though it hasn't fixed the ppa builds so probably unrelated.
[20:40] <lifeless> bac: ah, its a concurrent import issue
[20:41] <lifeless> bac: I WAG that there is a test that triggers the import, *and* uses an in-process thread helper
[20:41] <gary_poster> ack thanks lifeless
[20:41] <lifeless> bac: (which the bzr test framework will do)
[20:41] <lifeless> bac: there is a bug, let me grab it
[20:42] <lifeless> bac: bug 593536
[20:42] <_mup_> Bug #593536: Test failure: IllegalUseOfScopeReplacer: ScopeReplacer object 'ui' was used incorrectly <babune> <Bazaar:Confirmed> < https://launchpad.net/bugs/593536 >
[20:42] <lifeless> brb
[20:42] <bac> lifeless: any ideas on what to look for?
[20:42] <lifeless> bac: the root cause is that bzr doesn't support concurrent dereferences to the scope replacer
[20:42] <lifeless> it should
[20:42] <lifeless> there is an MP up and all
[20:42] <lifeless> it may even be fixed in bzr trunk.
[20:43] <lifeless> or it may be stuck in review hell.
[20:43] <gary_poster> lifeless, for subunit question, the other half of my question was whether you plan to make a Precise SRU for all those packages once you release. Have you decided?
[20:43] <lifeless> I have to put cynthia down for a nap, will dig more details later if you have no joy.
[20:43] <lifeless> gary_poster: 08:37 < lifeless> gary_poster: I'd be delighted to see an SRU, I wasn't planning on doing one myself.
[20:43] <lifeless> gary_poster: (no, I'm not going to do the SRU myself)
[20:43] <gary_poster> lifeless, bah, saw only one reply thanks
[20:43] <bac> thanks lifeless, the link to that bug is great
[20:43] <lifeless> gary_poster: oh,there are like 5 lines to you :)
[20:43] <lifeless> gotta go, back in a bit
[20:44] <gary_poster> cool thanks
[20:51] <lifeless> back
[20:52] <lifeless> I've commented in that bug
[20:54] <bac> lifeless: you mentioned a MP for bug 593536 -- i can't find anything
[20:54] <_mup_> Bug #593536: Test failure: IllegalUseOfScopeReplacer: ScopeReplacer object 'ui' was used incorrectly <babune> <Bazaar:Confirmed> < https://launchpad.net/bugs/593536 >
[20:57] <lifeless> let me look at trunk's changelog
[21:00] <lifeless> bac: revno: 6426 [merge]
[21:00] <lifeless> committer: Patch Queue Manager <pqm@pqm.ubuntu.com>
[21:00] <lifeless> branch nick: +trunk
[21:00] <lifeless> timestamp: Thu 2012-01-05 11:06:47 +0000
[21:00] <lifeless> message:
[21:00] <lifeless>   (gz) Make lazy imports proxy by default so that concurrent resolution is
[21:00] <lifeless>    robust (Martin Packman)
[21:00] <lifeless> bac: so it looks like its fixed as of rev 6426
[21:01] <lifeless> bac: so 2.6 has the fix
[21:02] <lifeless> bac: we could upgrade to 2.6bwhatever, or backport the fix.
[21:02] <bac> lifeless: ah, great.
[23:06] <lifeless> allenap: ping
[23:07] <lifeless> nvm, I've replied in the MP
[23:27] <wgrant> Blah
[23:27] <wgrant> I wish we would do away with the subdomains :(
[23:30] <huwshimi> wgrant: If I remember correctly, removing subdomains will remove a maintenance/codebase burden. However, subdomains were added to make the workflow better (switching between apps/projects). If we can show that this is no longer the case and that the workflow is better without them then I think we would probably be in a good position to make it happen.
[23:31] <wgrant> Remove a maintenance burden and increase performance :)
[23:31] <lifeless> huwshimi: We could probably generate data showing that folk don't manually change the domain
[23:32] <lifeless> huwshimi: (by looking for referrer rather than direct entry after a same-url different-domain page from the same user
[23:32] <wgrant> In my branches 6 months ago to remove subdomains, the behaviour of the tabs is not changed at all.
[23:32] <lifeless> huwshimi: that would show (if it does), that the links are what matter, and as wgrant says, we can preserve those easily.
[23:32] <wgrant> So it only affects people who change the URL manually.
[23:34] <wgrant> Plus it gets rid of stuff like https://code.launchpad.net/launchpad/+bug/1234
[23:34] <_mup_> Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts <lp-foundations> <Launchpad itself:Fix Released by debonzi> < https://launchpad.net/bugs/1234 >
[23:34] <wgrant> Bugs tab, Code breadcrumb, code domain.
[23:34] <wgrant> Yay
[23:53] <wgrant>          ->  BitmapOr  (cost=104.26..104.26 rows=11717 width=0) (actual time=218.365..218.365 rows=0 loops=1)
[23:53] <wgrant>                ->  Bitmap Index Scan on temp_bugtaskflat  (cost=0.00..26.47 rows=5859 width=0) (actual time=217.475..217.475 rows=55302 loops=1)
[23:53] <wgrant>                      Index Cond: (access_grants && $0)
[23:53] <wgrant>                ->  Bitmap Index Scan on temp_bugtaskflat2  (cost=0.00..71.94 rows=5859 width=0) (actual time=0.884..0.884 rows=1203 loops=1)
[23:53] <wgrant>                      Index Cond: (access_policies && $1)
[23:53] <wgrant> GIN makes for pretty plans.
[23:56] <james_w>