[00:37] <cjwatson> upgrading mawson for some QA
[00:39] <cjwatson> actually, maybe I can do this on qas - never mind, won't *hurt* to have dogfood more up to date
[00:41] <StevenK> cjwatson: Doing QA after midnight?
[00:42] <cjwatson> if I'm awake anyway
[00:44] <wgrant> cjwatson: Can you tell me when you're done, please?
[00:48] <cjwatson> wgrant: dogfood upgrade finished - sorry if I got in your way
[00:51] <wgrant> cjwatson: Not significantly :)
[00:51] <wgrant> Thanks.
[02:13] <StevenK> % grep -m 1 def lib/lp/code/tests/test_branch_webservice.py
[02:13] <StevenK>     def test_createMergeProposal_fails_if_reviewers_and_review_types_are_different_sizes(self):
[02:13]  * StevenK eyerolls
[02:14] <lifeless> mwhudson: I havdn't. Thanks.
[02:17] <mwhudson> lifeless: i found it very interesting
[02:32] <wallyworld_> lifeless: your branch in bb now. let's hope nothing goes wrong in the next 5 hours :-)
[02:33] <cody-somerville> mwhudson, Are you still working on that project group milestone bug fix?
[02:34] <mwhudson> cody-somerville: not really
[02:34] <mwhudson> cody-somerville: i'm certainly not doing it on work time
[02:35] <lifeless> thakns wallyworld_
[02:35] <wallyworld_> np
[03:02]  * cjwatson gets out of the way of lifeless' deployment pipeline steamroller.
[03:26] <wallyworld_> wgrant: if you get a chance later, could you run this on df https://pastebin.canonical.com/6714 ... it's a standard person vocab query but with an extra left join from person to account
[03:27] <wgrant> wallyworld_: That looks like it's missing a digit.
[03:27] <wgrant> Hm
[03:27] <wgrant> Although that is a very old person vocab query.
[03:27] <wgrant> Which probably won't work on the current schema.
[03:27] <wgrant> Is that just a coincidence?
[03:27] <wgrant> Incredible.
[03:27] <wallyworld_> that's what a standard test runs
[03:28] <wgrant> wallyworld_: Your paste URL is from 2008
[03:28] <wallyworld_> i just logged sql when running a test
[03:28] <wgrant> It's a Launchpad pillar search query
[03:28] <wallyworld_> ffs, sorry https://pastebin.canonical.com/67141/
[03:28] <wgrant> It's a remarkable coincidence.
[03:28] <wallyworld_> huh
[03:29] <wgrant>  Total runtime: 127.058 ms
[03:29] <wallyworld_> seems ok i guess for a vocab query? i'll paste the version without the account left join
[03:29] <wgrant> Nice move with the CTE
[03:29] <wgrant> Yeah
[03:29] <wgrant> It's an effective planner barrier.
[03:30] <wgrant> So it almost forces a good plan.
[03:30] <wgrant> Anyway, I'm wandering off for a while -- be back in 30 or so.
[03:31] <wallyworld_> https://pastebin.canonical.com/67142/
[03:31] <wallyworld_> ok
[03:31] <wallyworld_> the cte was already there
[03:31] <wgrant> wallyworld_: Within 2ms of the same time
[03:32] <wallyworld_> wgrant: excellent, thanks
[03:32] <wgrant> The account filtering is done afterwards on an average of about 102 people, so it's trivial.
[03:32] <wgrant> Really gone now.
[03:32] <wallyworld_> shoo
[04:01] <StevenK> wallyworld_: https://code.launchpad.net/~stevenk/launchpad/branch-information_type-factory/+merge/108094
[04:04] <wallyworld_> StevenK: info type defaults to public, right? ie if left unspecified in factory call?
[04:09] <StevenK> wallyworld_: No, it defaults to None, which means don't override it
[04:10] <StevenK> In the old code private=False ended up being an no-op
[04:12] <StevenK> wallyworld_: If it defaulted to PUBLIC, If you said makeBranch(product=private_product) the branch would get created as USERDATA and then overridden to PUBLIC.
[04:41] <lifeless> mwhudson: thanks for the link
[04:44] <lifeless> "The subtle beauty of a consistent system is that the invariants tend to hold even when the designer does not know what they are."
[04:44] <lifeless> awesome
[04:50] <mwhudson> lifeless: i thought you'd like it
[04:50] <mwhudson> the commutative datatypes sound interesting too
[05:04]  * StevenK stabs update-cache
[05:06] <StevenK> wallyworld_, wgrant: https://code.launchpad.net/~stevenk/launchpad/no-makebugtask-private/+merge/108096
[05:09] <wgrant> StevenK: There was really only one callsite?
[05:10] <StevenK> Only one callsite that did makeBugTask(private=True), yeah
[05:10] <wgrant> Approved
[05:51]  * wallyworld_ just went out a bought a new Galaxy S3 \\o/
[05:51] <StevenK> wallyworld_: And sold the new laptop to pay for it?
[05:51] <wallyworld_> nah, that's what credit cards are for :-)
[05:52] <StevenK> Oh, so your plan is to pay for it eventually
[05:52] <wallyworld_> but i have to get a micro sim :-(
[05:52] <wallyworld_> yeah , sometime by 2025
[05:52] <wallyworld_> but i am really bad at waiting
[05:52] <StevenK> wallyworld_: Naughty. I pay my credit card off in full every month.
[05:52] <wallyworld_> i try to, but i spend too much money i don't have
[05:53] <StevenK> Well, that's the root cause, isn't it? Don't spend money you don't have. :-)
[05:54] <wallyworld_> but it's new and shiny and i wanted it and i couldn't wait
[05:54] <StevenK> Didn't your mother ever teach that "I want never gets" ?
[05:55] <wallyworld_> nope :-)
[05:55] <StevenK> Haha
[05:55]  * wallyworld_ decides whether to get a box cutter to try and make the old sim card fit
[05:55] <StevenK> Hahaa
[07:05] <adeuring> good morning
[07:11] <lifeless> wallyworld_: thanks for your assistance this morning
[07:11] <lifeless> noodles775: https://dev.launchpad.net/Running/LXC
[07:11] <lifeless> noodles775: may help with your development environment
[07:15] <wallyworld_> lifeless: no problem, i did very little. i hope everything works well.only 1 hr till bb finishes :-)
[08:40] <mwhudson> "New code import: nyancat/trunk"
[08:40] <StevenK> Twitch
[08:42] <mwhudson> yes
[08:53] <bigjools> !
[08:56]  * jml googles nyancat
[08:57] <mwhudson> jml: don't do it!
[08:58] <gmb> mgz, You said something yesterday about bzr using a separate pipe for subunit output. Where can I look to find out how you actually go about doing that in a safe, sane, clean and above all quick-to-implement way (note that none of the above values have actually to be true).
[08:58] <jml> mwhudson: it's a repetitive, high-pitched cat-cake rainbow thing
[08:58] <mwhudson> jml: yes
[08:59] <mwhudson> jml: congratulations on not knowing about this particularly useless internet meme until now
[09:00] <jam1> sinzui: when you're around, I'm having a funny bug wrt launchpad answers. I set myself as an answers contact, and I see myself on https://answers.launchpad.net/launchpad
[09:00] <jam1> however, I *don't* see myself on any given question (like: https://answers.launchpad.net/launchpad/+question/198964)
[09:00] <jml> gmb: why not insist on a just, fair, true and loyal implementation?
[09:00] <jam1> though francis said he could see me on the list
[09:00] <jml> mwhudson: thanks :)
[09:00] <jam1> and... I'm not getting emails for new requests, I do seem to get posts to old ones
[09:00] <gmb> jml, I will accept fair, true and loyal, as long as I can have peace, respect for all, free love and a hard-boiled egg.
[09:01] <jml> gmb: I'm afraid I rather insist on having my eggs soft-boiled, old chap.
[09:01] <gmb> Well, no-one's perfect.
[09:03] <jml> hey
[09:03] <jml> what difference is there between LaunchpadZopelessLayer and ZopelessDatabaseLayer that might affect mail?
[09:04] <wgrant> Not much.
[09:04] <wgrant> Unless it uses the librarian...
[09:05] <jml> I guess this must, somehow.
[09:05] <jml> As when I switched it to use ZDL, the failures I got were about mail not being sent.
[09:05] <wgrant> Huh
[09:06] <wgrant> I don't think we change the mail config in LaunchpadLayer...
[09:06] <wgrant> If anything, I'd expect it to send less mail.
[09:07] <jml> anyway, I guess I'll push that forward to another patch
[09:07] <jml> oh
[09:07] <jml> james's thing
[09:07] <wgrant> james's thing?
[09:08] <jml> wgrant: https://code.launchpad.net/~james-w/launchpad/drop-filecmp/+merge/108021
[09:08] <czajkowski> jam: want to mumble and I can talk you through it
[09:10] <jam> czajkowski: I'm on now
[09:12] <jam> czajkowski: I only hear static when you talk
[09:12] <czajkowski> hmm
[09:13] <jam> we can just do IRC if you prefer
[09:13] <jam> also, I'd like to document it somewhere, so someone else in the future has access to it
[09:27] <jml> anyone already have a simple script to check current loc score for a branch?
[09:27] <jml> otherwise I'll hack one up with diffstat, cut & dc
[09:27] <gmb> jml, If you find one, let me know. I've got a slack-time card for it.
[09:27] <gmb> Haven't got round to it yet.
[09:27] <gmb> *find or make
[09:28] <cjwatson> http://paste.ubuntu.com/1016103/ (~/bin/diffstat-loc-delta here) postprocesses diffstat to a single number
[09:28] <cjwatson> (yeah, it's perl, bite me)
[09:28] <cjwatson> or you could probably repurpose bits of loc-contributions in lp-dev-utils
[09:28] <jml> cjwatson: heh
[09:28] <cjwatson> which is vastly more overengineered
[09:29] <jml> cjwatson: at least it's strict perl
[09:32] <cjwatson> loc-contributions gets kind of confused if you run it in a non-devel branch and (I think) attributes everything after the branch point to the last rev it has from devel and shows the delta for that commit, which in the general case has nothing to do with the author it's supposed to be examining.
[09:32] <cjwatson> Probably not desperately hard to fix ...
[09:32] <bigjools> bzr diff -r submit:|diffstat ?
[09:33] <StevenK> bigjools: I think jml was after one number
[09:33] <cjwatson> right, so with my script, bzr di -rsubmit: | diffstat-loc-delta
[09:33] <bigjools> ah ok, didn't catch on to that
[09:34] <cjwatson> (or -rancestor: for a bit less noise from bzr)
[09:34] <bigjools> ancestor needs more typing :)
[09:35] <cjwatson> bigjools: thanks for doing *PPH.requestDeletion() API exporting way back when, BTW - I only just cottoned onto it being there and wrote a client for it
[09:35] <jml> jml@lpdev:~/src/launchpad$ bzr damage
[09:35] <jml> Using submit branch file:///home/jml/.repos/launchpad/devel/
[09:35] <jml> Damage: 67 lines of code
[09:35] <bigjools> cjwatson: \o/
[09:35] <cjwatson> jml: cute
[09:35] <jml> http://paste.ubuntu.com/1016108/
[09:35] <bigjools> jml: haha!
[09:36] <bigjools> so it's net difference
[09:38] <gmb> mgz, nm, I've found the relevant code.
[09:38]  * jml searches for a team with suitably broad write permissions.
[09:39] <cjwatson> jml: http://paste.ubuntu.com/1016109/ ? :-)
[09:39] <jml> cjwatson: :D
[09:42] <jml> that's on lp:bzr-damage if anyone wants it. ~canonical has commit access. based on lp:difftodo, which I use all the time.
[09:42] <jml> gmb: ^
[09:42] <gmb> jml, Awesome, as they say, sauce. Ta.
[09:43] <gmb> "they," of course, being the "everyone" in "everyone knows."
[09:45]  * bigjools is off, g'night folks
[09:46] <StevenK> wallyworld_: Yours is red because r15335 needstesting
[09:46] <StevenK> And the QA machinery knows r15325 is a bad rev
[09:47] <wallyworld_> StevenK: but those 2 revs aren't related
[09:47] <StevenK> wallyworld_: Your rollback is r15336, so everything between r15325 and it has to be deployable for r15325 to be.
[09:48] <wallyworld_> ah, ok then
[09:49] <wallyworld_> StevenK: btw, my scissors and the micro sim experiment worked :-)
[09:49] <StevenK> Oh, twitch
[09:57] <mgz> gmb: sorry for delay, trying to hack through to getting code commited while it's all in my head
[09:57] <mgz> will reply in a sec
[09:59] <stub> Should all branches to fix a bug land with [incr], or only the second+, or just the first, or what?
[09:59] <wgrant> stub: Anything that doesn't fix the bug, normally.
[10:00] <wgrant> stub: It just prevents qa-tagger and me from closing the bug.
[10:00] <stub> ta
[10:33] <mgz> gmb: okay, I'm through the thicket, if you've got any questions still about subunit, bug me
[10:33] <gmb> mgz, At the moment, my questions are all very much of the nature of "that's really straightforward! Now, how the sweet hell do I get zope.testing to do that without breaking the entire universe?"
[10:33] <gmb> But no fear, I'll bug you as necessary.
[10:34] <mgz> right, that'll be the tricky bit :)
[10:44] <jml> fwiw, I did zope.testing's subunit support initially
[10:44] <jml> so I might be able to help a little
[10:46] <mgz> jml: the basic desure is to keep the subunit stream off stdout when running tests in more than one process
[10:47] <jml> why?
[10:52] <mgz> it's a bit to easy to break the world if a test has something that ends up printing to a standard stream
[11:01] <jml> isn't that just subunit's passthrough stuff being borked?
[11:08] <mgz> it doesn't help that the format is super-fragile, but TestProtocolClient(testresult.TestResult): """A TestResult whic
[11:08] <mgz> ...bad paste
[11:09] <mgz> anyway, you can pass a dedicated stream, which is then less liable to random breakage
[12:13] <jml> https://code.launchpad.net/~jml/launchpad/generate-ppa-logging/+merge/108040 needs review
[12:13] <jml> unfortunately I've made it huge in an attempt to clean up
[12:16] <jml> wgrant: if you're around... ^
[12:17] <rick_h_> jml: jcsackett should be around in the next hour/two and is OCR. I think wgrant is pretty EOD/night at this point.
[12:20] <wgrant> jml: I can't review that tonight, sorry. I'll be more than happy to do it tomorrow if nobody else does it.
[12:21] <jml> wgrant: np. thanks.
[13:33] <cjwatson> Hmm, members of ubuntu-archive who aren't in ubuntu-core-dev can't run auto-sync
[13:34]  * cjwatson ponders whether that's correct
[13:34] <cjwatson> I can see how it arises, obviously; rather impedes automation though
[14:51] <jml> jcsackett: hi
[14:52] <jcsackett> jml: heya.
[14:52] <jml> jcsackett: would you please take a look at https://code.launchpad.net/~jml/launchpad/generate-ppa-logging/+merge/108040 ?
[14:52] <jcsackett> jml: happily.
[14:52] <jml> jcsackett: it's kind of long. sorry.
[14:52] <jml> jcsackett: I went far & wide to try to make it line-count neutral. as it is it's still 30 lines in debt.
[14:53] <jml> jcsackett: oh, you should also note that an earlier version of said patch is currently cowboyed, running on germanium
[14:53] <jml> jcsackett: thanks.
[15:29] <jcsackett> jml: got delayed on looking at your MP; i'm a little ways through, but i've noticed that jelmer reviewed your code about 19 hrs ago and approved. did you explicitly want a second review, or just hadn't noticed it had a vote already?
[15:30] <jml> jcsackett: second review. jelmer approved an earlier, shorter. version for cowboying but not for landing.
[15:30] <jml> s/.//
[15:30] <jcsackett> jml: aaah. okay, i understand now.
[15:31] <jcsackett> jml: one quick note on the LoC thing; you can actually run a tool from lp-dev-utils that tells the total line debt you have. in this case, you're at -42, so the extra 30 still leaves you ahead of the game.
[15:33] <jml> jcsackett: oh, interesting. This is from a separate arc of work though, so I would personally like to count it separately.
[15:33] <jcsackett> jml: dig.
[15:33]  * jml think of 'bzr damage' hacks.
[15:35] <jml> jcsackett: fwiw, the assertContentEqual change is busted. I'm reverting that locally.
[15:36] <cjwatson> jcsackett: When you get a chance, I could use a review of https://code.launchpad.net/~cjwatson/launchpad/packageset-score-rename-support/+merge/107981 - fixing this is going to take three successive deployments, so I'd like to get it moving
[15:37] <jcsackett> cjwatson: sure thing. i'll look as i finish with jml's.
[15:37] <cjwatson> ta
[16:22] <jcsackett> jml: r=me on the MP. if you address the comments issues and set the commit msg, i can send that out to land for you.
[16:22] <jcsackett> cjwatson: taking a look at yours now.
[16:23] <jml> jcsackett: thanks. will do.
[16:24] <jml> jcsackett: one thing though, when I said 'numbers are arbitrary', I meant the 3, 45 & 16 I was using for testing, not the constants for how many seconds are in a day or microseconds in a second :)
[16:24] <jml> jcsackett: I can change either or both of those if you want, although I don't think either change will do much to enhance readability
[16:25] <jcsackett> jml: my comments are poorly placed. i am referring only to the parts about dropping this stuff when we drop py 2.6
[16:26] <jml> jcsackett: ah right. can do. I assume I don't have to file a bug for those XXX comments then?
[16:27] <jcsackett> jml: i see no need for that, and there are plenty of XXX comments without a bug. just name and date are fine. :-)
[16:29] <jml> jcsackett: cool. thanks. worth changing https://dev.launchpad.net/PolicyandProcess/XXXPolicy then, I reckon.
[16:29] <jcsackett> jml: probably so, yes.
[16:30] <jcsackett> cjwatson: r=me.
[16:31] <cjwatson> jcsackett: Great, thanks!  Could you "Status: Approve" it and I'll land it
[16:31] <cjwatson> ?
[16:32] <jcsackett> cjwatson: oh right; you can land but not mark approved. strange corner case to be in. :-P
[16:32] <cjwatson> Aye
[16:32] <jcsackett> cjwatson: done.
[16:33]  * jml <3 wikis
[16:33] <cjwatson> Lovely.  Off to EC2.
[16:35] <jml> jcsackett: I'm in the same boat actually.
[16:35] <jml> jcsackett: changes pushed.
[16:36] <jcsackett> jml: ok, then i've flipped the final toggle and you may land your branch. :-)
[16:36] <cjwatson> jml: Good to know it's not just me.
[16:40] <frankban> jcsackett: could you please review https://code.launchpad.net/~frankban/launchpad/bug-996720/+merge/108196 ?
[16:41] <jcsackett> frankban: already looking at it. :-)
[16:41] <frankban> thanks jcsackett :-)
[16:45] <jcsackett> frankban: r=me. good fix.
[16:45] <frankban> great, thank you
[17:02] <cjwatson> What happens to OOPSes generated during tests?
[17:02] <cjwatson> Actually I guess I don't know if it's an OOPS.  I'm getting an Unauthorized with a rather inscrutable response body, and would like to try to figure out what's trying to fetch the attribute ("items", so not very specific) that's the proximate cause of the Unauthorized.
[17:10] <cjwatson> ... I've fixed my immediate problem by staring closely at print debugging.  I'm still interested if there are more powerful tools I'm missing out on.
[17:23] <jml> cjwatson: that's almost certainly caused by zope's security proxy
[17:23] <jml> cjwatson: afaict, oopses ought to be captured by default within tests.
[17:24] <cjwatson> For once it actually wasn't the security proxy
[17:24] <cjwatson> Well, maybe it was, not sure.  I was returning a list of lists of dicts by accident when the interface said list of dicts.
[17:31] <jml> cjwatson: it'll be the proxy raising that error.
[17:31] <cjwatson> Perhaps my question would be better phrased as "how do I actually get to see that OOPS?".
[17:32] <cjwatson> I was getting stuff of the form http://paste.ubuntu.com/1016677/ .
[20:25] <sinzui> jcsackett, do you have time to review https://code.launchpad.net/~sinzui/launchpad/queue-project-email/+merge/108235
[20:27] <jcsackett> sinzui: sure.
[20:43] <jcsackett> sinzui: r=me.
[20:43] <sinzui> thank you.
[22:17] <bdmurray> I thought I'd look at doing some launchpad dev and I'm having trouble running it at the moment
[22:17] <bdmurray> Couldn't find a distribution for 'lazr.jobrunner=0.6'
[22:22] <czajkowski> bdmurray: have you seen the latest write up http://blog.launchpad.net/general/contributing-to-launchpad
[22:26] <bdmurray> czajkowski: yes and one thing that page doesn't address is actually running launchpad so you can see what it looks like and interact with it via a browser
[22:27] <bdmurray> or how to keep your launchpad development system up to date
[22:35] <cjwatson> bdmurray: did you do just 'bzr pull' rather than utilities/rocketfuel-get?
[22:35] <cjwatson> That looks like lp-sourcedeps is out of date
[22:35] <wgrant> bdmurray: bzr up ~/launchpad/lp-sourcedeps/download-cache
[22:40] <bdmurray> thanks, so is utilities/rocketfuel-get the best way to stay up to date or something else?
[22:41] <wgrant> bdmurray: That's the best way, yeah.
[22:42] <wgrant> It mostly just pulls devel, ups download-cache, and runs utilities/update-sourcecode
[23:12] <cjwatson> Could I have a DB patch number for "ALTER TABLE Packageset RENAME COLUMN score TO relative_build_score;", please?  Bug 1000570.
[23:12] <_mup_> Bug #1000570: "Packageset.score" is badly named <qa-untestable> <tech-debt> <trivial> <Launchpad itself:In Progress by cjwatson> < https://launchpad.net/bugs/1000570 >
[23:14] <cjwatson> I've already tested the packageset-score-rename-support branch linked to that bug both with and without that DB patch applied.
[23:14] <StevenK> cjwatson: 18-4
[23:14] <cjwatson> Thanks.  Earlier than the tip patches in db-devel?
[23:14] <cjwatson> I guess it doesn't matter
[23:14] <StevenK> It does not
[23:16] <cjwatson> OK.  I'll push it for review tomorrow; it's missed the upcoming NDT anyway, so no rush.
[23:17] <StevenK> cjwatson: DB patch requires FDT
[23:17] <StevenK> Oh, sorry, I missed your other comment
[23:21] <cjwatson> I was unclear.  I mean the code support branch has missed the upcoming NDT anyway, so no rush.  I understand that the DB patch will require an FDT.
[23:21] <lifeless> sinzui: https://bugs.launchpad.net/launchpad/+bug/1007208 may or may not interest you
[23:21] <_mup_> Bug #1007208: Searching for 'ev' in the 'add a member' picker fails <Launchpad itself:Triaged> < https://launchpad.net/bugs/1007208 >
[23:23] <StevenK> cjwatson: We have FDTs until at least Tuesday or Wednesday
[23:24] <wgrant> lifeless: I think that's a dupe.
[23:24] <wgrant> lifeless: A dupe of searching for mgz.
[23:24] <wgrant> We certainly considered it in our picker work.
[23:33] <lifeless> anyone remember why we have both ~launchpad-reviewers *and* ~canonical-launchpad-reviewers ?
[23:42] <bigjools> less email?  more email? :)
[23:43] <lifeless> whoknowsIcertainlydon't