[00:00] <lifeless> how does one specify a new dependency to buildout ?
[00:03] <mwhudson> lifeless: setup.py
[00:03] <lifeless> mwhudson: I'm looking in lazr.batchnavigator
[00:03] <lifeless> mwhudson: I have a test-only dependency, or should I not worry about the subtlety
[00:04] <mwhudson> setup.py *might* support test_requires?
[00:04]  * lifeless goes with damn-the-torpedoes
[00:08] <sinzui> thumper: wgrant mumble?
[00:08] <thumper> sure
[00:08] <wgrant> Sure.
[00:09] <thumper> wallyworld: you around?
[00:09] <wgrant> He's on mumble.
[00:09] <wallyworld> yep
[00:10] <wallyworld> thumper: sinzui: i can't hear you guys. looks like my audio is foobar again. will have to restart :-(
[00:10] <thumper> wallyworld: ok
[00:11] <sinzui> wgrant: does mumble need stabbing?
[00:11] <wgrant> sinzui: Thumper and I are talking OK...
[00:12] <thumper> sinzui: I can hear him
[00:12] <thumper> sinzui: and you
[00:12] <sinzui> maybe I fell off the earth
[00:12] <sinzui> I feel like that actually
[00:13] <huwshimi> sinzui: we can hear you
[00:13] <thumper> sinzui: it is just you
[00:13] <sinzui> fab
[00:16] <sinzui> mumble gave up on it's own
[00:23] <wallyworld> thumper: sinzui: sorry, my audio has totally died for some reason :-(
[00:24] <sinzui> wallyworld: okay. mumble booted me from the conversation twice
[00:25] <wallyworld> sinzui: it's not mumble. i have no output at all. speakers/headphone all silent :-(
[01:01] <poolie> lifeless,  shall we stick with https://bugs.launchpad.net/launchpad/+bug/525758
[01:01] <_mup_> Bug #525758: A project's branch privacy policy is not visible on the branch settings page <confusing-ui> <lp-code> <privacy> <Launchpad itself:Triaged> < https://launchpad.net/bugs/525758 >
[01:01] <lifeless> cyes
[01:01] <lifeless> yes
[01:06] <lifeless> poolie: mail sent; I hope I captured everything - if I didn't, please correct me ;)
[01:07] <poolie> very nice, thanks
[01:10] <poolie> ok, https://bugs.launchpad.net/launchpad/+bug/750871
[01:10] <_mup_> Bug #750871: want an api and ui to set branch privacy policy <Launchpad itself:Triaged> < https://launchpad.net/bugs/750871 >
[01:10] <poolie> lifeless, it looks like you could create a Branch through the api with private=true
[01:11] <poolie> which would avoid a race of making them private after they're created
[01:11] <poolie> in that case it would be enough to just have bzr call it
[01:11] <poolie> (arguably a bit messy to need to do this as well as sshing in, but not too bad)
[01:11] <poolie> do you think that won't work?
[01:12] <lifeless> you still need a policy setup to permit privacy at all
[01:13] <lifeless> + having to use bzr push --use-existing-dir
[01:14] <lifeless> wgrant: ugh
[01:14] <lifeless> wgrant: we broke 'redirect to a real context'
[01:15] <lifeless> https://bugs.launchpad.net/launchpad/+bugs/5011
[01:15] <poolie> well, if bzr called the api it would hopefully be smart enough to expect a directory there
[01:15] <wgrant> lifeless: We didn't.
[01:15] <lifeless> wgrant: it was already broken ?
[01:15] <wgrant> lifeless: The container is '+bug'
[01:15] <wgrant> lifeless: Not '+bugs'
[01:15] <poolie> ah, so the default policy, even if you have an entitlement to private branches, is to disallow them?
[01:15]  * lifeless fails
[01:15] <lifeless> poolie: right
[01:16] <lifeless> poolie: noone can has private branch until a policy is setup permitting a group they are in to have them
[01:17] <lifeless> poolie: I think 750871 is a dupe of 525758 isn't it ?
[01:18] <lifeless> ah, no its not
[01:20] <poolie> they're arguably the same, but  one is "show it" and the other is "let me change it"
[01:20] <poolie> i was going to file one more for "change it per branch"
[01:20] <lifeless> well, that already works, just only one way
[01:21] <poolie> huwshimi, it seems like pressing enter in the tags field no longer saves the changes
[01:21] <lifeless> a search for 'branch privacy' is pretty interesting
[01:21] <huwshimi> poolie: Can you file a bug please?
[01:22] <poolie> i will
[01:22] <poolie> oh also https://bugs.launchpad.net/launchpad/+bug/252172
[01:22] <_mup_> Bug #252172: Changing a branch's status/privacy isn't obvious <confusing-ui> <lp-code> <privacy> <Launchpad itself:Triaged> < https://launchpad.net/bugs/252172 >
[01:22] <poolie> lifeless, is bug 444498 a dupe of bug 347772?
[01:22] <_mup_> Bug #444498: branch privacy for packages (of projects with privacy enabled) <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/444498 >
[01:22] <_mup_> Bug #347772: Privacy policy support for package branches <disclosure> <lp-code> <package-branches> <privacy> <Launchpad itself:Triaged> < https://launchpad.net/bugs/347772 >
[01:22] <lifeless> poolie: no
[01:23] <lifeless> but I just edited it before you asked anyhow :)
[01:23]  * wgrant hunts for someone to review https://code.launchpad.net/~wgrant/launchpad/bug-750640/+merge/56276
[01:23] <lifeless> poolie: 444498 is about extending privacy to package branches when the upstream has a commercial ticket
[01:24] <lifeless> 347772 is about permitting distro contributors to do private branches for embargoed changes (BFB into primary archive will need that)
[01:24] <lifeless> wgrant: is +        fields.append('Source', source) right ?
[01:25] <lifeless> wgrant: if source is None, will that DTRT
[01:26] <wgrant> lifeless: Yes, see eg. the handling of Essential.
[01:26] <poolie> huwshimi, https://bugs.launchpad.net/launchpad/+bug/750880
[01:26] <_mup_> Bug #750880: pressing enter in bug tags field doesn't save changes <Launchpad itself:New> < https://launchpad.net/bugs/750880 >
[01:26] <lifeless> wgrant: its almost worth doing a Matcher there
[01:26] <lifeless> wgrant: but your helper is awkward, a nicer spelling is included in my review
[01:27] <wgrant> Thanks.
[01:27] <lifeless> huwshimi: hi
[01:27] <huwshimi> poolie: Does that happen when you hit the save button as well?
[01:27] <huwshimi> lifeless: Hello.
[01:28] <lifeless> huwshimi: I don't recall any feedback from you on my suggestion about your easy-ui bugs & priority
[01:28] <wgrant> lifeless: Treating it as a dict is wrong, but I guess it's OK for tests.
[01:28] <lifeless> huwshimi: so I thought I'd poll you for some
[01:28] <poolie> huwshimi, there is no save button
[01:28] <poolie> as i suspected it's due to a problem in tag suggestion
[01:28] <lifeless> wgrant: your test treats it as one :)
[01:28] <poolie> or so it seems
[01:28] <huwshimi> poolie: OK then this looks like a new issue
[01:28] <lifeless> wgrant: so either match on a vector (and definitely do a matcher), or be much more pithy :>
[01:29] <poolie> i think i'ts fallout from the previous fix
[01:29] <poolie> hm so https://bugs.launchpad.net/launchpad/+bug/120306 suggests there is already a ui for this
[01:29] <lifeless> poolie: tag edits are saving for me
[01:29] <poolie> it may be to do with using a new tag?
[01:29] <lifeless> poolie: yes there is, as I said. But public->private is deliberately not supported
[01:30] <poolie> then you can't toggle it, can you? :)
[01:30] <lifeless> poolie: no :>
[01:30] <lifeless> well
[01:30] <lifeless> you can toggle once
[01:30] <lifeless> anyhow
[01:30] <lifeless> I think that we need to revisit it
[01:31] <poolie> ok, so i'll file a new one, mentioning it may be complex
[01:31] <lifeless> but I don't think its a proximate cause of pain
[01:31] <lifeless> blah
[01:31] <lifeless> the words are not coming today. I mean 'changing that wouldn't make a lot of difference'
[01:32] <huwshimi> lifeless: I'm not sure it's appropriate for us to elevate these bugs. If we did we would have to raise up a few hundred bugs to high.
[01:33] <lifeless> huwshimi: but you think they are very important for the user experience, right? Or did I misread your email ?
[01:33] <huwshimi> lifeless: The idea is not that people should have to do these bugs, but a way of signifying that these are some good bugs to look at if people want to do some UI work.
[01:34] <lifeless> huwshimi: I think this is a flawed way to analyze the problem
[01:35] <lifeless> huwshimi: You made a compelling argument that fixing these bugs is both relatively cheap and will have a large impact on usability and product perception.
[01:35] <poolie> lifeless, it's exactly the button these users are wanting to push
[01:35] <poolie> i agree it would be better if they'd never gotten in to this state
[01:35] <poolie> anyhow, https://bugs.launchpad.net/launchpad/+bug/750889
[01:35] <lifeless> poolie: but they want to push it because another critical step has been missed.
[01:35] <_mup_> Bug #750889: need to be able to make public branches private <Launchpad itself:Triaged> < https://launchpad.net/bugs/750889 >
[01:36] <huwshimi> lifeless: In as much that fixing any UI bugs is a good thing.
[01:36] <lifeless> huwshimi: well, the UI isn't a special case for users: a bug is a bug
[01:37] <lifeless> hard to use is hard to use
[01:37] <poolie> ok now to fix the actual branch
[01:39] <lifeless> huwshimi: If I understand correctly, you are postulating a disconnect between 'this is important (to the UI)' and 'this is important'
[01:39] <lifeless> huwshimi: is that correct?
[01:40] <huwshimi> lifeless: I don't think the bugs I've tagged are necessary any more important than other UI bugs (in some cases exactly the opposite). All I am doing is identifying bugs that are cheap to fix.
[01:41] <lifeless> huwshimi: now I'm really confused
[01:41] <huwshimi> lifeless: One sec.
[01:41] <StevenK> lifeless: You've screwed up the topic a bit
[01:42] <lifeless> huwshimi: you said in your email that these were high leverage bugs, holding three properties: easy to fix, only need ui changes, make a big difference to users
[01:42] <lifeless> bwah
[01:42] <poolie> lifeless, shall we have a bug for 'bzr push --private'?
[01:42] <lifeless> poolie: I think that would be good
[01:42] <poolie> istm that's a bit less important than getting the policy set right
[01:42] <poolie> but may be worth filing anyhow
[01:51] <thumper> lunch I think before tackling the inmemory xmlrpc mock for the stacking changes
[02:28] <lifeless> huwshimi: the ajax log stuff is awesome
[02:29] <lifeless> I've having a few wtf moments
[02:29] <lifeless> (at latencies)
[02:30] <huwshimi> lifeless: Yeah it's nice to see that stuff all the time. We're actually under for quite a few queries, and most of the rest are are not a long way over
[02:31] <lifeless> huwshimi: I had some come in at 24 seconds this morning ><
[02:31] <huwshimi> lifeless:  Oh really!@
[02:33] <lifeless> yeah
[02:33] <lifeless> I may have hit browser concurrent connection limit or something
[02:33] <lifeless> I opened a few tabs
[02:48] <lifeless> wgrant: why isn't it a regression ?
[02:49] <wgrant> lifeless: What regressed/
[02:50] <lifeless> wgrant: our hiding of merge proposals
[02:50] <lifeless> wgrant: when we added a feature (prereqs) we backslid on disclosure
[02:51] <wgrant> Mmmmm. Maybe barely.
[02:51] <wgrant> We're not really disclosing stuff we shouldn't, though.
[02:52] <wgrant> So it's more that prereqs are broken when the prereq is private but the proposed branch is not.
[02:52] <wgrant> I think that makes it a broken feature, not a regression.
[03:07] <lifeless> disclosure is defined as being viral
[03:07] <lifeless> thats not working here
[03:07] <lifeless> thats a regression
[03:09] <wgrant> Viral to what extent?
[03:10] <wgrant> A private bug does not make a branch private.
[03:10] <wgrant> A private branch does not make a bug private.
[03:10] <wgrant> A private prereq should possibly not make an MP private.
[03:10] <lifeless> a branch link is invisible if either the branch or the bug is invisible
[03:10] <lifeless> a mp is invisible is any of the items on it are invisible
[03:10] <wgrant> Except a bug or blueprint or
[03:11] <lifeless> one step removed
[03:11] <lifeless> mmm, viral is the wrong word
[03:11] <lifeless> I would love to see 4 /    0  None fixed
[03:13] <wgrant> Hmm, it's the librarian.
[03:14] <wgrant> Erm.
[03:14] <wgrant> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1920MPJ4
[03:14] <wgrant> Reads the same file 376 times.
[03:16] <lifeless> wgrant: I actually meant the 'None' part :)
[03:26] <wgrant> lifeless: Do you know of a bug for late evaluation of attachment LFCs on BugTask:+index?
[03:26] <lifeless> no
[03:26] <wgrant> Have you looked at that at all?
[03:27] <lifeless> shouldn't be happening
[03:27] <lifeless> perhaps fallout from librarian code changes you did?
[03:27] <wgrant> Which?
[03:27] <wgrant> It only affects attachments that appear in comments.
[03:27] <lifeless> removing the feature flag
[03:27] <lifeless> oh
[03:28] <wgrant> No, that's unrelated.
[03:28] <lifeless> hadn't seen that at all
[03:28] <wgrant> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1920A1682 for example.
[03:28] <wgrant> 3s selecting attachment LFCs.
[03:28] <wgrant> Fixing now.
[03:28] <lifeless> win
[03:28] <wgrant> Rendered in 10.9s for me just now :/
[03:28] <lifeless> why does it need the LFC's at all ?
[03:28] <wgrant> (with ?comments=all)
[03:28] <wgrant> It shows the file size.
[03:29] <lifeless> whatnow
[03:29] <wgrant> Xorg.0.log (23.1 KiB, text/plain)
[03:29] <lifeless> in the comment ?
[03:29] <wgrant> This is in the comments, not the portlet.
[03:29] <thumper> hmm...
[03:29] <lifeless> 178 queries/external actions issued in 5.27 seconds
[03:29] <wgrant> lifeless: ?comments=all
[03:29] <lifeless> we really should show the real url in the oops report
[03:30] <lifeless> 521 queries/external actions issued in 10.93 seconds wheeeee
[03:30] <wgrant> lifeless: The query string is there if you look hard, but yes.
[03:30] <wgrant> lifeless: Exactly.
[03:30] <lifeless> wgrant: gets truncated sometimes
[03:30] <lifeless> wgrant: so, are you going to eager load, or make the attachment the same as the portlet
[03:31] <wgrant> lifeless: It should be really cheap to eager load.
[03:31] <lifeless> cool
[03:31] <wgrant> I mean, LFC isn't that fat.
[03:32] <wgrant> Hmm, except the hashes. But it's still <100kb of extra data.
[03:33] <lifeless> sure
[03:33] <wgrant> Bug search really, really sucks.
[03:39] <wgrant> This will possibly fix half of the BugTask:+index timeouts.
[03:39] <wgrant> I hope.
[03:40] <wgrant> Mm, although I don't know what the OOPS report shows.
[03:40] <wgrant> Since it shows more entries for BugTask:+index in "top timeouts" than there were timeouts.
[03:42] <lifeless> rotfl
[03:50] <thumper> lifeless: how can I tell if a repository is stacked or just pretending?
[03:50] <thumper> lifeless: how can I open the repository to find the number of revisions?
[03:51] <thumper> I have a branch that appears to be stacked locally using my new branch id alias
[03:51] <spiv> thumper: I'm not sure what "just pretending" could mean
[03:51] <thumper> but I want to confirm for myself that it is doing what it says
[03:51] <thumper> spiv: I mean is saying it is stacked, but the branch repository has all the revisions
[03:51] <spiv> Either a repository has at least one fallback repository, or it doesn't…
[03:51] <thumper> can it do that?
[03:51] <thumper> does it confirm that the fallback repository is valid?
[03:52] <spiv> Probably you can have the state where the stacked repo has all the revisions (e.g. stacking on an empty repo)
[03:52] <spiv> But I don't know why you'd care?
[03:52] <thumper> humour me
[03:52] <spiv> bzrlib always opens all the fallbacks
[03:52] <spiv> Unless you explicitly do Branch.open(ignore_fallbacks=True)
[03:53] <spiv> I'm guessing “can be opened” is what you mean by “is valid”?
[03:54] <thumper> open(base, _unsupported=False, possible_transports=None)
[03:54] <thumper> no ignore_fallbacks
[03:54] <thumper> repository? or bzrdir?
[03:55] <spiv> *Branch*
[03:55] <mwhudson> thumper: you can look at len(branch.repository.all_revision_ids())
[03:55] <spiv> The fallback location is defined in the branch.conf
[03:55] <mwhudson> (iirc)
[03:55] <spiv> If you open a repository directly, without going via a branch, it will have no fallbacks configured.
[03:55] <lifeless> thumper: it opens the fallbacks at Repository.open() / Branch.open()
[03:56] <lifeless> thumper: it will fail eagerly
[03:56] <spiv> lifeless: not at Repository.open
[03:56] <lifeless> thumper: this may change in future but hasn't yet
[03:56] <lifeless> spiv: yes, true, I'm handwaving
[03:56] <lifeless> because I hadn't read your prose yet :P
[03:57] <spiv> thumper: (BzrDir.open_branch also accepts ignore_fallbacks=…)
[03:57] <thumper> http://pastebin.ubuntu.com/589515/
[03:57] <thumper> seems to be working
[03:57] <thumper> info -v tells me what I care about
[03:57] <thumper> and that is the 3 revisions bit
[03:57] <spiv> thumper: but that said, it sounds like you just want to open the branch, and if it can be opened then the repository and its fallbacks must exist.
[03:58] <spiv> There may be a good reason why you want to check whether the revisions exist in the branch's repo or the stacked-on repo, but it's not obvious to me why you should need to check that.
[04:01] <spiv> thumper: I would expect info -v in that context would be counting revisions in the fallbacks as well as that direct location.
[04:05]  * spiv → lunch
[04:11] <thumper> spiv: no, it doesn't
[04:11] <thumper> spiv: which is good
[04:12] <thumper> interesting
[04:13] <thumper> bzr info -v http://bazaar.launchpad.dev/~thumper/wikkid/soundex doesn't show the count of revisions in the repository
[04:22] <jtv> lifeless: I'm experiencing delays in Q/A for db-devel r10383.  What are the chances of that one becoming a blocker for this rollout?
[04:23] <wgrant> jtv: 0
[04:23] <wgrant> jtv: The merge has already occurred.
[04:23] <wgrant> r10381
[04:24] <jtv> so no?  thanks, that's good to know
[04:25] <wgrant> Right.
[04:25] <wgrant> It is very scary and needs to be QAd at some point, but it's not 11.04-criticasl.
[04:27] <jtv> Well the interesting part is that besides the big change, I'd also want to see that the minor changes to the original script are still safe.
[04:28] <lifeless> jtv: FTR I mailed the -dev list on monday about this
[04:28] <lifeless> jtv: I'd like to know if I was unclear etc so I can communicate better in future
[04:28] <wgrant> jtv: I meant that both are very scary.
[04:28] <wgrant> jtv: That script hasn't been changed significantly in a Long Time.
[04:28] <wgrant> Even though these changes look pretty safe.
[04:30] <jtv> lifeless: I see it now—I suspect thunderbird has been hiding it from me.
[04:32] <jtv> wgrant: it's extra-scary even because I know so little of what to expect from the scripts that it invokes.  Did you see the run-parts directories in cronscripts/publishing/distro-parts?
[04:33] <lifeless> bbiab
[04:54] <poolie> wow the new +authorize-token is quite slick
[04:54] <poolie> well done leonard, or whoever
[04:54] <wgrant> The system-wide one? Yeah.
[04:55] <wgrant> (Pdb) from lp.bugs.model.bug import Bug
[04:55] <wgrant> (Pdb) Bug.get(16)
[04:55] <wgrant> <Bug at 0xfe2cb90>
[04:55] <wgrant> (Pdb) print self.context.bugID
[04:55] <wgrant> 16
[04:55] <wgrant> (Pdb) print self.context.bug
[04:55] <wgrant> None
[04:55] <wgrant> What?
[04:56] <wgrant> Hmm. Maybe I have a slave object, I guess, but...
[04:56] <wgrant> ... and attempting to check self.context._store crashed pdb. Yay.
[04:56] <lifeless> win
[05:03] <lifeless> wgrant: this is a new bugtask ?
[05:04] <wgrant> lifeless: Yes. I create it, test the query count, add attachments, test the query count. The query count test seems to be removing it from the store, which I guess shouldn't surprise me too much.
[05:04] <lifeless> its invalidating the world
[05:04] <lifeless> grab it again from the set
[05:05] <lifeless> (at a guess)
[05:05] <lifeless> psatebin ?
[05:09] <wgrant> lifeless: Retrieved, still broken :/
[05:10] <lifeless> wgrant: ok, thats new then
[05:10] <lifeless> I've not seen *that* before
[05:10] <lifeless> time to edit z3batching
[05:10] <lifeless> if I'm not back in an hour, send in a search party
[05:10] <wgrant> Heh
[05:11]  * StevenK goes to tell the people in the next apartment where they can store the masonry drill they've been using since 9am.
[05:12] <StevenK> It's in the room right next to me, so I have a splitting headache
[05:12] <wgrant> lifeless: http://pastebin.ubuntu.com/589533/
[05:13] <wgrant> makeBugAttachment works if you drop line 59 of that diff.
[05:13] <thumper> :-(((
[05:13] <thumper> WTF?
[05:14] <thumper> running a test I get a failure that looks hard to explain
[05:14] <thumper> so I run the test with -D
[05:14] <thumper> it stops at: -> result.addSuccess(test)
[05:14] <thumper> (Pdb) c
[05:14] <thumper> so I continue
[05:14] <thumper> Ran 1 tests with 0 failures and 0 errors in 11.213 seconds.
[05:14] <thumper> stupid POS
[05:16] <lifeless> wgrant: that makes no sense at all
[05:16] <wgrant> lifeless: The test, or the problem?
[05:17] <lifeless> wgrant: the problem
[05:17] <lifeless> wgrant: there is no store.reset etc etc in that matcher
[05:18] <lifeless> nor a store.invalidate
[05:18] <wgrant> A store.invalidate won't remove the objects, either... it should just mark everything AutoReload, right?
[05:19] <lifeless> store.invalidate is pretty shallow yes
[05:19] <lifeless> store.reset is harsher, IIRC
[05:20] <wgrant> Right, I think reset does some really bad stuff.
[05:20] <wgrant> I guess I'll just create a fresh task for now :/
[05:23] <lifeless> wgrant: I'd really like to know whats up
[05:23] <lifeless> wgrant: have you tried to bisect?
[05:27] <wgrant> lifeless: Bisect the matcher?
[05:27] <wgrant> I probably should.
[05:30] <lifeless> wgrant: yes
[05:35] <thumper> can I get someone else to run TestBranchChangedErrorHandling ?
[05:35] <thumper> I have it failing on devel
[05:35] <thumper> unless I add -D
[05:35] <thumper> in which case it kinda passes
[05:44] <spiv> thumper: I'm pretty sure 'bzr info -v' of a branch does count revisions from the stacked-on repository.  What makes you think otherwise?
[05:45] <thumper> spiv: it shows the full history count for the branch, but the repository says 3 revision
[05:45] <thumper> spiv: since the output says that, that is why I think that way
[05:46] <spiv> thumper: not in quick testing locally
[05:46] <spiv> thumper: and not according to my reading of the code
[05:46] <thumper> spiv: is for me
[05:47] <thumper> spiv: http://pastebin.ubuntu.com/589515/
[05:48] <spiv> It's probably affected by running over a smart server.
[05:48] <spiv> Probably that's a bug.
[05:49] <thumper> but very handy
[05:51] <spiv> You're probably the first person to think so :)
[06:07] <wgrant> WTF :/
[06:11] <lifeless> wgrant: ENODETAIL
[06:14] <wgrant> Set up a browser? Fine. Browse to a question? Fine. Browse to a bug? You can't use makeBugAttachment any more.
[06:15] <wgrant> Somehow browsing to BugTask:+index manages to break the subscribers, I think.
[06:15] <wgrant> lifeless: ^^
[06:15] <wgrant> makeBugAttachment doesn't work at all, even on a new bug.
[06:18] <wgrant> (this affects anything usin setupBrowserForUser, not just the matcher.
[06:19] <lifeless> wgrant: I thought it wasn't the matcher ;)
[06:20] <wgrant> So did I, but I didn't have evidence.
[06:29] <StevenK> wgrant: Pity me, I'm debugging the packagecloner
[06:30] <lifeless> StevenK: pity the fool ?
[06:48] <wgrant> Oh, LaunchBag.
[06:49] <wgrant> Fucking LaunchBag, please die.
[06:50] <StevenK> wgrant: Then remove it?
[06:53] <wgrant> I have some misgivings about the output of *canonical*_url depending on what you've traversed through lately.
[06:55] <StevenK> wgrant: Perhaps it wants to make sure you take your shoes off so you don't dirty the carpets.
[06:56] <wgrant> Hah
[06:57] <lifeless> wgrant: rotfl
[06:57] <StevenK> Sigh, I thought the build was linked from BPPH
[06:58] <wgrant> StevenK: You have to go through BPR.
[06:58] <wgrant> lifeless: No.
[06:58] <StevenK> Ah, I see it.
[06:58] <wgrant> Unless you are rolling around to squash LaunchBag flat, in which case it might be acceptable.
[07:17] <lifeless> sigh at domain name spam
[07:38] <lifeless> pop quiz
[07:38] <lifeless> nvm
[07:52] <jtv> lifeless: is there no way to resolve a qa-bad other than roll back the entire revision and then land a fixed re-run of the branch?
[07:55] <lifeless> jtv: you can just land a fix
[07:56] <lifeless> jtv: have it claim to rollback the bad revision
[07:57] <jtv> lifeless: thanks.  I think https://dev.launchpad.net/QAForContinuousRollouts sort of skips over the exact meaning of --rollback; I thought it had bzr implications.
[07:57] <lifeless> jtv: feel free to tweak it; its purely a workflow tag for us
[07:58] <lifeless> if the commit says '[rollback=1234] fix 1234', then its pretty clearly not a rollback
[07:58] <jtv> lifeless: so it just pairs the revisions to mark the fact that the newer revision fixes a qa-bad on the older one?
[07:58] <lifeless> IWBN to have qatagger have a unbreak=1234 that does the same as rollback but doesn't confuse people
[07:58] <lifeless> jtv: yes
[07:59] <jtv> OK… I guess https://dev.launchpad.net/QAProcessContinuousRollouts needs updating as well.
[07:59] <poolie> lifeless,  oh was your complaint about domain spam by any chance inspired by pda.lv?
[07:59] <poolie> i just hit that
[08:00] <lifeless> 'Internet copyright of "canonical" and Bdjikln company'
[08:00] <lifeless> Dear President & CEO, .... - addressed to info@ and delivered to me
[08:02] <jtv> So CEO is Russian for "occupant"?
[08:39] <jtv> No reviewers today?
[08:40]  * StevenK pushes wgrant forward.
[08:41] <jtv> a volunteer!
[08:41]  * jtv pins suspiciously plastic-y medal and branch on wgrant: https://code.launchpad.net/~jtv/launchpad/db-bug-751054/+merge/56298
[08:42]  * wgrant is looking.
[08:45] <wgrant> jtv: Done.
[08:45] <wgrant> StevenK: Want to mentor?
[08:45] <jtv> thanks
[08:45] <jtv> only fair :)
[08:47] <StevenK> wgrant: Done
[08:49] <StevenK> jtv: Well, wgrant is on the schedule as OCR today, which is why I picked on him
[08:49] <jtv> wgrant: I'm not sure what you mean about me saying that I reverted to the devel version…  what I said was "I really just copied the devel version of the script into a db-devel branch."  What's missing?
[08:50] <jtv> It's not actually exactly reverting, since the devel version had changed in the meantime.
[08:51] <wgrant> Mmm
[08:56] <adeuring> good morning
[09:42] <wgrant> lifeless: Thanks.
[09:45] <wgrant> Bah, real test failure.
[09:55] <wgrant> Odd...
[09:55] <wgrant> I can't reproduce it, but it happens on ec2.
[09:55] <StevenK> wgrant?
[09:56] <wgrant> Anyway, I should go.
[10:59] <jtv> gmb: got a branch for you to review if it's convenient!  https://code.launchpad.net/~jtv/launchpad/db-bug-244328/+merge/56310
[10:59] <gmb> jtv: Sure.
[10:59] <jtv> Splendid, thanks
[11:00]  * jtv runs out for some simple, urgently-needed nutrients
[11:04] <jml> are we in RC mode?
[11:04] <StevenK> Just testfix, I think.
[11:12] <jml> ffs.
[11:15] <gmb> jtv: r=me
[11:16] <jml> not that it matters!
[11:34] <jtv> gmb: thanks
[11:54] <jtv> StevenK, wgrant: do you chaps know anything about the pending merge on df current?
[11:56] <wgrant> jtv: You can drop it.
[11:56] <jtv> \o/ thanks
[11:56] <wgrant> That's weeks old, though, and not actually applied any more...
[11:58] <wgrant> jml: Um, that makes you feel *better*?
[11:58] <wgrant> jml: I can see why, but it also scares me more.
[11:58] <wgrant> Because something has changed.
[11:59] <wgrant> Although what exactly I cannot tell, since the assertion message suggests that the text matches the regexp fine...
[11:59] <jml> wgrant: it's intermittent, and it's probably because of code.
[11:59] <jml> rather than environment
[11:59] <bigjools> wgrant: grar, every time I see a test change for the publisher I want to shout loudly when the file is left in lp/soyuz
[11:59] <jml> and it's only that test rather than other tests in the file
[11:59] <wgrant> bigjools: That orig.tar.gz? Yeah.
[12:00] <bigjools> wgrant: no, lib/lp/soyuz/tests/test_publish_archive_indexes.py and friends
[12:00] <bigjools> should be lp/archivepublisher
[12:00] <wgrant> Oh.
[12:00] <wgrant> Yeah.
[12:00] <wgrant> I guess I should have moved it.
[12:00] <wgrant> but the code itself is in Soyuz.
[12:00] <wgrant> So maybe not.
[12:00] <jml> wgrant: I mean, I feel terrible that we tolerate having such things in our test suite, but believe me that's a small fraction of the terrible I feel, and I'm trying to take my wins where I can.
[12:00] <bigjools> along with most of the code in the soyuz model ....
[12:01] <wgrant> bigjools: Shall I move it before I land the branch, or keep it with the code it tests?
[12:02] <bigjools> wgrant: rs=me if you want to move it
[12:02] <wgrant> I think we should keep it in Soyuz until we split the classes, though :/
[12:02] <bigjools> maybe
[12:02] <jtv> bigjools: can I just run publish-ftpmaster on df or will that open a hole that the Old Ones may use to break through into our world?
[12:02] <jtv> (LPCONFIG=dogfood)
[12:03] <bigjools> jtv: the cron.publish-ftpmaster  script can run unaltered
[12:03] <wgrant> jtv: Please back up dists/ first, though.
[12:03] <jtv> (And of course I'm just naming one of the more likely failure modes as an example; please let me know of other risks as well)
[12:03] <bigjools> nothing will cross from the Other Side
[12:03] <jtv> Phew.
[12:03] <bigjools> wgrant: dists/ is probably already fucked
[12:03] <wgrant> bigjools: Some of it is, some of it is not.
[12:04] <wgrant> It's reasonably easy to judge, and useful for comparisons when trying to unfuck the publisher :)
[12:04] <jtv> bigjools: that's /srv/launchpad.net/ubuntu-archive/ubuntu/dists/ ?
[12:05] <bigjools> jtv: yes
[12:05] <jtv> right ho
[12:05] <bigjools> wgrant: unfuck the publisher?  You have a spare year? :)
[12:05] <jml> deryck: have you seen bug 751187?
[12:05] <_mup_> Bug #751187: Upstream translations not being imported for some Ubuntu packages <Launchpad itself:New> < https://launchpad.net/bugs/751187 >
[12:06] <jml> deryck: not sure if it's relevant to the work you guys are doing
[12:06] <deryck> jml, I haven't seen.  I'll look now.
[12:07] <jml> deryck: thanks.
[12:08] <jtv> deryck: there's the possibility that it's a simple outdated timestamp.
[12:08] <jtv> It may pay to have a look at the import queue entries.
[12:41] <wallyworld_> deryck: hi. my laptop is acting up. no sound, flaky network :-( did you get my recent email? i just want to make sure you don't waste time on the windmill stuff since i've got it sorted
[12:42] <deryck> wallyworld_, no, but my mail setup is flaky.  mail not getting to me after upgrade of server.
[12:42] <deryck> I'm looking into my mail problem now.
[12:43] <wallyworld_> deryck: cool. i got rejection messages. my sound is totally borked for "no" reason. very frustrating.
[12:45] <deryck> my busted mail is very frustrating.
[12:45] <jtv> wgrant: I don't suppose you should be here at this time, but if you are: I got publish-ftpmaster to run in 27 minutes or so, but bigjools tells me that's a good thing.  Perhaps you could take a look?
[12:46] <wgrant> jtv: That is plausible if no release pocket was dirty.
[12:46] <wgrant> Let's see.
[12:46] <wallyworld_> deryck: did you upgrade the kernel recently? that's what did my sound in i think. or did you upgrade to natty?
[12:46] <jtv> wgrant: the output is in /srv/launchpad.net/codelines/current/jtv7.log
[12:47] <wgrant> I was about to ask.
[12:47] <wgrant> Thanks.
[12:48] <wgrant> 2011-04-05 11:10:57 DEBUG   Publishing The Maverick Meerkat-RELEASE
[12:48] <wgrant> 2011-04-05 11:10:57 DEBUG   Attempting to publish pending sources.
[12:48] <wgrant> 2011-04-05 11:11:00 DEBUG   Added /srv/launchpad.net/ubuntu-archive/ubuntu/pool/main/h/hello/hello_2.6-1lp5.dsc from library
[12:48] <wgrant> It really finished in only 27 minutes?
[12:49] <wgrant> Dirty maverick-release should have put you through at least 3-4 hours of pain...
[12:49] <deryck> wallyworld_, yeah, I have a server I share with a friend and he upgraded over night.
[12:49] <jtv> wgrant: I ripped out all the explicit gc and the cache invalidations.
[12:49] <wgrant> jtv: Ah, you can close one of my bugs, then.
[12:49] <jtv> No longer necessary with the generational cache.
[12:49] <wgrant> jtv: But that wasn't the bit that made it take hours.
[12:50] <jtv> What was?
[12:50] <wgrant> (I had a branch that did the same thing, but it didn't definitely improve performance)
[12:50] <wgrant> Queries when generating override and file lists.
[12:51] <wgrant> Huh.
[12:51] <wgrant> Only took 7 minutes to generate binary file lists.
[12:51] <wgrant> WTF?
[12:51] <wgrant> This is reason to be extremely suspicious about its results.
[12:51] <jtv> Mind you, the various calls to publish-distro etc. are all in one process now, so we may be getting better cache re-use.
[12:52] <jtv> (When combined with not continually invalidating or flushing the cache, of course)
[12:52] <jtv> But by all means, please be suspicious about the results!  That's what I really need here.
[12:52] <wgrant> ... oh.
[12:52] <wgrant> You deleted publishingtunableloop.
[12:52] <wgrant> *That* is the important bit.
[12:52] <jtv> Yes
[12:53] <jtv> Because it did explicit gc and cache invalidation.
[12:53] <wgrant> As long as we're not running into RAM usage issues (due to materialising a huge resultset in one hit), that is fine and should be a massive benefit.
[12:53] <jtv> And essentially nothing else.
[12:54] <wgrant> The issue was that it did binary file lists in 16ish batches of 10000 each, each of which took 8-9 minutes for the DB to calculate due to the compound sort key.
[12:54] <jtv> Yeah… I figured (and documented in the MP) that if there are still problems of this nature, we're probably better off taking a fresh, post-StupidCache, post-bash look at them.
[12:54] <wgrant> Actually, I think I did test this once before.
[12:54] <wgrant> By hacking tunableloop to always use a batch size of 200000.
[12:55] <jtv> It pains me to admit it, but the loop tuner was never the right tool for this particular job.
[12:55] <wgrant> But it wasn't quite so wildly successful, possibly because of the remaining cache crap.
[12:56] <jtv> Bear in mind by the way that we no longer have the infinite-caching problem.
[12:56] <wgrant> RIght.
[12:56] <jtv> So if we still have memory problems in this script, it's going to show up as excessive database waits rather than as swap or OOM.
[12:57] <jtv> But I'd be very much interested in your appraisal of the data that this run produced.
[13:00] <wgrant> launchpad@mawson:/srv/launchpad.net/ubuntu-archive/ubuntu$ ls -l dists/maverick/main/source/Sources
[13:00] <wgrant> -rw-r--r-- 1 launchpad launchpad 3763543 Apr  5 11:31 dists/maverick/main/source/Sources
[13:00] <wgrant> That shouldn't exist any more, should it?
[13:01] <jtv> wgrant: that's done by one of the run-parts scripts, which I'm not running in this case.
[13:01] <jtv> Basically Ubuntu-specific.
[13:01] <wgrant> jtv: Ah! Well, apart from that it looks pretty reasonable. I will throw more at it tomorrow, when I am meant to be working.
[13:01] <wgrant> Well done on destroying PublishingTunableLoop.
[13:01] <wgrant> Probably won't help productive by more than a couple of minutes, but helps DF massively...
[13:02] <jtv> (But actually glad you're spotting these things, because it makes it much more likely that you'd have spotted any noticeable oversights)
[13:02] <jtv> Thanks very much for looking into this.
[13:02] <wgrant> s/productive/production/, grar.
[13:02] <jtv> Next time let's run domination in parallel.  :-)
[13:03] <wgrant> Hmm?
[13:03] <wgrant> You can run judgeSuperseded in parallel with index generation if you really want to, but that's about it...
[13:03] <jtv> Just guessing: maybe domination is embarrassingly parallelizable across architectures.
[13:03] <wgrant> Indeed.
[13:04] <wgrant> But it should also be blindingly fast now.
[13:04] <jtv> And it takes a fair bit of the time, actually.
[13:04] <wgrant> Maybe on mawson.
[13:04] <wgrant> On prod each pocket should be no more than 1.5s or so.
[13:04] <jtv> On this run, I see about 4 minutes going into it.  That's a sizable percentage of overall runtime.
[13:05] <jtv> Not that parallel runs would necessarily help mawson.  :)
[13:05] <StevenK> I think parallel runs on mawson might make the chassis itself glow red hot.
[13:05] <wgrant> jtv: You can see it speed up significantly as the caches get hotter.
[13:05] <jtv> Kewl!
[13:06] <bigjools> StevenK: rofl
[13:06] <wgrant> amd64 takes 59s, armel 15s, i386 13s, and it continues.
[13:06] <jtv> yeah nice
[13:06] <wgrant> Source still takes 90s, but it's more like 2s on prod (was 150s until I fixed it six months ago)
[13:07] <wgrant> wildcherry has fewer issues with caches, given that it doesn't have 4GiB and all of the LP services.
[13:08] <henninge> rvba: Just to let you know, I am working on your review.
[13:08] <jtv> wgrant: by the way you'll notice complaints about stuff not being signed.  You probably saw this coming, but that's because gpg signing also is in a run-parts script now.
[13:08] <rvba> henninge: great.
[13:08] <henninge> rvba: Here is as far as I have come and there are a few things that need attention.
[13:08] <wgrant> jtv: Yeah, I'll walk through everything, get more stuff publishable, populate partner, add fake keys, enable the rest of run-parts, etc. tomorrow and see what breaks.
[13:08] <henninge> rvba: if you want you can start on those. http://paste.ubuntu.com/589661/
[13:09] <wgrant> Then I may change my qa-hellno to qa-ok.
[13:10] <jtv> wgrant: I'm so glad I don't know how to do all of that.  I backed up before my run using cp -r /srv/launchpad.net/ubuntu-archive/ubuntu/dists /srv/launchpad.net/dists.bak
[13:10] <StevenK> wgrant: You mean it isn't qa-overmydeadbody ?
[13:10] <bigjools> jtv, wgrant: I'm not entirely convinced about those complaints being to do with lack of signing
[13:10] <jtv> wgrant: do you want me to put that old dists back in place?
[13:10] <bigjools> since it's never been an issue on DF before
[13:10] <jtv> Invalid archive signature?  It could be reading the wrong file or something I guess
[13:12] <jtv> bigjools: you're right… files seem to be missing
[13:12] <bigjools> jtv: which equates to a further path issue
[13:12] <jtv> Yes, and it's not the partner path
[13:13] <bigjools> well, in fact the original path issue :)
[13:14] <jtv> Hmm maybe not…  In the example I'm looking at, the diff, dsc, and orig tarball are all there but the deb isn't.
[13:14] <jtv> Where should that deb have come from?  (If it's the librarian, then I can think of a reason)
[13:21] <wgrant> bigjools: I didn't see those errors. I'm trying not to look at it in depth yet.
[13:22] <wgrant> bigjools: But if it's "Invalid archive signature" on a deb, it could be from the failed librarian transfers when I ran the careful publisher.
[13:22] <wgrant> I forget the full list, but fennec was one of them.
[13:22] <wgrant> On most archs its debs failed to transfer properly from production.
[13:22] <wgrant> Is that one of the ones with errors?
[13:24] <jtv> wgrant: fennect looks to be behind a sizable portion of the errors, yes
[13:24] <wgrant> As for partner, there are no fresh uploads and probably nothing existing on disk to index. I will sync and upload stuff tomorrow to test it out.
[13:24] <wgrant> jtv: Aha, great.
[13:24] <wgrant> So it's probably nothing to worry about, but I'll check it out.
[13:24] <jtv> About half the pages of errors are completely full of fennec-related lines
[13:25] <jtv> Then there's python-htmltmpl
[13:25] <jtv> and a bit of microcode.ctl
[13:25] <wgrant> I don't recall those, but possibly because they sound arch-indep.
[13:25] <wgrant> So there would be around 1/5 of the errors.
[13:27] <jtv> I think python-htmltmpl is again repeated lots of times (per arch I guess) and that seems to be most of the rest.
[13:27] <wgrant> I may manually regrab the files tomorrow and see what happens.
[13:27] <wgrant> As well as -C'ing partner.
[13:27] <wgrant> Hopefully that won't take too long.
[13:30] <jtv> One thing that bothers me a lot is the carrying-over of old directories.  For all I know we might not notice if, for instance, we stop generating a file and keep copying an old copy instead.
[13:31] <wgrant> jtv: Yeah, but we have no choice :/ dists isn't all generated by the publisher.
[13:31] <wgrant> Custom uploads end up in there too.
[13:31] <wgrant> Custom uploads are bad in a few ways.
[13:31] <wgrant> And good in not many :(
[13:32] <jtv> Well, here's hoping that we're making some real progress in manageability and transparency of the process.
[13:33] <jtv> Oh, we have another buildbot failure in progress.  :(
[13:35] <wgrant> What has combusted now?
[13:36] <jtv> Dunno summary won't load
[13:36] <wgrant> That's why I asked :/
[13:36] <wgrant> It's just hanging for you too?
[13:37] <jml> I don't see any failures on the waterfall
[13:37] <jtv> Oh drat I'm mis-reading it.
[13:37] <wgrant> I see nothing in stdio.
[13:37] <wgrant> jtv: Ah, good.
[13:38] <jtv> Sorry for the noise.
[13:39] <LPCIBot> Project windmill build #139: STILL FAILING in 1 hr 11 min: https://lpci.wedontsleep.org/job/windmill/139/
[13:39] <wgrant> Not helping, Jenkins.
[13:50] <jtv> wgrant: my fix for the partner archive path is in db-devel now, so if you update df's codebase tomorrow it should be in there.
[13:50] <wgrant> jtv: Great, thanks.
[13:50] <deryck> jml, can you send me a ping at my work email, see if I got mail sorted out now?
[13:50] <jml> deryck: sure.
[13:50] <wgrant> I may merge db-stable into devel again tomorrow, since there are no DB changes.
[13:50] <jtv> I'll clean up my pending merge first.
[13:51] <wgrant> jtv: Which branch is that?
[13:51] <wgrant> jtv: It's fairly critical to sensible running the script.
[13:51] <jtv> The gc/cache cleanup
[13:51] <wgrant> i mean where is it on LP, so I can merge it again tomorrow.
[13:51] <jtv> Alternatively, I could just commit it.
[13:51] <deryck> hurray, mail!  Thanks, jml!
[13:51] <jtv> wgrant: Oh, I was about to give you the pointer.  :)
[13:52] <jtv> wgrant: lp:~jtv/launchpad/db-bug-244328
[13:52] <jtv> Feel free to attach your own kill-kill-kill bug.
[14:20] <rvba> henninge: just pushed the corrections from the first batch of comments you made (Thanks already for the careful review :)).
[14:20] <bigjools> wgrant: hopefully jtv answered all your questions, I was at lunch
[14:20] <jtv> bigjools: well… "is there a God" was a bit of a sticky point
[14:22] <henninge> rvba: I'll have  a look. I just sent off the complete review.
[14:22] <rvba> henninge: great, I'll look into it.
[14:22] <wgrant> bigjools: I think so.
[14:22] <bigjools> jtv: contentious but ultimately easy to answer :)
[14:23] <jtv> bigjools: we've been over this.  You don't count.
[14:25] <LPCIBot> Project windmill build #140: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill/140/
[14:29] <rvba> henninge: a small question about your comment of my use of @@. I though this was the only way to access an attribute on the default _view_ attached to this object. But since it's not used in the code base, I'd like to know how else this can be done ...
[14:35] <henninge> rvba: oh, this is an attribute of the view?
[14:35] <rvba> henninge: yes
[14:35] <henninge> ah yes ;)
[14:35] <henninge> rvba: view/attribute
[14:36] <rvba> henninge: but the view available in the page is attached to another object
[14:36] <rvba> henninge: let me explain:
[14:36] <henninge> hm
[14:36] <rvba> I need to access an attribute of the view attached to an object inside a loop
[14:37] <rvba> the current view is attached to the context
[14:37] <rvba> I need to access another view
[14:37] <henninge> rvba: I understand
[14:37] <henninge> rvba: now the notation makes sense, too.
[14:40] <henninge> rvba: now I wonder, too, why it is not used anywhere else
[14:40]  * henninge greps again
[14:40] <rvba> indeed ...
[14:41] <rvba> if you create a small template fragment that is used inside the loop then it's not necessary to use this @@ because you can make the association (view/object) for this fragment only
[14:42] <rvba> but if all you need is to get an attribute from a view, adding a 3 lines template fragment looks overkill.
[14:44] <henninge> rvba: I think the usual approach would be to push this into the model
[14:45] <henninge> rvba: In this case, DistroSeriesDifference should have parent_source_package and source_package attributes.
[14:46] <henninge> rvba: and you'd use "difference/parent_source_package/fmt:url" in the template.
[14:46] <rvba> henninge: I confess I don't really like putting things like this into the model
[14:47] <rvba> henninge: but if it's the way it's done in the rest of the code I'll do it
[14:47] <henninge> rvba: that's my interpretation, yes
[14:47] <rvba> henninge: what does this /fmt:url do exactly?
[14:48] <henninge> rvba: it gets the canonical_url for the object,  the same thing the function does.
[14:48] <rvba> henninge: ok, I get it.
[14:48] <henninge> so you wouldn't need that for tal:condition, but for tal:attributes
[14:49] <rvba> ok
[14:49] <henninge> rvba: to me it sounds better to not have the different view depend on each other too much.
[14:49] <henninge> s/view/views/
[14:50] <rvba> henninge: good point
[14:50] <henninge> rvba: I'd say it makes the code more fragile.
[14:50] <henninge> we have a pretty close relationship between view and template in Launchpad.
[14:51] <henninge> rvba: Ha!
[14:51] <henninge> pub = IResultSet(pubs).one()
[14:52] <henninge> Database code does not belong in view code, that much I know. ;-)
[14:52] <henninge> rvba: so this is a strong indicator that these should be pushed into the model.
[14:52] <rvba> henninge: that's right. You win :)
[14:52] <henninge> :-D
[14:52] <henninge> Launchpad wins!
[14:53] <rvba> henninge: all right ... I'll go though the rest of your remarks and get back to you when it's done
[14:54] <bigjools> henninge: you should explain why "Database code does not belong in view code" so that rvba learns something :)
[14:54] <henninge> bigjools: Hey, I am only going through the motions here ... :-P
[14:55] <rvba> I think it's pretty standard isn't it? Views are for fetching data from models and getting it ready for the templates.
[14:55] <bigjools> the main reason is security
[14:56] <henninge> rvba: it's also because you should only handle security proxied objects in view code.
[14:56] <bigjools> there we go :)
[14:56] <henninge> rvba: yeah, it's actually the main reason
[14:56] <henninge> ;-)
[14:56] <rvba> ok, makes sense
[14:57] <henninge> rvba: plain database queries will give you naked objects.
[14:57] <henninge> can't have that in public ...
[14:57] <rvba> right
[14:58] <rvba> henninge: thanks again, I'm learning a lot thanks to this review process I reckon :)
[15:00] <bigjools> rvba: generally if view code needs to get a database object, it does a query via the context, or uses a secured utility
[15:04]  * jml mumbles something about sorting & views.
[15:17] <bigjools> allenap: "field.summary": u"Even The Register likes it." - just made me lose a mouthful of coffee
[15:17] <allenap> bigjools: Hehe :)
[15:23] <bigjools> allenap: you have a typo in lib/lp/registry/help/distribution-add-series.html
[15:24] <allenap> bigjools: Dang.
[15:24] <bigjools> "its version is used instread"
[15:24] <allenap> bigjools: Nothing wrong with that ;)
[15:24] <allenap> That's how they say it round here.
[15:24] <bigjools> if you're dyslexic
[15:25] <allenap> bigjools: I'll fix it now.
[15:25] <bigjools> allenap: I could make more comments about round ther e:)
[15:25] <bigjools> but they would apply to round here too
[16:13] <jcsackett> anyone happen to know if logging something as error in our cronscripts automatically creates an OOPs?
[16:15] <sinzui> jcsackett: it is not automatic
[16:15] <sinzui> jcsackett: an text can be logged as an error. We want an exception.
[16:16] <jcsackett> sinzui: right, i was double checking. b/c once i was able to get tests for the hardwardb stuff running, the call site I saw that corresponded to the OOPs error msg didn't cause an exception. :-(
[16:19] <sinzui> jcsackett: look for globalErrorUtility or a subclass. it will call handling()
[16:19] <jcsackett> sinzui: ah, okay.
[16:23] <abentley> deryck: I've got the form showing: http://people.canonical.com/~abentley/translations-usage.png Just want to confirm this is really what you want before I go implement saving.
[16:24]  * deryck looks
[16:24] <deryck> abentley, yeah, looks good to me.
[16:25] <abentley> deryck: alrighty then.
[16:43] <bac> hey deryck, is this type of markup (found in several bugs pt files) still valid?  i don't see that file being built anymore.
[16:43] <bac> http://paste.ubuntu.com/589741/
[16:45] <deryck> bac, we shouldn't be doing that anymore.
[16:45] <bac> deryck: thanks for the confirmation
[16:45] <deryck> bac, np
[16:54] <bac> deryck: would you mind looking at the top of soyuz/templates/archive-copy-packages.pt?  i assume it is wrong too but don't know why it was ever there.
[16:55] <deryck> ok, looking....
[16:56] <deryck> bac, yeah, it's wrong too
[16:56] <deryck> not needed.
[16:56] <deryck> anything in lib/lp/APPNAME/javascript gets pulled in automatically.
[16:56] <bac> so anything loading specific js files from icing/build is wrong
[16:57] <deryck> bac, yup.
[16:57] <deryck> bac, it's loading files twice in devmode but no harm to production.
[16:58] <bac> deryck: well those files don't exist in devmode, so it is oopsing trying to load them
[16:58] <deryck> bac, ah, right.
[16:58] <bac> which confuses people, e.g. me
[16:59] <deryck> gotcha
[17:18] <bac> gmb: can you have a look at https://code.launchpad.net/~bac/launchpad/remove-old-devmode-js/+merge/56400
[17:19]  * bac lunches
[17:37] <gmb> bac: Sure
[17:43] <LPCIBot> Project windmill build #141: STILL FAILING in 1 hr 15 min: https://lpci.wedontsleep.org/job/windmill/141/
[17:43] <gmb> bac: r=me
[17:54] <henninge> rvba: still around?
[17:54] <rvba> henninge: yes
[17:55] <henninge> why did you have to use structured().escapedtext?
[17:56] <henninge> I mean, I thought just structured() would have been enough?
[17:56] <rvba> I did that as first but then I get the __repr__ version of the object in my page ... and it's not pretty
[17:58] <rvba> s/as first/at first/
[17:58] <mrevell> Night!#
[18:02] <jml> flacoste: you have disappeared from our secret squirrel IRC server!
[18:02] <flacoste> jml: really!?!
[18:02] <jml> flacoste: yep.  flacoste has quit (Connection reset by peer)
[18:03] <bigjools> night all
[18:09] <henninge> rvba: really? that's interesting.
[18:10] <henninge> rvba: you mean this gives you a _repr_ of the structured object?
[18:10] <henninge> 871	+      <p><tal:replace replace="structure view/explanation" /></p>
[18:10] <rvba> henninge: yes
[18:11] <henninge> I wonder if wgrant has already been changing things ...
[18:11] <rvba> I saw quite a few .escapedtext in the code ...
[18:11]  * henninge checks places he knows
[18:13] <henninge> hm, those that I had don't go straight to TAL.
[18:14] <henninge> rvba: see, now I learned something, too ... ;-)
[18:14] <rvba> henninge: :)
[18:16] <rvba> henninge: the proper way might be to do this:
[18:16] <rvba> <tal:replace replace="structure view/explanation/escapedtext" />
[18:16] <rvba> not much difference though
[18:17] <rvba> but the code is full of these
[18:17] <rvba> henninge: I'll have to get going is a few
[18:18] <rvba> s/is/in/
[18:19] <henninge> rvba: I am not done yet, I am sorry. We will have to do another short round tomorrow morning.
[18:19] <henninge> I'll finish my review of your changes tonight, so you can have them in the morning.
[18:19] <rvba> henninge: sounds perfect
[18:20] <rvba> henninge: see you tomorrow
[18:20] <henninge> rvba: see you! ;)
[19:05] <bac> hi deryck, sinzui: we've got a few places in our JS that uses Y.fail.  they seem to be untested and calls to it actually fail.  do either of you have any experience with it?
[19:07] <deryck> bac: it's a test module method, no?  We shouldn't be using that in regular code.
[19:07] <bac> deryck: that is my impression too.  but i see it in many places
[19:07] <bac> deryck: should we just be throwing an error?
[19:08] <deryck> bac: yeah, I think we either want to use Y.error directly or the showError mechanism we have.
[19:10] <bac> deryck: it is in five modules, including lp.js and client.js
[19:10] <deryck> hmmmm, ok
[19:10] <abentley> deryck: how would I get the URL for a translation_group from its name in Javascript?
[19:11] <abentley> deryck: I figure translation_groups.getByName, but I don't know how to get translation_groups.
[19:12] <bac> deryck: and i just discovered it is part of 'test', so you have to include 'test' in production code, which is vile.
[19:13] <deryck> bac: yeah, agreed.  so the client module looks like it's trying to log the fail. I think Y.error or even a simple Y.log('some msg', 'error') is enough there.
[19:13] <bac> and it points to none of those paths ever being exercised...
[19:13] <deryck> bac: and I think that ^^ could be the basic pattern.  I'm certain we don't want Y.fail in js code.
[19:13] <deryck> right
[19:14] <bac> ok
[19:14] <deryck> abentley: are they exported in the api?  Can you get them from an api get?
[19:14] <abentley> deryck: yes, they're exported in the API.  I don't know how to get them from an API get.
[19:18] <deryck> I'm not sure either.  I'm thinking and looking at code.
[19:20] <abentley> deryck: it seems like there should be a generic answer to "how do I get the URI for a collection", and then the rest would fall into place.
[19:20] <deryck> yeah
[19:24] <deryck> abentley: yeah, so it's the same as an entry in the client, right.  Y.lp.client.Collection.  but like you say you need the URI.  I really don't know how you get that.  trying to find an example somewhere.
[19:26] <deryck> abentley: where are you getting the name from?
[19:27] <abentley> deryck: I'm getting it from the form data.
[19:28] <abentley> deryck: from the form I posted a screenshot of earlier.
[19:28] <deryck> right
[19:28] <abentley> deryck: Unless I'm doing it wrong?  (I'd love to be doing it wrong!)
[19:29] <deryck> abentley: are you doing an XHR post of the form on submit?  Or trying to handle each piece with the API?
[19:30] <abentley> deryck: the latter.
[19:30] <deryck> abentley: can you not make it easier by doing a single form post with the data?
[19:31] <abentley> deryck: It's not something I'd thought of 'till now.
[19:31] <abentley> deryck: how would that work?
[19:32] <deryck> abentley: do an XHR post to the page that normally handles this step.  on success flash green and go to next part of page.  report if it errors.
[19:34] <deryck> abentley: we may not do this anywhere else.  I can't find an example.  But you would just use Y.io directly.
[19:34] <abentley> deryck: could you give me more detail or an example of the first piece?
[19:34] <abentley> deryck: That is, making the XHR post.
[19:36] <deryck> abentley: typing up something....
[19:42] <deryck> abentley: something like this: http://pastebin.ubuntu.com/589828/
[19:43] <rvba> henninge: still around?
[19:43] <henninge> rvba: yes and no ;)
[19:44] <rvba> henninge: I see ... just a quick question then if you don't mind
[19:44] <henninge> rvba: go ahead
[19:45] <rvba> henninge: in your review you advise me to move back getParentPackageSetsNames into the views ... but my understanding of our previsou co
[19:45] <rvba> sorry ...
[19:45] <rvba> previous conversation was that you wanted these methods in the model to avoid the clumsy @@ inside the template
[19:46] <henninge> rvba: sorry, there must have been some misunderstanding, then.
[19:46] <rvba> henninge: I understood that the main point was security.
[19:47] <rvba> henninge: but still, I'll have to use @@ to be able to call a method from a view (but not the "main" view) associated with an object in the template.
[19:47] <henninge> rvba: yes, that's why (parent_)source_package_release belong in the model.
[19:48] <abentley> deryck: thanks.  I think I can hack that.
[19:48] <henninge> rvba: no, you don't ;)
[19:48] <deryck> abentley: cool.  hope it helps.
[19:48] <rvba> henninge: then I think I missed something
[19:49] <henninge> rvba: which view is the one that the template belongs to?
[19:50] <henninge> rvba: ah here, DistroSeriesMissingPackages
[19:50] <rvba> henninge: yes
[19:50] <henninge> that's the view that needs the formatting code.
[19:50] <rvba> henninge: but I'll need to call a view that is acting on the difference, not the distroseries
[19:51] <rvba> that's the part I don't understand properly I guess ... how to call a method, not on the main view of the template ... but on the view associated with the many differences displayed on the page
[19:51] <henninge> rvba: aha, difference is from a tal:repeat
[19:51] <rvba> henninge: right
[19:52] <rvba> henninge: there is my problem :-)
[19:52] <rvba> henninge: hence the @@
[19:52] <henninge> rvba: yes, you have too options to avoid the @@
[19:53] <henninge> rvba: option 1: construct the list in TAL
[19:53] <rvba> henninge: yes, I can use ','.join directly inside the TAL
[19:54]  * rvba greps
[19:54] <henninge> nah, avoid python in TAL at all costs.
[19:54] <rvba> right
[19:54] <henninge> rvba: you could do a tal repeat over difference.source_package_release
[19:55] <henninge> and use tal:condition on the "last" variable (I forget the details of tal:repat here) to add a comma or not.
[19:56] <henninge> rvba: option 2: construct it in the view
[19:56] <rvba> henninge: got it ... quite ugly though.
[19:56] <henninge> yes, I agree
[19:56] <rvba> (I'm talking about the repeat)
[19:56] <henninge> I know
[19:57] <henninge> rvba: but then you will not be able to loop over differences/batch but will have to create your own list.
[19:57] <henninge> which works ok
[19:58] <rvba> still looks a little bit of a hack to me though :-)
[19:58] <rvba> but I'm glad to use any method that works
[19:59] <henninge> rvba: currently differences is the content of view/cached_differences.
[19:59] <rvba> ye
[19:59] <rvba> s
[20:00] <henninge> rvba: you can instead create a propety that iterates over cached_differences internally and yields dicts of information
[20:00] <rvba> I think I get the idea: create a simple list wrapper with the differences and the formatted packagesets
[20:00] <rvba> right
[20:01] <henninge> yup
[20:01]  * henninge goes back to do other stuff
[20:01] <rvba> henninge: thanks for your time, it's late for the two of us ... I'll sleep over this and see if the morning brings a new idea.
[20:02] <henninge> rvba: great idea
[20:02] <henninge> ;-)
[20:02]  * henninge cannot sleep yet, though
[20:02]  * rvba meither
[20:02] <rvba> s/meither/neither/
[20:14] <lifeless> morning
[20:14] <lifeless> deryck: hi
[20:15] <deryck> hi lifeless
[20:16] <lifeless> deryck: bug heat decay
[20:16] <deryck> ah yes
[20:16] <deryck> we talked about that at the thunderdome, no?
[20:16] <lifeless> deryck: stub has identified *something* causing rapid index bloat in bug/bugtask
[20:16] <lifeless> deryck: we talked about the rendering stuff - threshold and the curve fitting function
[20:17] <deryck> ok, gotcha.  new issues now.  the joys of heat! :-)
[20:17] <lifeless> deryck: stub is still gathering data, but it may be the bug heat decay (because every row in bug (and now bugtask)) is being rewritten at high frequency
[20:18] <lifeless> I'm being opportunistic, since you're still here ;) and asking about how important the decay aspect is
[20:18] <lifeless> like, if we removed the 'time since last alteration' component from the heat function, do we think folk would care?
[20:19] <deryck> lifeless: it's very important actually.  the decay helps bugs not sit in the top 10 hot bugs too long.  bugs can gain heat quickly and they need to decay quickly or it gets odd looking on that bugs home page.
[20:19] <deryck> lifeless: the decay happens via the offline job or cron, though.  So it could be run less frequently.
[20:19] <lifeless> deryck: did we try it without the decay at any point ?
[20:20] <lifeless> deryck: I ask because hot bugs are often lightning rods anyway
[20:20] <lifeless> deryck: which means they get meaningless comments that have the effect of nullifying the decay
[20:20] <deryck> lifeless: we tried various forms of heat.  we never tried without the decay alone.
[20:21] <deryck> lifeless: decay helps mitigate the lightening rod.  comments don't add heat, either.
[20:22] <deryck> lifeless: so I think the decay bit runs in garbo.  perhaps we could go daily instead of hourly?  I don't recall how frequently it runs actually.
[20:24] <lifeless> deryck: the frequency the task runs isn't the issue
[20:24] <lifeless> deryck: its the rewriting of the entire table over the course of a week
[20:24] <lifeless> deryck: *if* this is the problem, its baked into the use of a decay function at all.
[20:24] <lifeless> deryck: it may not be
[20:24] <deryck> lifeless: ah, ok.
[20:24] <lifeless> deryck: like I say, I'm gathering data.
[20:25] <deryck> lifeless: and, to be clear, there isn't a decay funtion per se.  There is one calculation function. part of that function handles decay
[20:26] <lifeless> deryck: yep, I'm on that
[20:26] <deryck> ok, cool
[20:26] <lifeless> update_bug_date_last_updated updates bug_last_updated, which is the key thing for the decay, on every IObjectModified event
[20:27] <lifeless> which includes
[20:27] <lifeless>         for="lp.bugs.interfaces.bugmessage.IBugMessage                 lazr.lifecycle.interfaces.IObjectCreatedEvent"
[20:27] <lifeless>         handler="lp.bugs.subscribers.buglastupdated.update_bug_date_last_updated"/>
[20:27] <lifeless> deryck: so commenting on a bug freshens its heat
[20:27] <lifeless> deryck: that might not have been the intent, but it is the implementation :)
[20:28] <deryck> lifeless: I don't think that's entirely correct.  update_bug_date_last_updated has nothing to do with heat, IIRC.
[20:28] <lifeless> in trusted.sql
[20:29] <lifeless>     days_since_last_update = (datetime.utcnow() - date_last_updated).days
[20:29] <deryck> lifeless: sorry to seem dumb, I'm in the middle of natty upgrade and get really look
[20:29] <lifeless>     total_heat = int(total_heat * (0.99 ** days_since_last_update))
[20:30] <deryck> lifeless: right.  that heat function *uses* date_last_updating but the event that causes date_last_updated to be updated doesn't cause the heat function to run.
[20:30] <lifeless> deryck: right
[20:31] <lifeless> deryck: but the reason we have to recalculate the heat on every bug
[20:31] <lifeless> deryck: is because date_last_updated is part of the function
[20:31] <lifeless> [and date_created]
[20:32] <lifeless> deryck: I was analysing the 'commenting on a bug does not affect its heat' - but it does
[20:32] <lifeless> deryck: because it resets date_last_updated
[20:33] <lifeless> deryck: anyhow, will leave you to your upgrade :) stub is gathering concrete data to pin down the cause of bloat
[20:33] <deryck> lifeless: well indirectly.  commenting affects date_last_updated.  And that factors into heat.  But commenting does not trigger a recalculation of heat.  Changing those dates does not trigger a recalculation of heat.
[20:33] <deryck> lifeless: ok, fair enough :-)  Good luck with it.
[20:34] <lifeless> deryck: thanks
[20:34]  * sinzui just discovered multitouch is now enabled on his macbook
[20:35] <jcsackett> sinzui: really? how well is it working?
[20:36] <sinzui> three fingers: resize/move via love handles. four fingers: opens the dash
[20:38] <sinzui> contacts synced for the first time in 4 months this morning too. The test will be my next update though. My primary computer has only synced twice in 18 months
[20:39] <lifeless> deryck: I see the confusion I was causing; I was saying that commenting on a bug stops the 'if days_since_last_update > 0:' condition firing
[20:39] <deryck> ah ha
[20:40] <lifeless> deryck: any bug commented on less than 1 day before the background task to update heat, will have an unscaled heat
[20:40] <deryck> lifeless: I see what you mean now
[20:40] <lifeless> deryck: and also that bugs which are in the top 10 will likely get a continual stream of comments - they are lightning rods
[20:41] <deryck> right
[20:41] <lifeless> deryck: all they need is one comment every week or so to stop them dropping out
[20:41] <deryck> right
[20:41] <jcsackett> sinzui: nifty.
[20:41] <lifeless> deryck: which is why I'm wondering if there is any /practical/ impact of dropping the date based scaling
[20:42] <sinzui> oh, hell
[20:42]  * sinzui gets children
[20:42] <lifeless> deryck: IFF stub finds that it is the heat routine causing issues
[20:42] <deryck> lifeless: right.  given that, maybe there's no harm.
[20:42] <deryck> lifeless: we could try and see.
[20:42] <lifeless> yeah
[20:42] <lifeless> there is no rush, not till we know the bloat cause
[20:43] <lifeless> thanks for the time!
[20:44] <deryck> np!  Thanks for bringing it up.
[21:05] <deryck> Later on, everyone.
[21:17] <lifeless> wgrant: would you like the honours ?
[21:52] <LPCIBot> Project windmill build #142: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill/142/
[22:10]  * mwhudson_ raised an eyebrow at https://launchpad.net/c++
[22:11] <lifeless> -lol-
[22:11] <lifeless> terrible project name
[22:12] <mwhudson> yeah
[22:12] <mwhudson> jml: hooray for the upgrade to twisted 11 being so easy!
[22:12] <lifeless> 933, in _get_nodes
[22:12] <lifeless>     found[idx] = cache[idx]
[22:12] <lifeless> RuntimeError: maximum recursion depth exceeded
[22:36] <sinzui> jcsackett:
[22:36] <sinzui> ping
[22:37]  * sinzui is on stupid medication today
[22:50] <jcsackett> sinzui: pong.
[22:50] <jcsackett> sorry, didn't hear the notification.
[22:51] <sinzui> jcsackett: mumble?
[22:59]  * wallyworld sad. coffee machine broken :-(
[23:37] <lifeless> gmb: ping
[23:38] <lifeless> gmb: lp:~gmb/launchpad/bug-1-timeout - this will cause timeouts on bug message collections via the API I think
[23:42] <poolie> hi lifeless
[23:46] <lifeless> gmb: s/timeouts/bad-data/ - it needs rolling back, I've explained in the bug
[23:46] <lifeless> hi poolie
[23:46] <wgrant> lifeless: Which honours?
[23:46] <lifeless> wgrant: deleting shipit
[23:47] <wgrant> Woot.
[23:47] <wgrant> I wasn't sufficiently up to date on email.
[23:47] <wgrant> But yay.
[23:47] <wgrant> Is production sufficiently gone?
[23:48] <lifeless> see chat with chex in -ops an hour back
[23:49] <wgrant> So that looks like a yes.
[23:49] <wgrant> And if not, then the unused shipit appservers will break, oh no.
[23:49] <wgrant> This is very good news.
[23:50] <wgrant> We can finish purging Account.
[23:50] <wgrant> And then delete AccountPassword and eventually Account itself!
[23:50] <wgrant> And we will be sensible again!
[23:51] <lifeless> VPC 4 eva
[23:51] <wgrant> Yes.
[23:52] <wgrant> lifeless: Have you rolled back gmb's thing?
[23:52] <lifeless> not yet
[23:52] <lifeless> I have to pop out for a bit
[23:52] <lifeless> if you want to do it yourself, that would be cool
[23:52] <lifeless> I can't see any good reason for him to be collecting /all/ bug messages for bug 1 in his code
[23:52] <_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> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:I
[23:52] <lifeless> so I suspect the change is actually entirely different
[23:53] <LPCIBot> Project windmill build #143: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill/143/
[23:53] <lifeless> change needed is entirely different, I mean
[23:53] <wgrant> OK, I'll check it and roll it back.
[23:53] <lifeless> thanks
[23:54] <lifeless> have we seen an OOPS for this in the oops reports?
[23:55] <lifeless> -> bbiab
[23:55] <jml> mwhudson: hah!
[23:56] <mwhudson> jml: ?
[23:56] <jml> mwhudson: it took way longer than you might think, because of two separate spurious test failures during ec2 and a testfix mode when I went to land today
[23:56] <jml> mwhudson: but the patch was small :)
[23:57] <mwhudson> jml: well, ok, so "modulo usual launchpad development craptitude"?
[23:57] <jml> mwhudson: yeah, modulo that, it was a piece of cake
[23:57] <jml> mwhudson: I wish every Python library cared as much about backwards compatibility.
[23:58] <jml> anyway, off to bed
[23:58] <jml> g'night.