[00:08] <kfogel> jml: morning!
[00:08] <mwhudson> thumper: https://bugs.edge.launchpad.net/launchpad-code/+bug/430354
[00:08] <mup> Bug #430354: BazaarBrachStore needs to use push --overwrite <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/430354>
[00:08] <thumper> mwhudson: ta
[00:08] <mwhudson> jml: the bzr-git tests are failing in that not-really-failing way :(
[00:09] <jml> :(
[00:09] <jml> kfogel, hi :)
[00:11] <mwhudson> jml: do you know how i can find out what the failure actually is?
[00:12] <jml> mwhudson, what are the circumstances?
[00:12] <jml> mwhudson, I'm afraid I know next to nothing about the problem.
[00:13] <mwhudson> jml: https://pastebin.canonical.com/22151/
[00:13] <jml> oh _those_
[00:15] <jml> mwhudson, I'll need a coffee to help you properly, but I think I've put most of the relevant info in a bug report
[00:15] <mwhudson> jml: can you remember which bug report ?
[00:16] <jml> mwhudson, I'm looking for it now.
[00:17] <jml> mwhudson, http://twistedmatrix.com/trac/ticket/4003
[00:18] <jml> there's one in Launchpad...
[00:18] <mwhudson> i've found the launchpad one
[00:18] <jml> mwhudson, what is it?
[00:18] <mwhudson> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/425113
[00:18] <mup> Bug #425113: Some tests can fail without detection <build-infrastructure> <Launchpad Foundations:Triaged> <Twisted:Unknown> <https://launchpad.net/bugs/425113>
[00:18] <mwhudson> it wasn't triaged (!)
[00:20] <jml> launchpad overall is rather poor at triage
[00:20] <mwhudson> man wtf
[00:21] <mwhudson> oh
[00:22] <jml> mwhudson, it's a nasty problem.
[00:22] <jml> mwhudson, I can try to address it if you'd like, but I'd really also like to finish off the permissions branch I've started.
[00:22] <mwhudson> jml: i'll dig for a moment myself
[00:23] <jml> mwhudson, ok. let me know if you want context or to bounce ideas.
[00:29] <thumper> mwhudson: how do you invoke ec2test now it is a module in the tree?
[00:30] <mwhudson> thumper: ./utilites/ec2test.py is still tehre
[00:30] <thumper> mwhudson: ok
[00:30] <thumper> mwhudson: I noticed the move, but not the addition
[00:31] <thumper> mwhudson: :(
[00:31] <mwhudson> thumper: :( ?
[00:31] <thumper> mwhudson: my "hack" of using an alias for ec2test doesn't work
[00:31] <thumper> now it needs a path
[00:33]  * thumper changes the symlink to an alias
[00:38] <barry> thumper: ping
[00:40] <mwhudson> jml: a fairly small hack to zope.exception gets things working again
[00:41] <jml> mwhudson, oh nice.
[00:41] <jml> mwhudson, diff?
[00:41] <mwhudson> jml: well what's in eggs isn't in a bzr branch of course :/
[00:41] <mwhudson> jml: but it's "f.f_locals" -> getattr(f, 'f_locals', {})
[00:42] <jml> *nod*
[00:42] <thumper> barry: hi
[00:42] <jml> mwhudson, I still suggest twisted should change...
[00:42] <barry> thumper: hi will you be around for a while?  i need to run out before the stores close
[00:42] <thumper> barry: yeah, although I might head out for coffee and lunch soon
[00:42] <barry> thumper: no worries.  it's gonna be 45m-1h anyway i'm guessing
[00:43] <barry> thumper: will ping you when i get back
[00:43] <thumper> ok
[00:44] <mwhudson> jml: yes, but in the interests of not having undetected failures in our test suite...
[00:44] <jml> mwhudson, oh yes.
[00:44] <jml> mwhudson, I'm very happy to have urgent bandaids applied
[00:48] <mwhudson> jml: maybe this is a cleaner/easier band-aid:
[00:48] <mwhudson> from twisted.python.failure import _Frame
[00:48] <mwhudson> _Frame.f_locals = property(lambda self: {})
[00:48] <jml> mwhudson, yeah, I think so.
[01:10] <jml> mwhudson, is there anything you'd like me to do wrt this?
[01:11] <mwhudson> jml: review this branch in a bit, i guess
[01:15] <jml> mwhudson, ok, thanks.
[01:19] <jml> maxb, your unittest branch is up for review
[01:20] <maxb> ok
[01:21] <maxb> or was that a question?
[01:21] <maxb> I know it's up for review, I marked the MP as such
[01:22] <maxb> karmic appears safe again, btw, on amd64 and i386, at least if you're using archive or gb.archive
[01:28] <mwhudson> oh, phew, the failures in the bzr-git tests are really shallow
[01:31] <jml> maxb, sorry, yes it was a question.
[01:31] <jml> maxb, I'll review it :)
[01:32] <jml> oh, in fact I have
[01:32] <jml> hurrah
[01:32] <maxb> You reviewed it without realising?
[01:32] <maxb> :-)
[01:34] <maxb> jml: "peculiarly" as in "why repeat an operation that your base class is already doing?"
[01:34] <jml> maxb, it's been a very distracted morning
[01:35] <jml> maxb, iirc, it's there for Python 2.3 support
[01:35] <jml> but I can't recall exactly.
[01:35]  * jml does a science thing
[01:35] <maxb> fair enough (and that'll be 2.4 support)
[01:35] <jml> maxb, Twisted supports python 2.3 :)
[01:36] <maxb> ok, 2.4 and earlier
[01:36] <maxb> It's just a different way of providing such compatibility to which other TestCase subclasses have taken, and less intrinsically clear that it's there for compatibility
[01:37] <maxb> hmm, I need to write more branches, that's my last one :-)
[01:38] <jml> right.
[01:40] <jml> "WARNING: The following packages cannot be authenticated!"
[01:40] <jml> the list includes libc6.. wtf
[01:46] <mwhudson> sadness is submitting a merge proposal at ??:?5:?? o clock
[01:49] <jml> yeah.
[01:49] <jml> Somebody should do Something about that.
[01:50] <maxb> What's special about ??:?5:?? o clock ?
[01:52] <jml> maxb, the diff on MP pages is generated by a cron job that runs at ??:05:??
[01:53] <jml> rather than by, say, some daemon that's listening for events
[01:55] <mwhudson> jml: thanks for the review
[01:55] <jml> mwhudson, np
[02:35] <barry> thumper: ping
[02:36] <thumper> barry: pong
[02:36] <barry> thumper: is this a good time to talk?
[02:36] <thumper> barry: lets talk titles :)
[02:36] <thumper> yes
[02:36] <barry> thumper: cool.  skype?
[02:36] <thumper> yep
[02:36] <barry> firing it up
[02:37] <jml> barry, hey
[02:37] <barry> jml: hi
[02:37] <jml> barry, I know you're talking to thumper right now, but do you know what's going on with the '+filebug' thing appearing in page titles?
[02:37] <jml> actually what I mean to say is... look at the bug I'm about to link to :)
[02:38] <barry> jml: salgado was supposed to be landing a branch that allowed views to fix this.  don't know if it landed yet
[02:38] <jml> barry, but individual views must fix this?
[02:39] <barry> jml: i haven't looked at his branch, but i believe this is the case.  there was some talk about labels getting in the act but dunno what the state of that is
[02:40] <jml> barry, ok, thanks.
[02:40] <jml> barry, it's a little sad that the default is quite so wrong
[02:42] <barry> jml: agreed
[02:53] <jml> barry, is there something we can do to improve the default?
[02:54] <jml> (also, would it be more convenient for me to raise this on the list?)
[02:54] <barry> jml: i think it would be better to raise it on the list.  i'm not sure what the state of salgado's branch is, or exactly what it changes
[02:54] <jml> barry, ok, thanks.
[03:38]  * jml away for a bit
[03:52] <wgrant> Erm.
[03:52] <wgrant> Why do I see tests for the new braindead titles?
[04:04] <sinzui> wgrant: because we are out of time to do page conversions. It is faster for me to convert pages and send people to add the need breadcrumb adapter afterward
[04:04] <sinzui> wgrant: salgado has a branch that fixes most of the bad breadcrumbs, that will also fix the titles
[04:14] <wgrant> sinzui: Ah, thanks.
[04:14] <sinzui> wgrant: I think I can send every team member to fix breadcrumbs after tomorrow
[04:16] <wgrant> launchpad-project 3.0 is timing out: OOPS-1355EB146
[04:18] <wgrant> Ah, there we go.
[04:19] <wgrant>     At least 1397 queries issued in 15.77 seconds
[04:19] <wgrant> Ah.
[04:27] <thumper> phew
[04:27] <thumper> wow
[04:27] <thumper> which project?
[04:28] <thumper> launchpad-project?
[04:28] <wgrant> thumper: launchpad-project?
[04:28] <wgrant> s/?/./
[04:32]  * thumper wonders where all the queries are :)
[04:34] <ajmitch> 1397? that's a little high
[04:35] <wgrant> thumper: Doesn't the OOPS tell you?
[04:35] <thumper> wgrant: well, yes
[04:36] <thumper> wgrant: well, yes and no
[04:36] <thumper> it'll tell you what they are, but not where they are called from
[04:36] <wgrant> thumper: Ah.
[04:36] <wgrant> I haven't looked extensively at the OOPS format.
[04:38] <thumper> SELECT BugTag.bug, BugTag.id, BugTag.tag FROM BugTag WHERE BugTag.bug = %s ORDER BY BugTag.tag repeated 700 times
[04:38] <wgrant> Ah, of course.
[04:38] <thumper> SELECT OfficialBugTag.distribution, OfficialBugTag.id, OfficialBugTag.product, OfficialBugTag.tag FROM OfficialBugTag WHERE OfficialBugTag.product = %s ORDER BY tag 394 times
[04:38] <thumper> I'm sure it is fast with no data
[04:38] <thumper> :)
[04:38] <wgrant> Indeed.
[04:39]  * wgrant files a bug.
[04:39] <wgrant> Is that malone or launchpad-registry?
[04:40] <sinzui> wgrant: is that the 3.0 milestone page?
[04:40] <wgrant> sinzui: Yes.
[04:40] <sinzui> rock
[04:40] <sinzui> That is my excuse to remove the tags
[04:40] <wgrant> That does not follow.
[04:40] <wgrant> Ah.
[04:41] <sinzui> I think it makes the list hard to read, and I do think they help me understand the bugs I am seeing
[04:41] <wgrant> sinzui: Did you mean "I do not think they help me[...]"?
[04:42] <sinzui> wgrant: yes.
[04:42] <wgrant> sinzui: They should be useful, but are not in their current location.
[04:42] <wgrant> sinzui: And why do I have an empty sidebar on that page?
[04:42] <sinzui> right
[04:42] <wgrant> It takes up some large horizontal fraction of my screen, and is empty.
[04:43] <sinzui> wgrant: You cannot subscribe to bugs on that page?
[04:43]  * sinzui liked the page without the side bar
[04:43] <wgrant> sinzui: I can't. That seems like a bug.
[04:43] <sinzui> It is
[04:43] <wgrant> Oh.
[04:43] <wgrant> It's the project, not product, milestone page.
[04:43] <wgrant> So it's not a real thing to be subscribed to.
[04:44] <sinzui> right...
[04:45] <sinzui> I can make the side discretional in the template.
[04:45] <wgrant> sinzui: But that leaves a largely useless sidebar on other milestones.
[04:46] <wgrant> Is there nowhere better to put the link?
[04:47] <sinzui> I can use a horizontal list after the description. It breaks style and may confuse user, but *I* think it makes the page usable.
[04:47] <stub> huh. I killed rocketfuel-get at the wrong point and managed to lock lp:~launchpad/lp-source-dependencies/trunk. Surprised pulling that branch requires a lock!
[04:47] <wgrant> sinzui: Possibly put it at the bottom of the Activities portlet, with the bug stats?
[04:48] <sinzui> wgrant: Edit and delete do not belong there.
[04:48] <wgrant> sinzui: It's not editing in the traditional sense.
[04:49] <sinzui> agreed, certainly not when the milestone has a release
[04:50] <sinzui> I can make something that looks like the side portlets and float it to the right.
[04:50] <wgrant> https://edge.launchpad.net/~wgrant/+archive/ppa/+packages does something not too bad.
[04:51] <wgrant> Although I'm sure it breaks the guidelines.
[04:51] <wgrant> It might be better if it had the same gray background.
[04:52] <sinzui> It does, but a side portlet with one item is dumb
[04:52] <sinzui> Yea. I will try that after I sleep
[04:52] <wgrant> Great.
[04:57] <thumper> sinzui: what's the status of the page_title breadcrumb?
[04:58] <sinzui> salgdao is doing test fixes to the branch. I think I can land tomorrow
[04:58] <sinzui> thumper: we have made it hard on him since we keep landing pages
[04:59]  * thumper nods
[04:59] <thumper> how come no one told me I needed to create a named IBreadcrumb adapter for "code"?
[04:59] <thumper> I spent ages chasing why I wasn't seeing breadcrumbs
[05:01] <sinzui> thumper: I'll ask salgado to explain what is happening
[05:02] <thumper> sinzui: I think it'll help, but I understand it now
[05:02] <sinzui> barry and salgado had a few meeting about this. I do not think their work plays well together
[05:02] <thumper> sinzui: what would help is knowing how to add additional breadcrumbs
[05:02] <thumper> sinzui: like "Active reviews for XYZ"
[05:03] <thumper> I can create custom IHierarchy adapters (like we have now)
[05:03] <thumper> I'm wondering if there is a simpler way
[05:03] <sinzui> thumper, interesting problem. since crumb is a traversed object, I think you need to pop an object onto the stack, or ...
[05:04] <thumper> it is a view, not an object
[05:04] <thumper> I need to have a fake object that has a breadcrumb relating to the page
[05:04] <sinzui> thumper: views are an object, that is why the view name is in the crumbs
[05:04] <thumper> yeah, yeah
[05:04] <thumper> ...
[05:05] <thumper> I'm trying to fix my last few pages first
[05:05]  * sinzui stumbles to bed
[05:05] <thumper> I want to have a view that is registered against two interfaces
[05:05] <thumper> the problem is that one object implements both interfaces
[05:05] <thumper> :(
[05:06]  * thumper wonders how helpful the #zope channel is
[05:07]  * sidnei raises an eyebrow
[05:07] <sidnei> thumper: you might get better help on #plone
[05:08] <thumper> sidnei: really?
[05:08] <sidnei> thumper: surely
[05:08] <thumper> sidnei: ta
[05:09] <BjornT> thumper: i don't see where the problem is. can you give an example of what you're trying to do?
[05:09] <thumper> BjornT: normally zope complains if there are two directives that can apply to one context object
[05:10] <thumper> BjornT: I have a view that I want for the majority of implements of IHasMergeProposals
[05:10] <jml> back
[05:10] <thumper> BjornT: but I want a special one for IPerson
[05:10] <thumper> BjornT: and a person implements IHasMergeProposals
[05:12] <BjornT> thumper: hmm, ok. i guess zope doesn't complain, but you don't know which of the views will get used for Person?
[05:13] <thumper> I think it does complain
[05:13]  * thumper checks
[05:14] <BjornT> thumper: one solution would be to make IPerson inherit from IHasMergeProposal, except that registry shouldn't depend on code...
[05:14] <wgrant> But Registry depends on *everything*... is that wrong?
[05:14] <thumper> BjornT: it does right now
[05:14] <jml> wgrant, it's a work in progress.
[05:15] <stub> You might be able to do it by registering an adapter for Person -> view rather than IPerson -> view
[05:15] <wgrant> jml: How will that work? Adapting things to ICodeProduct or whatever?
[05:15] <jml> wgrant, well, we already do a great deal of that in lp.code
[05:15] <jml> wgrant, see IBranchTarget, etc.
[05:15] <wgrant> True.
[05:15] <BjornT> wgrant: yes. in an ideal world, everything can depend on registry, but registry shouldn't depend on code, bugs, soyuz, etc.
[05:15] <thumper> BjornT: however our API decisions violate that
[05:15] <wgrant> BjornT: But that seems impractical unless a huge amount of adaption is involved.
[05:15] <jml> wgrant, how it will work with the REST APIs is another, and much more interesting, question.
[05:16] <wgrant> jml: True.
[05:16] <thumper> BjornT: as we mix everything in
[05:16] <jml> wgrant, "impractical"?
[05:16] <jml> wgrant, dumping huge amounts of responsibility on Person and Product is equally impractical.
[05:16] <thumper> BjornT: if there is interface inheritance, does it take the most derived?
[05:17] <wgrant> jml: That's not impractical at all. It makes sense, unless you start splitting the apps up.
[05:17] <BjornT> thumper: yes. i wonder, why do you need breadcrumbs for IHasMergeProposals? what does that view look like?
[05:18] <thumper> BjornT: the breadcrumbs that beuno wanted was to show "Active reviews for XYZ" when looking at a bmp
[05:18] <thumper> I'm not yet convinced
[05:18] <thumper> but at least now I know more what I need to do to fix the breadcrumbs
[05:18] <thumper> BjornT: I'm actually looking at the +activereviews registration
[05:18] <thumper> BjornT: if I can register +activereviews against IHasMergeProposals, but specialise for IPerson
[05:19] <thumper> BjornT: then that is a good thing
[05:19] <jml> wgrant, I disagree.
[05:19] <wgrant> jml: Why does it not make sense to have the methods of a Person on IPerson?
[05:19] <jml> wgrant, it violates the principle of single responsibility
[05:20] <wgrant> jml: A distribution has lots of binary packages. Distribution.searchBinaryPackages should not exist, simply because Soyuz owns BinaryPackageRelease?
[05:20] <jml> wgrant, and they are not, intrinsically, methods of a person
[05:21] <stub> thumper: You can avoid importing code into registry if you want. Create IPersonHasMergeProposals in code and attach that marker interface to Person in code's zcml.
[05:21] <jml> wgrant, I'm not completely happy with the way we've decided to arrange our tree
[05:21] <jml> and soyuz / registry seems a particularly thorny case
[05:21] <wgrant> It is.
[05:22] <wgrant> Some structural things ended up in Registry.
[05:22] <wgrant> But others didn't.
[05:22] <wgrant> And they're all very tightly bound to the rest of Soyuz.
[05:22] <thumper> stub: but it adds a method that a person must implement
[05:22] <thumper> stub: it uses the mixin idiom we use
[05:22] <jml> wgrant, so I would love to hear of better ways to split up the tree
[05:22] <stub> oic.
[05:22] <thumper> although
[05:23] <thumper> ...
[05:23] <wgrant> jml: Run away!
[05:23] <thumper> we could just adapt...
[05:23] <stub> Indeed
[05:23] <thumper> we have the technology
[05:23] <BjornT> thumper: i think you can only do that, if IPerson inherits from IHasMergeProposals. looking at it, it looks like it does do that already. we have to think about how to handle this case with our new code structure
[05:23] <thumper> stub: but right now, with the API, to give a person the abiltiy to getBranches we need a mixin
[05:24] <thumper> BjornT: what are the planned changes?
[05:25] <BjornT> thumper: IPerson is in registry, so it can no longer inherit from application-specific interfaces, like IHasMergeposals, IHasSpecifications, and so on
[05:25] <wgrant> How is lazr.restful going to work?
[05:26] <thumper> BjornT: I'd be happy for the change if we can work out the API
[05:27] <thumper> it seems kinda kludgy right now
[05:27] <BjornT> thumper: yeah. it's a nice idea in theory, but we don't yet know how to actually do it practically
[05:27] <thumper> :)
[05:28] <thumper> thinking is easy
[05:28] <thumper> doing is hard
[05:29] <jml> meh.
[05:29] <jml> thumper, if you don't know what to do, you haven't finished thinking yet.
[05:30] <thumper> :)
[05:30] <thumper> true
[05:30] <thumper> keep thinking jml
[05:30] <jml> (but a good way to push thinking along is to do something!)
[05:51] <lifeless> sounds like you want an Extension concept
[05:53] <thumper> :(
[05:53] <thumper> build failed
[05:53] <thumper> no space left on device
[05:53] <thumper> mwhudson: just rekick?
[05:53] <mwhudson> thumper: yeah :(
[05:56]  * mwhudson is reorganizing ec2tests command line parsing code
[05:56]  * mwhudson is going to the pub later
[05:57] <mwhudson> this is merely a happy coincidence
[06:00] <jml> mwhudson, :D
[06:05] <jml> which database are the tests using?
[06:06] <mwhudson> launchpad_ftest
[06:06] <mwhudson> which iirc doesn't actually exists apart from when a test is running
[06:06] <mwhudson> it's copied from launchpad_ftest_template
[06:07] <jml> thanks.
[06:07] <jml> I'm trying to figure out why this apparently correct code isn't working.
[06:10] <mwhudson> jml: soyuz hates you?
[06:11] <jml> yes.
[06:11] <jml> one day, I hope to make it afraid of me.
[06:13] <thumper> sometimes zope is very cool
[06:14] <jml> thumper, what's it done now?
[06:15] <thumper> jml: registering views against IHasMergeProposals :)
[06:15] <thumper> jml: what zope is good at
[06:15] <jml> thumper, ahh yeah.
[06:15] <thumper> jml: that with branch collection adaptation FTW
[06:16] <jml> heh :)
[06:16] <jml> thumper, jkakar has been sending me interesting emails about use of a similar pattern in landscape
[06:16] <jml> I really must get around to actually reading them and maybe even replying.
[06:19]  * thumper has just fixed (deleted) the last remaining old style template for code
[06:19]  * thumper EODs for now
[06:20] <jml> thumper, yay
[06:20] <jml> thumper, have a good evening
[06:35] <jml> the relationships between soyuz objects are very complicated.
[06:37] <mwhudson> (+1, understatement)
[06:38] <jml> I just hope that this actual behaviour I'm reaching for makes sense.
[06:41] <mwhudson> flymake-mode has changed my life
[06:41] <jml> mwhudson, heh :)
[06:42] <jml> mwhudson, any particular instance this time?
[06:42] <mwhudson> jml: just help when refactoring
[06:42] <mwhudson> jml: copy paste block of code into function
[06:42] <mwhudson> jml: add arguments to function until pink goes away
[06:42] <jml> mwhudson, yeah.
[06:42] <jml> that's a nice thing
[06:43] <jml> although it always makes me wonder how much more automated it could get
[06:43] <lifeless> brm
[06:44] <jml> never really made my life any better when I used it
[07:04]  * mwhudson EODifies
[07:05] <mwhudson> jml: want to review this branch chock full of fun tomorrow?
[07:05] <mwhudson> it's here for now bzr+ssh://bazaar.launchpad.net/~mwhudson/launchpad/ec2-entrypoints
[07:08] <jml> mwhudson, yes.
[07:08] <jml> mwhudson, I might even review it today...
[07:09] <mwhudson> jml: it needs docstrings, i know that much
[07:14] <jml> heh heh
[07:15] <mwhudson> oh and copyright headers and __all__ and so on
[07:20] <jml> *nod*
[07:22] <wgrant> jml: What are you fighting with Soyuz about this time?
[07:26] <jml> wgrant, permissions, still.
[07:26] <jml> wgrant, but I think I've won this battle
[07:33] <maxb> jml: what was your feel on my py2.5-unittest-compatibility? You did "review approve" but not "merge approve"
[07:35] <jml> maxb, I review approved.
[07:35] <jml> maxb, but I confess I forgot that you can't land branches yourself :)
[07:35] <jml> maxb, so I was expecting you to change the comment or not at your discretion and then land it :)
[07:36]  * maxb reminds jml that self-landing is not an option :-)
[07:36] <jml> maxb, do you want to tweak the comment? if yes, please do so and poke me. if not, I'll land your patch now.
[07:37] <lifeless> maxb: what is the thing you find odd?
[07:37] <lifeless> maxb: or rather what makes it odd to you?
[07:37] <maxb> that it should redo logic that its base class's __init__ does too
[07:38] <maxb> ok, one edited comment coming right up
[07:38] <jml> maxb, heh, thanks :)
[07:38] <maxb> I'd lost track of whether the "peculiarly" was in the BMP or the code itself
[07:39] <lifeless> urgggle, unitteset._CmpToKey
[07:39] <lifeless> that really should be in e.g. list.something
[07:40] <jml> I'm doing too many tasks at once. Please give me a moment while I serialize a few of them.
[07:40] <maxb> jml: "chooses to write to it .... as part of its own method of arranging for pre-2.5 compatibility" ?
[07:41] <jml> maxb, perfect.
[07:41] <lifeless> I must admit to curiousity about why the property is needed
[07:42] <lifeless> I'm guessing something is being naughty
[07:43] <maxb> pushed, many thanks for the attention during this branch's bumpy path to this point
[07:43] <jml> maxb, np. I'll land that now.
[07:46] <mwhudson> good grief, ec2 demo works
[07:46] <jml> zomg.
[07:47] <poolie> jml https://bugs.edge.launchpad.net/launchpad/+bug/430504
[07:47] <poolie> (no action needed)
[07:47] <mwhudson> (which probably isn't true on trunk btw)
[07:48] <jml> mwhudson, has your headless improving branch landed on stable yet?
[07:49] <mwhudson> jml: dunno about stable, it's in devel though
[07:50] <jml> mwhudson, ok. I'll run from there, see how things work out. :)
[07:52] <maxb> what's ec2 demo? make run, in an ec2 instance?
[07:54] <wgrant> Yep.
[07:54] <wgrant> Woah. ec2test is split.
[07:55] <jml> heck yes
[07:55] <jml> mwhudson has skills.
[07:56] <jml> also, ec2test --headless takes much less time. hurrah.
[07:57] <jml> maxb, your branch is submitted. you'll get an email when the test run finishes.
[07:57] <wgrant> "# Perl allows for inplace editing unlike sed."
[07:57] <wgrant> sed -i?
[07:58]  * jml shrugs
[07:58] <maxb> thanks
[07:58] <maxb> bye
[07:58] <jml> maxb, bye.
[07:58] <jml> wgrant, you wouldn't happen to be rewriting it in Python, would you?
[07:59] <wgrant> jml: Can't really do that without a public AMI!
[07:59] <wgrant> And no.
[08:00] <jml> oh. pity.
[08:24] <adeuring> good morning
[08:53] <jml> adeuring, hello
[08:53] <adeuring> hi jml!
[09:26] <mrevell> Guten morgen
[09:31] <jml> g'night all :)
[09:54] <wgrant> bigjools: Available for a few ddeb-related questions?
[09:55] <bigjools> wgrant: yes, ask away, but I am pretty busy and have a call in 5m so I'll do what I can
[09:56] <wgrant> bigjools: Great, thanks.
[09:56] <wgrant> bigjools: process-death-row currently crashes on copy/debug archives, because they lack an archive_url.
[09:56] <wgrant> I guess it's important for debug archives, but not copy archives as they're not published.
[09:56] <wgrant> Should I define an archive_url for debug archives?
[09:57] <bigjools> wgrant: yes, sounds sane
[09:58] <bigjools> wgrant: https://bugs.edge.launchpad.net/soyuz/+bug/244145
[09:58] <mup> Bug #244145: process-death-row script chokes on rebuild archives <derivation> <Soyuz:Triaged by al-maisan> <https://launchpad.net/bugs/244145>
[09:58] <wgrant> bigjools: Ah!
[10:00] <wgrant> bigjools: Second one: ddebs really want to follow their debs around very closely. I plan to adjust the ftpmaster-tools and various internal methods to search for binaries owned by a source inside the debug archive as well, and possibly add some extra magic to change-override and lp-remove-package to drag the ddebs along when their debs are operated upon directly.
[10:01] <wgrant> Sounds sane?
[10:01] <wgrant> Third: Copies are going to get pretty broken and confusing after this. Argh.
[10:03] <bigjools> wgrant: gimme a few mins, I have a call
[10:03] <wgrant> bigjools: Sure.
[10:04] <wgrant> I wonder whether forcing the archive in newSourcePublication is enough, or if it should be done at a higher level...
[10:04] <wgrant> Time to write lots of tests, I guess!
[10:37] <bigjools_> wgrant: it would be good if you could send email to -dev to enumerate all the places you need to fix for ddebs in the separate archive, then we can have a think about it, it's a somewhat scary change
[10:41] <wgrant> bigjools: I shall prepare an email -- I hadn't thought about this aspect of it until yesterday.
[10:42] <bigjools> wgrant: great, thanks
[10:58] <deryck> Morning.
[11:07] <bigjools> beuno, deryck: https://bugs.edge.launchpad.net/malone/+bug/430593
[11:07] <mup> Bug #430593: New milestone listing page's bug tags are easily confused with the description <Launchpad Bugs:New> <https://launchpad.net/bugs/430593>
[11:10] <deryck> bigjools, yeah, that is confusing.
[11:13] <bigjools> deryck: right-floating them would help, but ideally a separate column on the same line
[11:14] <deryck> bigjools, ok.
[11:15] <bigjools> deryck: and if you can fix bug 262545 at the same time that'd be *great* :)
[11:15] <mup> Bug #262545: Milestone listings should show the bugs' titles/descriptions in a tool tip <milestone-management> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/262545>
[11:15] <deryck> heh
[11:15] <wgrant> Bonus points for reducing the query count (OOPS-1355EB146)
[11:16] <bigjools> :)
[11:16] <bigjools> oh wgrant, what's the issue with package copies and ddebs again?
[11:17] <wgrant> bigjools: I guess delayed copies should be fine, but a direct copy with binaries between distroseries or to a PPA is going to require Magic to both pick up the right binaries, and put them in the right place.
[11:18] <bigjools> wgrant: right
[11:24] <bigjools> wgrant: reminder: you have until next wednesday to give me your top three 4.0 wishes
[11:24] <wgrant> bigjools: I'd remembered that, but have so far received zero responses on the mailing list. I will send a reminder.
[11:25] <bigjools> ok :/
[11:25] <wgrant> Something like that.
[11:25] <bigjools> if I don't get anything, then I'll proceed with what *we* think is important, which may not be the same as what you guys think
[11:25] <wgrant> Of course.
[11:27] <bigjools> ta very much
[11:27] <wgrant> I'll hopefully be able to give you something, but I can't unless others give me something.
[11:31] <bigjools> if you don't hear anything, your opinion would still be better than nothing
[11:31] <wgrant> Possibly.
[12:20] <BjornT> can someone with a recent SUCCESS mail from a ec2test run tell me how many tests were run?
[12:29] <simon-o> Hi, I tried to send an email to<EMAIL_ADDRESS>but got an error message. Is this a known error?
[12:30] <barry> simon-o: what error did you get?
[12:31] <simon-o> barry: http://paste.ubuntu.com/272035/
[12:32] <simon-o> If I try to connect to lists.launchpad.net on port 25, I get a "Connection refused"
[12:32] <barry> simon-o: yep, i just tried the same thing and got the same error
[12:32] <barry> simon-o: thanks for letting us know.  i'll ping our admins
[12:33] <simon-o> barry: thanks
[12:34] <danilos> bigjools, I see you commented on the last buildbot failure: do you know what that might be about?
[12:36] <bigjools> danilos: the usual out of disk space
[12:36] <bigjools> no idea why, our buildbot expert needs to take a lookl
[12:36] <danilos> bigjools, heh, ok, figured that much out myself... ok, thanks
[12:36] <danilos> bigjools, would it be worth retrying the build?
[12:37] <bigjools> danilos: that one was the result of re-trying... but no harm in doing it again
[12:40] <barry> simon-o: try it now.  mta on that box was just restarted and i can telnet to it okay
[12:42] <simon-o> barry: telnet works fine and the email got through. thanks
[12:48] <barry> simon-o: cool
[13:37] <danilos> gmb, intellectronica: is there a known problem with bug description editing ("Entity body is not a well formed JSON object")?
[13:37] <jtv> It's failing on staging as well.
[13:37] <gmb> Urrr...
[13:37] <gmb> Not one that I'm familiar with.
[13:37]  * gmb looks
[13:37] <danilos> gmb, I think I've seen this yesterday as well, but attributed it to my epiphany-webkit usage... having tried again today with firefox, it's really not working for me
[13:38] <jtv> Hmm... I tried editing another bug on staging and replacing the description with just "x".  That worked.
[13:38] <wgrant> There's a bug for that.
[13:38] <jtv> (At least I hope I did that on staging ;)
[13:38] <danilos> gmb, perhaps intellectronica added something like if user.inTeam(rosetta_admins): no fancy ajax editing for you
[13:38] <danilos> wgrant, ah, ok, I thought I'd ask first
[13:38] <gmb> Heh.
[13:38] <wgrant> Bug #424625
[13:38] <mup> Bug #424625: use native python for manipulating images <Photo Frame Prep:New> <https://launchpad.net/bugs/424625>
[13:38] <wgrant> Not that one.
[13:39] <wgrant> Bug #424645
[13:39] <mup> Bug #424645: Entity-body was not a well-formed JSON document. <Launchpad itself:Confirmed> <https://launchpad.net/bugs/424645>
[13:39] <gmb> wgrant: Ah, thanks.
[13:39] <danilos> wgrant, thanks
[13:39] <danilos> and it's "Confirmed"... we don't use "confirmed" :)
[13:40] <gmb> danilos, jtv: Can't reproduce it on staging or edge atm, but I believe you :)
[13:40] <jtv> weirdly enough, on staging, I can enter the same text in a different bug.
[13:40] <jtv> A-hah!
[13:41] <danilos> gmb, reassiging the bug to malone, fwiw, you guys can take it from there
[13:41] <jtv> I was adding it to another bug.  If I put it at the top, it seems to break.
[13:41] <gmb> danilos: Righto.
[13:44] <danilos> allenap, the base branch is devel, you can look at the diff for now, but I'll take a look at what's going on there
[13:44] <allenap> danilo-afk: Don't do anything! It was my fault.
[13:45] <danilos> allenap, ok, and sorry about the wrong channel (though, we might be making kfogel happy :)
[13:45] <allenap> danilo-afk: I pulled devel this morning, but it was on a different machine.
[13:45] <danilos> allenap, heh, multiple machines are bad for your health
[13:46] <allenap> danilos: Yes, I've not heard that one before, but I'll take your word for it :)
[13:46] <intellectronica> danilos: that's a known problem. i think deryck might know a bit more about this
[13:46] <danilos> intellectronica, cool, thanks
[13:47] <intellectronica> danilos: and no, i have no objection for clerks from other departments using ajax, as long as they fill in the correct forms (in three copies)
[13:48] <deryck> intellectronica, danilos -- yeah, entity body bug is known.  I thought the bug was triaged for this cycle.  But the one I was just subscribed to isn't.
[13:48]  * deryck looks
[13:49] <deryck> bug 423924 is the one that will be fixed.
[13:49] <mup> Bug #423924: Entity-body was not a well-formed JSON document when updating bug description <Launchpad Bugs:Triaged by deryck> <https://launchpad.net/bugs/423924>
[13:50] <deryck> and geez, it's wednesday, I need to hunker down on some bugs.
[13:50] <deryck> barry, ping
[13:53] <barry> deryck: pong
[14:14]  * gmb -> out for a while; back later
[14:20] <bac> hi sinzui -- i'm looking for templates.  the page shows 8 outstanding.  any taken?  any suggestions?
[14:21] <sinzui> bac: yes. We have a dependency issue with these last templates
[14:21] <barry> bac: i will be looking for more templates to convert too
[14:23] <sinzui> bac: barry: lets discuss how to land these during our call. Lots of things breack when person +edit changes
[14:23] <bac> sinzui: ok
[14:23] <barry> sinzui: +1
[14:26] <BjornT> barry: ping?
[14:26] <barry> BjornT: pong
[14:26] <BjornT> barry: why does AppServerLayer start an smtp server?
[14:27] <barry> BjornT: originally it was because the mailman integration tests need to talk to a real smtp server.  it's possible we could move that into the MailmanLayer now though (i'm not sure what, if anything else not in that layer depends on it)
[14:33] <BjornT> barry: hmm. registry/tests/test_mlists.py seems to use the smtp server. could it use MailmanLayer, instead of AppServerLayer? or do you have any suggestion of an easy way of not hard coding the smtp port number?
[14:37] <barry> BjornT: i don't think we want to move that to MailmanLayer.  One problem with that layer is that it doesn't run by default and we have an open bug on running it in a cron
[14:38] <barry> i'll have to think about the port hardcoding; it was difficult last time so i punted ;)
[14:40] <barry> gary_poster: we suck again ;/  let's just admit we won't get to this until after 3.0
[14:40] <mrevell> gary_poster: ping
[14:40] <barry> gary_poster: and by "we" i probably mean "me" ;)
[14:44] <gary_poster> barry: are you talking about the reviewer bits?
[14:44] <gary_poster> mrevell: pong (sorry was on call)
[14:44] <barry> gary_poster: yep
[14:48] <henninge> barry: has the heading situation changed, again?
[14:48] <henninge> barry: on normal pages, I provide a 'label' that is placed as an H1 *above* the breadcrumbs, right?
[14:48] <kfogel> danilos: you made me happy :-)
[14:49] <barry> henninge: not for 2 days now afaik :)
[14:50] <barry> henninge: you need a label on your view yes, but it maybe be an h1 or an h2
[14:50] <barry> henninge: depending on whether your view implements IMajorHeading or not
[14:50] <barry> henninge: and it should only implement that marker interface if your page is the +index page of the root context
[14:51] <henninge> barry: yes, but I am not talking about the latter
[14:51] <henninge> barry: does this look correct? http://people.canonical.com/~henninge/screenshots/pofile-details.png
[14:52] <henninge> barry: or this http://people.canonical.com/~henninge/screenshots/pofile-translate.png
[14:52] <barry> henninge: yep, that looks right
[14:52] <barry> henninge: second one looks right too
[14:52] <henninge> barry: all I do is provide a 'label', nothing else.
[14:52] <henninge> barry: cool, thanks
[14:52] <barry> henninge: right.  for most pages, the default just DTRT
[14:52] <barry> well, default + 'label'
[14:52] <flacoste> Registry has 8 templates left!
[14:53] <flacoste> wow, this was a marathon!
[15:03] <BjornT> barry, flacoste: does this patch look sane? http://pastebin.ubuntu.com/272138/
[15:04] <barry> reviewers -> #launchpad-meeting
[15:07] <flacoste> BjornT: if it actually solves the problem, r=me!
[15:07] <flacoste> looks sane to me anyway
[15:08] <BjornT> flacoste: thanks, it does solve the problem! well, i'll try to run the mailman tests, to make sure it didn't break anything
[15:09] <barry> beuno: do you want to join us over in #launchpad-meeting?
[15:19] <jml> maxb, you around?
[15:48] <allenap> intellectronica: On https://bugs.launchpad.net/ubuntu/+source/debhelper/+bug/427356 (and almost certainly every other bug index), lp.picker and lazr.activator get run multiple times. By that I mean that the message "loading lp.picker" (and "loading lazr.activator") are logged many times.
[15:48] <mup> Bug #427356: Boot Performance Updates <acpid (Ubuntu):Fix Released> <anacron (Ubuntu):Fix Released> <apport (Ubuntu):Fix Released> <at (Ubuntu):Fix Released> <avahi (Ubuntu):Fix Released> <cron (Ubuntu):Fix Released> <cryptsetup (Ubuntu):Fix Released> <cups (Ubuntu):Confirmed> <dbus (Ubuntu):Fix Released> <debhelper (Ubuntu):Fix Released> <gdm (Ubuntu):Fix Released> <hal (Ubuntu):Fix Released> <hostname (Ubuntu):Fix Released> <ifupdown (Ubuntu)
[15:52] <allenap> intellectronica: I've tried to figure out why, but can't, unless YUI().use(..., 'lp.picker',...) is not using the already loaded version.
[15:53] <allenap> intellectronica: Ah, YUI().use(...) creates a new Y, so I guess it must run each module again. That would explain things. Seems a shame to do this so many times in a page load though.
[15:53] <maxb> jml: for a few minutes
[15:55] <intellectronica> allenap: that's not a problem, other the annoying logging
[15:56] <intellectronica> allenap: there are multiple pickers because there are multiple rows
[15:57] <allenap> intellectronica: Yes. The thing is that the lp.picker library code is being run ~20 times. If we did all the initialisation of the bugtask rows in a single YUI().use() block, then it would only be run once.
[15:58] <intellectronica> allenap: i'm not sure i understand. the module is only loaded once (yui takes care of that). the widget is being initialized 20 times if there are 20 widgets (two for each bugtask). i don't see any way around that, nor do i think this is a problem. am i missing something?
[15:59] <henninge> Since when did test_suite become obsolete in unit tests? Does anybody know anything about this?
[15:59] <henninge> Are tests added automagically now?
[15:59] <allenap> intellectronica: I think YUI is running the lp.picker module ~20 times, rather than just once, because the "loading lp.picker" message is within the Y.add() in lp/picker.js.
[16:00] <allenap> intellectronica: And lazr.activator is being run ~20 times too because it's required by lp.picker.
[16:01] <intellectronica> allenap: oh wow, you're right. that is truly bizarre!
[16:01] <bac> sinzui: call?
[16:02] <intellectronica> allenap: i would have expected yui to only load the module once. that's the whole point, innit?
[16:03] <BjornT> flacoste: call?
[16:03] <allenap> intellectronica: Yeah. The file is cached by the browser at least. I think, to create the Y that's passed into the function(Y) {...}, it has to run each of the modules mentioned in the use(...) call.
[16:04] <sinzui> bac yes
[16:05] <intellectronica> allenap: it doesn't make any sense to me. sounds like a bug. if you have to run all modules each time yui use() them, then it means that you should have as few uses as you can. but that means that it really doesn't make sense to do it the way we do, where we isolate every call
[16:05] <allenap> intellectronica: Put another way: YUI().use('mod', 'another_mod', function(Y) {...}) creates an empty Y object then runs mod and another_mod in that namespace.
[16:05] <flacoste> BjornT: yes
[16:06] <intellectronica> allenap: more annoyingly, to get around that, we'll need to somehow pass all row data in one go. that's doable, but we can no longer rely on the template to do that
[16:06] <allenap> intellectronica: Yeah, agreed. I don't think it's a bug, but perhaps the amount we use it is excessive.
[16:06] <sidnei> intellectronica: it is possible to cache the global YUI object, by doing 'Y = YUI().use()....' and then pass 'Y' into your function
[16:07] <intellectronica> sidnei: aha! that's a nice solution
[16:07] <intellectronica> allenap: i think that's definitely worth doing on the bug page, since there are so many call sites
[16:08] <allenap> intellectronica: The other way of doing this is to put the row data in a hidden <span class="row-data">{...json...}</span>, then the setup can run once, find these and use them.
[16:09] <intellectronica> allenap: that's a pretty nasty workaround. if we have to do that we might as well generate it all in the view, no?
[16:10] <intellectronica> i mean the top-leve view, not the row view
[16:10] <allenap> intellectronica: Yeah, you're right. Probably easier to test too.
[16:10] <intellectronica> sidnei, allenap: you should totally write about that to the rhinos ml. i had no idea, and this is likely to become an issue as we add more ajax to pages
[16:11] <sidnei> intellectronica: good idea
[16:12] <allenap> sidnei: You or me then?
[16:12] <sidnei> allenap: you? :)
[16:12] <allenap> sidnei: Okay :) I might do it tomorrow, but sure.
[16:12] <intellectronica> my appreciation of YUI3 just dropped significantly (though of course it was based on completely bogus premises)
[17:00] <deryck> intellectronica, allenap -- admittedly I'm only scanning scrollback just now, but I wonder if this is better in the beta release, i.e. that modules are more smartly re-used?
[17:01] <deryck> I'm talking about the YUI discussion
[17:02] <intellectronica> deryck: no idea. i also thought that this is a feature yui3 provides, and so i'm inclined to believe that this is improved in future versions, but maybe i simply expect too much from yui
[17:02] <allenap> deryck: It might be. I'll write to the list; maybe someone there will either know or find out. However, owing to how the Y objects are created, I doubt there's a ton that can be done.
[17:03] <allenap> deryck: Well, not really how they're created, but the fact that a new one has to be built for each invocation of YUI().use().
[17:05] <deryck> intellectronica, allenap -- ok, thanks for chasing this down.
[17:06] <allenap> deryck, intellectronica: By the way, although this stuff is slowing down the bug page, I don't think it's what's causing bug 430288, unless there's a very indirect cause and effect.
[17:06] <mup> Bug #430288: Major page load time regression in 3.0-dev for many-bugtask bugs <Launchpad Bugs:Triaged by allenap> <https://launchpad.net/bugs/430288>
[17:07] <deryck> allenap, but your comments on the bug do indicate where you think the troubles might lie?
[17:08] <intellectronica> allenap: also, if by 'load times' what is meant is really 'initialization time' it's worth changing the bug summary. i thought it's about the time it takes to render the page and send back the response
[17:08] <allenap> deryck: Yes.
[17:08] <deryck> allenap, cool
[17:09] <deryck> I think of load time as the whole process -- server response through browser render.
[17:09] <deryck> but maybe that is just me
[17:09] <allenap> intellectronica: Good point. I've updated the description and title.
[17:10] <intellectronica> nah, maybe i'm just not used to thinking about it because that wasn't traditionally a problem on LP (while rendering the page has)
[17:10] <allenap> deryck: Me too, but in this case it's probably worth being specific because the server time is roughly the same between lpnet and edge.
[17:11] <deryck> yeah, definitely agree we should be more specific.  Was more just thinking out loud about the phrase "load time"
[17:14] <intellectronica> i think we can conclude that if you can think out loud of the phrase "load time" and the page still hasn't loaded then we've got a problem :)
[17:16] <bigjools> how do I get an email with a diff in it from the MP page?
[17:18] <bigjools> abentley? ^^
[17:19] <abentley> bigjools: There isn't a way.  See bug #307461.  However, you should have received it from your launchpad-reviews subscription.
[17:19] <mup> Bug #307461: Provide a way to start doing a review by email from web page. <code-review> <confusing-ui> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/307461>
[17:20] <bigjools> abentley: ah forgot about that, thanks
[17:57] <mrevell> night all, back on later
[18:03] <kees> I have an API search that seems to be hanging forever
[18:03] <kees> the UI works fine:
[18:03] <kees> https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=Signal%3A+11&orderby=datecreated&search=Search&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.component-empty-marker=1&field.status_upstream-empty-marker=1&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.has_cve.used=&field.tag=apport-crash&field.tags_combinator=ANY&field.has_no_package.used=
[18:03] <kees>     tasks = lp.distributions['ubuntu'].searchTasks(tags='apport-crash', order_by='-datecreated', omit_duplicates=True, search_text="Signal: 11")
[18:03] <kees> but the API never returns
[18:05] <kees> (or rather, it seems to be loading them ALL before returning....)
[18:05] <kees> strace shows activity
[18:09] <kees> is there something that can be done about this, or a way to report back progress?
[18:37] <rockstar> barry, do you know if it's safe to upgrade karmic packages yet?
[18:39] <barry> rockstar: i haven't upgraded today.  i got lucky yesterday though; upgrading before the fubar
[18:39] <barry> rockstar: you feeling brave? :)  i probably won't attempt it until after i finish the next branch i'm working on
[18:40] <rockstar> barry, well, I'm getting weirdness, so I almost did it before I remembered what maxb said yesterday.  I'm just going to ignore it and try my best to get my work done.
[18:41] <barry> rockstar: i'm pretty sure maxb said it was safe to upgrade late last night
[18:41] <maxb> Yesterday's fubar was past by around 0200 UTC IIRC
[18:41] <barry> maxb: thanks!
[18:41] <maxb> I'm not ruling out *new* weirdness, though :-)
[18:42] <barry> :)
[18:42] <rockstar> maxb, can you get identical hardware to me and test before I upgrade in the future?  kthxbai
[18:42] <rockstar> :)
[18:54] <maxb> jml: PQM sulked, I take it? :-)
[18:58] <rockstar> maxb, jml is .au - so he is probably sleeping right now.
[18:59] <maxb> ah, ok. I've just got a second ec2test success email for a branch, so I'm assuming the first submission to PQM vanished somehow
[19:00] <maxb> On that topic, how long is normal from ec2test submitting to PQM, to it actually landing?
[19:10] <maxb> Should someone remind Florian Effenberger on launchpad-dev@ about the image licensing terms?
[19:16] <intellectronica> maxb: depends what machine size you're using, but i believe it's somewhere around 4h these days
[19:16] <maxb> no, I mean from when ec2test completes and hands off to PQM
[19:16] <intellectronica> maxb: oh, maybe i didn't read the question right. once ec2 submits to pqm it's only about 5 minutes, unless there's stuff in the queue before that
[19:17] <maxb> I guess the queue's busy today
[19:17] <intellectronica> maxb: the queue itself is variable. some branches need a test suite run, others don't (and only take about 5 minutes)
[19:18] <intellectronica> maxb: there are two branches in front of yours in pqm. neither need a test suite run, so you can expect yours to land soon
[19:18] <maxb> revisions seem to be going into devel at about 20 minute intervals right now
[19:23] <dhillon-v10> deryck: hi how are you
[19:24] <deryck> dhillon-v10, hi, on call :)  Sorry
[19:24] <dhillon-v10> finally got a hold of you :)
[19:25] <deryck> dhillon-v10, were we supposed to chat today?
[19:25] <dhillon-v10> i have some time do you?
[19:25] <dhillon-v10> if not then we can talk later
[19:25] <deryck> dhillon-v10, on call right now
[19:25] <deryck> dhillon-v10, let me email you later
[19:25] <dhillon-v10> oh, sorry
[19:25] <deryck> np
[19:49] <flacoste> gary_poster: that's what i get when running python bootstrap.py in lazr.restful: http://pastebin.ubuntu.com/272305/
[19:49] <flacoste> any idea?
[19:49] <flacoste> http://pastebin.ubuntu.com/272306/
[19:49] <flacoste> and that's what i get if I try python2.5 bootstrap.py
[19:50] <gary_poster> flacoste: not off hand no
[19:50] <gary_poster> have not seen that
[19:50] <gary_poster> flacoste: karmic?
[19:51] <flacoste> gary_poster: no, Jaunty
[19:53] <gary_poster> flacoste: ...python2.4 bootstrap.py works fine on karmic for me.
[19:54] <flacoste> gary_poster: still fails here
[19:54] <flacoste> python2.4 gives the same error than python2.5
[19:55] <flacoste> python-setuptools isn't installed
[19:55] <flacoste> but was in the past
[19:55] <flacoste> i'll install again and try agian
[19:56] <flacoste> gary_poster: with python-setuptools installed, python2.5 works
[19:56] <gary_poster> flacoste: setuptools is not installed for me
[19:56] <flacoste> but you are on karmic on a new install
[19:56] <gary_poster> flacoste: it may be that installing and uninstalling leaves something unpleasant around.  would you like me to try that?
[19:57] <gary_poster> i.e., do you want me to investigate?
[19:57] <flacoste> gary_poster: nah, i'm moving on
[19:57] <gary_poster> ok
[19:57] <flacoste> if it happens again, i'll investigate
[19:57] <flacoste> gary_poster: lazr.youpkg still has
[19:57] <flacoste> sys.path.insert(0, 'src')
[19:57] <flacoste> from lazr.yourpkg import __version__
[19:57] <flacoste> in it, is that correct?
[19:59] <gary_poster> probably.  we've fixed everything else
[19:59] <flacoste> gary_poster: ok, i thought we didn't want to do this import try from setup.py anymore
[19:59] <flacoste> but since you've fixed buildout
[19:59] <flacoste> maybe we don't care anymore
[20:00] <gary_poster> well, ubuntu still doesn't like it
[20:00] <gary_poster> so it is worth changing
[20:00] <gary_poster> I'll get to it
[20:01] <flacoste> gary_poster: what's the new thing to do? use a static version in setup.py?
[20:01] <flacoste> and no __version__?
[20:02] <gary_poster> see how it is done in lazr.restful: version.txt in package, setup.py loads the value into __version__ by reading the file, and __init__.py uses pkg_resources
[20:02] <gary_poster> to load it into __version__
[20:03] <gary_poster> flacoste: actually, note that the __init__.py still has some old cruft: the try:except is no longer necessary
[20:05] <flacoste> ok, thanks
[20:31] <barry> sinzui: ping
[20:33] <gary_poster> salgado: ping
[20:34] <salgado> hi gary_poster
[20:35] <gary_poster> salgado: hi :-) .  I need to convert the logintoken pages to the new templates.  I'm trying to figure out how to duplicate that locally so I can get a visual "before and after" check to make sure I have converted everything OK.  Do you have an idea on how I might do that?
[20:38] <kees> how do I turn off caching in python-launchpadlib ?
[20:39] <salgado> gary_poster, I think the fastest way would be to create logintokens of all different kinds inside a 'make harness' session and for each of them load 'https://launchpad.dev/token/<token>' for each of them before and after you convert.  does that answer your question?
[20:41] <gary_poster> salgado: I think so, yes, thanks!  I'll do what I see at the beginning of logintoken-pages.txt
[20:42] <barry> rockstar: ping
[20:42] <barry> intellectronica: ping
[20:42] <barry> EdwinGrubbs: ping
[20:43] <rockstar> barry, hi
[20:43] <salgado> gary_poster, np
[20:43] <EdwinGrubbs> barry: pong
[20:43] <barry> rockstar, EdwinGrubbs : hi.  can you do a quick ui review for a somewhat redesigned ~/person/+editemails page?
[20:44] <EdwinGrubbs> barry: do you have screenshots?
[20:44] <barry> EdwinGrubbs: yes: http://people.canonical.com/~barry/editemails.png
[20:44] <rockstar> barry, if you have screenshots, I can do it now, otherwise it'll have to be a bit.
[20:44] <barry> rockstar: ^^
[20:45] <barry> EdwinGrubbs, rockstar it's not perfect.  i wish i could put that Add button next to the input field, but that page is kind of a hack and it's not feasible given timeboxing
[20:46] <barry> EdwinGrubbs, rockstar still, i think it's better and i get to close an old bug 180349 as a bonus
[20:46] <mup> Bug #180349: mailing list subscriptions page should link to team <mailing-lists> <Launchpad Registry:In Progress by barry> <https://launchpad.net/bugs/180349>
[20:46] <intellectronica> hi barry
[20:46] <salgado> gary_poster, btw, I have a question for you.  we have some tests that generate a request and append objects into request.traversed_objects, but having the tests define that is far from ideal so I'm wondering if it'd be possible to pass just the URL into the request and feed it to the publisher so that traversed_objects gets updated appropriately.  is that possible?
[20:46] <barry> intellectronica: hi. sorry to bother you.  was looking for a ui review, but rockstar and EdwinGrubbs ponged me first ;)
[20:47] <thekorn> kees, I'm turning off the cache at runtime for one of my scripts, let me try to find how I'm doing it
[20:47] <intellectronica> barry: you are always welcome to bother me if someone else picks up the work eventually ;)
[20:48] <thekorn> kees, wow, it is as simple as    launchpad._browser._connection.cache = None
[20:48] <barry> intellectronica: :)
[20:48] <EdwinGrubbs> barry: it seems like the displayname of the team should also be linkified. Actually, shouldn't you use the tales fmt:link which will give it a nice icon?
[20:49] <barry> EdwinGrubbs: good point.  i'll see if i can fix that
[20:49] <EdwinGrubbs> barry: ui=me
[20:49] <barry> EdwinGrubbs: thanks
[20:49] <gary_poster> salgado: ...yes, that should probably be doable, though I haven't tried it.  I would first try a test request and then do what zope.publisher.publish.publish does (get the publication, process inputs, and so on through maybe the "afterTraversal" call.  You might need to get your own publication...
[20:50] <salgado> gary_poster, ok, I'll give that a try
[20:50] <gary_poster> cool
[20:52] <kees> thekorn: okay, thanks
[20:53] <barry> EdwinGrubbs, rockstar http://people.canonical.com/~barry/editemails2.png
[20:54] <EdwinGrubbs> barry: looking good, Mr. Carter
[20:54] <barry> EdwinGrubbs: :)  thanks!  rockstar?
[20:55] <rockstar> barry, I agree that the add button should be next to the input field, but that's a problem with FormView, not you.  r=me
[20:55] <barry> rockstar: thanks man
[21:03] <sinzui> barry: I think  "but that page is kind of a hack". Is an understatement. The page is a hack We need to reinvent it for 4.0
[21:05] <barry> sinzui: yeah ;)
[21:07] <sinzui> barry, have you really solved bug 180349
[21:07] <mup> Bug #180349: mailing list subscriptions page should link to team <mailing-lists> <Launchpad Registry:In Progress by barry> <https://launchpad.net/bugs/180349>
[21:07] <barry> sinzui: did you see the screenshot?
[21:07] <sinzui> I am
[21:08] <sinzui> barry: how did you get the label linked?
[21:08] <barry> sinzui: i hacked the view to give me the team and the widget, disabling the widget.label.  then i render the team/fmt:link in one column and the widget in the second column
[21:09] <sinzui> interesting. I will have to study this
[21:10] <barry> sinzui: for some reason, it was a lot easier to manage this time around.  it mean it kind of surprised me.
[21:11] <sinzui> I think the work with the license widget taught you all the options.
[21:14] <mwhudson> morning
[21:36] <thumper> salgado: has your page_title fix landed?
[21:36] <salgado> thumper, no
[21:36] <thumper> salgado: ETA?
[21:37] <thumper> salgado: I'm wanting to work on the breadcrumbs for branches
[21:37] <thumper> salgado: but I don't want all the "correct" stuff
[21:37] <thumper> oops
[21:37] <thumper> I want the "correct" stuff to start with
[21:37] <thumper> rather than land stuff, then be told it is wrong or overridden with something else
[21:39] <salgado> thumper, the only thing that will be overridden is the text of the last breadcrumb when you're on a page which is not the default one for that context
[21:39] <salgado> we're currently using the page's name (as defined in the zcml) and after my fix lands we'll use the page's title (either view.page_title or the entry in pagetitles.py)
[21:40] <sinzui> salgado: I do not think it should support pagetitles since we want to remove that file in 10 days
[21:42] <salgado> sinzui, we're removing that file and moving all the titles there as view attributes or what?
[21:43] <sinzui> salgado: We want to remove the module. No 3.0 page should use it. We will know on day 1 of week 0 if someone cheated
[21:43] <thumper> sinzui: +1 on not falling back to pagetitles.py
[21:44] <sinzui> salgado: I don't think you need to change your code, but i would delete a test for that feature rather than fix it
[21:44] <salgado> sinzui, that's just not practical.  have you seen how many pages still take their titles from pagetitles.py?
[21:45] <sinzui> salgado: yes. Sometime people do this right thing when threated with violence
[21:45] <mwhudson> wow, markup flamewar on launchpad-dev!
[21:45] <sinzui> salgado: I think a lot of developers have not cleaned out the pagetitle that is not being used
[21:46] <sinzui> mwhudson: this is just a prelude for when we build wikis for user. Most probably know mediawiki, not moin
[21:46] <gary_poster> salgado: most of these token pages use context/@@main_template/master .  The conversion guidelines suggest main_side or main_only for these, but locationless seems more appropriate.  Do you agree?
[21:47]  * sinzui thinks investment in a gui editor will alleviate the need to fight the markup war
[21:48] <salgado> gary_poster, yes, they should be locationless
[21:48] <gary_poster> salgado: cool thank you
[21:49] <maxb> What is the purpose of the ~launchpad-hackers team?
[22:01] <kfogel> gary_poster: hey, I've got matsubara's branch that ports lp-bug-ifier to launchpadlib.  Do you do anything history-preserving when you port stuff from lp-dev-utils to launchpadlib/contrib/, or do you just copy the script?  If the latter, maybe I can save you some time?
[22:02] <kfogel> maxb: some hysterical raisins, and I can't remember exactly what now...
[22:02] <gary_poster> kfogel: just copy.  yeah, thanks, I won't get to that today, and I have some other things ahead of that for tomorrow too, though I might get to it then.
[22:03] <kfogel> gary_poster: launchpadlib is not PQM-governed anyway, right?  I.e., if I can just push this in myself, I will; otherwise, I'll make a branch of launchpadlib and leave it for you.
[22:04] <gary_poster> kfogel: it is not governed by pqm.  I found out recently that the desired way to handle these is to "co" the branch, merge in the changes from your branch, and commit the merge with the appropriate "[r=foo] bar" message
[22:06] <kfogel> gary_poster: hmmm.  doing "bzr branch launchpadlib foo; cd foo; cp .../lp-bug-ifier.py .; bzr add lp-bug-ifier.py; bzr ci -m '[r=notsureyet] bar'; bzr push lp:launchpadlib"    is not the way?
[22:07] <gary_poster> kfogel: no
[22:07] <kfogel> gary_poster: I confess I'm surprised they would even have different effects; what's worse, I remember having this exact discussion (perhaps with you?) last week, and yet I still am expecting those two have the same effect.
[22:09] <kfogel> gary_poster: anyway, diogo is the one who ported it, and you're the one I'm discussing this with.  Should I put "[r=gary]" ?
[22:11] <kimus> should I file a bug for the statistics module see: https://lists.launchpad.net/launchpad-users/msg05474.html or it's ok in ML only?
[22:11] <kfogel> kimus: reading
[22:12] <gary_poster> kfogel: not with me.  you are probably right that it would have the same effect--to bzr.  It does not have a review in there--unless you are the reviewer, which is quite possibly your intent (effectively you are reviewing Diogo's work).
[22:12] <gary_poster> If you wanted someone else to be the reviewer you would need to push your branch publicly first to have it reviewed, and then the process I described would be the right way.
[22:12] <kfogel> kimus: yes, please, and feel free to include as many specific examples of useful stats in the bug as you can think of.
[22:13] <kfogel> kimus: if the bug could contain a link to the archive URL above, that'd be great; that way we can get from the bug to the thread.
[22:13] <kimus> sure kfogel
[22:13] <kfogel> gary_poster: well, I think I'm not officially a reviewer, so [r=kfogel] is probably never formally correct, though in this case I did review his change of course.
[22:14] <kimus> kfogel: what model? launchpad it self?
[22:14] <kfogel> gary_poster: or when you said "does not have a review in there" did you mean "does not have to have a review in there" ?
[22:14] <kfogel> kimus: yes
[22:15] <gary_poster> kfogel: no I meant "does not have a review step in there."  In this case, I'd just use yourself as a reviewer, under the circumstances.  Not letting you be a reviewer for this feels...wrong.
[22:15] <kfogel> heh
[22:15] <kfogel> gary_poster: not all changes in the launchpadlib logs have a reviewer at all.  Is the r= even necessary?    Or, well, we didn't know the desired result.  This commit message should be a "[r=kfogel] (merged for matsubara) add another internal file newly ported to launchpadlib" or something like that, AIUI.
[22:18] <kfogel> gary_poster: I'll JFDI.  If it's a mistake, this is the way to find out.  Thanks!
[22:18] <gary_poster> kfogel: well, we don't have automation here.  the way to find out that you did something is wrong is for a colleague to inform you of that...
[22:19] <kimus> kfogel: done: https://bugs.launchpad.net/launchpad/+bug/431011
[22:19] <mup> Bug #431011: Launchpad statistics <statistics> <Launchpad itself:New> <https://launchpad.net/bugs/431011>
[22:20] <kfogel> gary_poster: that's what I meant
[22:20] <kfogel> kimus: thank you
[22:21] <gary_poster> kfogel: ok.   what I meant was, I was trying to inform you before a mistake was made :-)  but if we're on the same page then cool, all in favor of jfdi
[22:21] <kfogel> kimus: I changed the summary to be more accurate
[22:21] <kfogel> gary_poster: AH, gotcha
[22:21] <kimus> kfogel: fine :-)
[22:21] <kfogel> gary_poster: I just tested his script -- it works perfectly.  Review enough for me!
[22:21] <gary_poster> kfogel: +1
[22:22] <mwhudson> thumper: ready now
[22:23]  * rockstar is ready too
[22:24] <thumper> rockstar: skype doesn't think so
[22:24] <mwhudson> rockstar: you didn't pick up ?
[22:24] <rockstar> mwhudson, thumper, skype sucks?
[22:25] <mwhudson> rockstar: yes
[22:25] <mwhudson> my skype doesn't think you're online, but we know what that's worth
[22:25] <thumper> rockstar: you still aren't picking up :)
[22:25] <rockstar> thumper, call now, sound sorted.
[22:55] <bac> hi mwhudson -- i just launched an ec2test --headless and it took 66 minutes to get it running and let go.  has something changed...for the worse?
[22:55] <mwhudson> bac: !!!
[22:56] <rockstar> bac, I definitely didn't see that just not when I launched 2 ec2tests
[22:56] <jml> hello
[22:56] <mwhudson> bac: that's terrible, did you notice which steps were taking the time?
[22:56] <bac> mwhudson: i've got another coming up that i'll double check
[22:56] <rockstar> ...and I pulled pretty recently.
[22:56] <mwhudson> bac: also what machine version did it say you were using?
[22:56] <bac> mwhudson: didn't specify a machine.  i thought the default was changed to be XL
[22:57] <mwhudson> bac: i meant "Using machine image version %d\n'"
[22:57] <kfogel> jml: hi
[22:57] <mwhudson> bac: it's one of the first things the script prints
[22:57]  * bac scrolls bac
[22:57] <bac> er, back
[22:58] <jml> heh heh
[22:58] <jml> kfogel, hello :)
[22:58] <jml> kfogel, want to join skype?
[22:58] <bac> mwhudson: this it?  Using machine image version 16
[22:59] <bac> mwhudson: i don't see anything that identifies the machine.
[22:59] <mwhudson> bac: yes, that's what it should say
[22:59] <kfogel> jml: yup, getting the headphones now
[22:59] <jml> kfogel, cheers.
[23:00] <bac> i wish the output had timestamps
[23:00] <kfogel> jml: skype just dumped core
[23:00] <kfogel> jml: no kidding
[23:00] <jml> kfogel, :(
[23:00] <kfogel> jml: yup, did it again
[23:00] <kfogel> jml: let me see if there's an update real quick
[23:01] <jml> kfogel, ok
[23:02] <mwhudson> bac: yeah, i'd like that too
[23:03] <kfogel> jml:  on
[23:04] <mrevell> Good ol' Skype just died on me
[23:04] <jml> mrevell, :(
[23:04] <kfogel> mrevell: I had to upgrade at skype.com
[23:05] <mrevell> jml: I'm back.
[23:05] <mrevell> kfogel: seems ok now
[23:06] <kfogel> jml: did you drop?
[23:06] <kfogel> jml: I think we should set this up via canonical conf calling...
[23:06] <kfogel> do you have a code?
[23:07] <jml> kfogel, no I don't.
[23:07] <mrevell> I'm getting crazy amounts of static
[23:07] <mrevell> I *lurve* Skype
[23:07] <kfogel> jml: we could hijack kiko's, maybe
[23:08] <kfogel> jml: (action item: get you a code)
[23:08] <jml> kfogel, heh
[23:08] <kfogel> jml: (not a joke!)
[23:08] <thumper> kfogel: you have several outstanding approved branches
[23:08] <thumper> kfogel: are you going to land them?
[23:08] <kfogel> thumper: I do?
[23:08] <jml> kfogel, you were dumping a bunch of noise onto the line
[23:08] <kfogel> thumper: I wonder what they are; I didn't know I had anything outstanding.
[23:08] <kfogel> thumper: will look after this call
[23:08] <kfogel> jml: uh
[23:08] <thumper> kfogel: check out the approved section in https://code.edge.launchpad.net/launchpad/+activereviews
[23:08] <kfogel> thumper: thx
[23:09] <kfogel> jml, mrevell: um.  let's hijack kiko's code, and then jml can get a code of his own later.  thoughts?
[23:09] <jml> kfogel, ok, sure.
[23:09] <kfogel> jml: okay, I'll dial in.  If I'm first, I'll set it up.
[23:09] <jml> kfogel, privmsg details please
[23:10] <kfogel> jml: will do, one sec
[23:28] <barry> jml, thumper, mwhudson, rockstar wanna meet today?
[23:28] <mwhudson> barry: guess so
[23:28] <thumper> barry: yes
[23:28] <barry> -> #launchpad-meeting in 2m
[23:29] <thumper> rockstar: lets have a call after the reviewer meeting
[23:29] <rockstar> thumper, I'll probably have to walk the dog, but after that, sure.
[23:30] <thumper> rockstar: ok
[23:30]  * rockstar is assuming reviewer meeting is now.
[23:54]  * thumper really hates pagetests
[23:57] <wgrant> 3.0 is a week away now, isn't it?
[23:58] <mwhudson> wgrant: that's the plan i think
[23:59] <wgrant> Eek.
[23:59] <mwhudson> i guess a delay is possible...
[23:59] <wgrant> It's still all very unpolished, there is a big unresolved root context issue, and there is no UI designer.