[00:06] <wgrant> lifeless: Hmm.
[00:07] <wgrant> lifeless: Why 'timeline.timeline' instead of 'timeline'?
[00:08] <wgrant> I have to say that I really question the utility of a 155 line diff to deduplicate a single line of code.
[00:10] <wgrant> The python-oops-wsgi diff could be argued to be sensible. But I don't think python-timeline's is.
[00:11] <lifeless> wgrant: PEP 3333
[00:11] <lifeless> wgrant: environ variables are namespaced
[00:11] <wgrant> But even python-oops-wsgi's diff is probably better handled by passing a dict of stuff to preserve from the environment.
[00:12] <lifeless> so, which package do you think should define the location of the timeline in a wsgi stack ?
[00:13] <lifeless> An implied aspect is that we should export a symbolic variable with the value 'timeline.timeline'
[00:13] <wgrant> Does it need to be fixed?
[00:15] <wgrant> What's going to use it?
[00:21] <lifeless> wgrant: storm and other things that want to log events in a wsgi world
[00:21] <lifeless> wgrant: e.g. https://code.launchpad.net/~lifeless/storm/wsgi/+merge/76009
[00:22] <wgrant> Erm
[00:22] <wgrant> We have DNS breakage.
[00:22] <wgrant> LibrarianServerError: <urlopen error [Errno -2] Name or service not known><br />
[00:22] <lifeless> wgrant: note that this knows nothing about oopses
[00:22] <wgrant> Just got an OOPS for that page.
[00:23] <lifeless> -win-
[00:23] <lifeless> (sarcasm)
[00:23] <wgrant> And I forget to grab the OOPS ID.
[00:23]  * wgrant greps.
[00:24] <lifeless> was that a librarian fail or a find-librarian fail ?
[00:24] <wgrant> I think find-librarian,.
[00:24] <wgrant> Two OOPS so far today with that error, both from soybean.
[00:25] <lifeless> I've asked in is
[00:26] <lifeless> there was a dns reload
[00:27] <wgrant> Ah
[00:28] <lifeless> anyhow
[00:28] <lifeless> back to our regularly scheduled program
[00:28] <lifeless> its about loose coupling
[00:28] <lifeless> connecting storm to timeline in a wsgi environment is one step
[00:29] <lifeless> connecting timeline to oopses in a wsgi environment is another
[00:29] <wgrant> Just got another one.
[00:29] <lifeless> thus a change to storm, to timeline, and to oops-wsgi
[00:29] <wgrant> AQ4
[00:29] <wgrant> Are they still reloading DNS?
[00:43] <lifeless> james_w: I'm trying to use testr_recipe, but it says 'installing test.. cannot find distribution for test' (where test is the part in the buildout.cfg
[00:48] <lifeless> wgrant: ok, now where were we.
[00:56] <wgrant> lifeless: Having storm.wsgi.make_app be time-line specific seems odd.
[00:59] <wgrant> I'm all for factoring out common code sensibly, but I really don't think the python-oops-wsgi and python-timeline changes are examples of that. They save three lines of code, all of which are trivial and two of which could be reduced to one with a more generic python-oops-wsgi solution.
[01:01] <lifeless> wgrant: you'll need to spell out what you mean, because I don't see it
[01:01] <wgrant> lifeless: Which bit?
[01:01] <lifeless> more generic python-oops-wsgi solution.
[01:02] <wgrant> The oops_wsgi change would probably be better as a general facility to specify values from the environ to put in the context.
[01:02] <lifeless> I can do that
[01:02] <wgrant> eg. pass in a {'timeline.timeline': 'timeline'} dict or so.
[01:02] <lifeless> I don't see it eliminating the needed for the other changes
[01:03] <lifeless> I'd also like to have it do that particular one by default, as a sane-default
[01:03] <wgrant> So, to tie the bits together I need to import a module and have a special-case in oops_wsgi, or I can specify a tiny dict and construct a timeline myself.
[01:03] <wgrant> Which takes roughly 1.5 lines.
[01:04] <lifeless> I am rather allergic to copy and paste of undifferentiated code
[01:04] <lifeless> when there is really local policy, its fine. This isn't one of those times
[01:04] <wgrant> This code is actually going to be shorter.
[01:04] <wgrant> The other one just happens to be entirely symbols.
[01:05] <lifeless> per PEP3333
[01:05] <lifeless> the timeline module is what gets to use timeline.*
[01:06] <lifeless> if we call it oops.timeline or oops.context['timeline'] then oops-wsgi could set it
[01:06] <lifeless> if we call it storm.timeline, storm could set it
[01:06] <lifeless> anything else is asking for trouble, and all those other names are (hopefully obviously) undesirable
[01:09] <wgrant> I don't think any of those need to set it.
[01:09] <wgrant> The only glue code that is useful here is the stuff in storm.wsgi.
[01:12] <lifeless> which would be totally the wrong place to create the timeline object
[01:13] <lifeless> as its used for more than just storm lookups
[01:13] <wgrant> Sure, I don't think you should create it there.
[01:13] <wgrant> I think the app should do it.
[01:13] <wgrant> Pass the name into Storm.
[01:13] <wgrant> And ask oops-wsgi to map it into the report.
[01:13] <lifeless> that would force configuration onto everything that wants to talk to a timeline
[01:13] <lifeless> I think thats undesirable
[01:14] <wgrant> That's possibly true.
[01:14] <lifeless> I'm happy to make oops-wsgi more configurable
[01:14] <lifeless> but it would be a mistake to do that and then say 'now everyone has to use that'
[01:14] <wgrant> But we also have a 155 line diff to add one line (41 characters) of very trivial.
[01:15] <wgrant> very trivial code.
[01:15] <lifeless> shrug
[01:15] <wgrant> I think *that* is probably undesirable.
[01:15] <lifeless> the major cost - writing and testing it - is sunk
[01:16] <wgrant> This smells, and I don't have enough WSGI experience to say if it is sane. I'm afraid I can't sensibly approve this myself.
[01:18] <wgrant> This is an interface that other projects are going to use, so I am going to be more cautious than I would be for an internal LP interface.
[01:27] <lifeless> sure
[01:27] <lifeless> this is what jamesh and I agreed on
[01:27] <lifeless> I don't agree that it smells
[01:28] <lifeless> separate but related
[01:28] <lifeless> oops-tools has code to infer request duration
[01:29] <lifeless> by examining the last item in a timeline
[01:29] <lifeless> I think it might be sane for Timeline() to have a 0 duration initial action
[01:29] <lifeless> to seed things
[01:29] <lifeless> but Timeline can't tell when its finished with, so it needs to be told [exact details for doing this could vary]
[01:30] <lifeless> man, really want yield from
[01:31] <wgrant> That didn't make it into 3.2, did it?
[01:31] <lifeless> I don't think so
[01:31] <wgrant> :(
[01:31] <lifeless> it would make some of these wsgi wrappers better and faster
[01:31] <wgrant> Indeed, accepted for 3.3.
[01:32] <lifeless> such as the next change to the timeline one which I'm about to self review
[01:43] <lifeless> wgrant: other than the structural thing which you've abstained on
[01:43] <lifeless> wgrant: were there code quality comments; I have one noted from the discussion - why doesn't oops-wsgi let the map be done arbitrarily
[01:44] <lifeless> wgrant: which I will execute on as I'm in the area
[01:46] <wgrant> lifeless: It all looks fine, apart from the workaround for lack of 'yield from', which I believe is pretty standard anyway.
[01:46] <lifeless> yah
[01:47] <lifeless> thanks
[01:47] <lifeless> do you want to see the generalisation before I land (I plan to supply a default mapping dict which folk can use as a template, and a mapping param which None means 'use the default dict'
[01:48] <wgrant> That sounds fine. I'm about to wander out for a few hours, so won't be around much.
[01:48] <wgrant> Anyone want to review https://code.launchpad.net/~wgrant/launchpad/no-config-names-in-store-names/+merge/76135? Simple code changes, potentially non-simple consequences, but the test suite is fine with it.
[01:50] <lifeless> what about the impact on session query filtering ?
[01:50] <wgrant> The store name there is just 'session'
[01:50] <wgrant> Always has been.
[01:50] <wgrant> I don't think it even uses LaunchpadDatabase.
[01:51] <wgrant> Yeah, see PGSessionBase in canonical.launchpad.webapp.pgsession
[01:51] <lifeless> ok
[01:53] <wgrant> Thanks.
[01:59] <jtv> nigelb: noticed that too… no idea; frankly I don't know why other MPs don't get empty diffs once they're merged.
[02:03] <jtv> wgrant: looks like gina's done with sid.
[02:03] <jtv> Syncing logs to see what happened to squeeze.
[02:04] <jtv> Oh come on oneiric, please don't do this… I need to shut down _somehow_ so I can carry this laptop to the office.
[02:04] <wgrant> sudo pm-suspend ftw
[02:05] <lifeless> jtv: sudo pkill e*
[02:05] <lifeless> ?
[02:05] <jtv> lifeless: why e*?
[02:06] <lifeless> erlang, can't remember the process name
[02:06] <lifeless> has been known to cause 'issues'
[02:06] <wgrant> beam.smp? :)
[02:06] <lifeless> yeah :P
[02:06] <lifeless> there are two though
[02:06] <lifeless> beam and a broken
[02:06] <wgrant> epmd?
[02:06] <lifeless> broker
[02:06] <lifeless> yes
[02:06] <wgrant> Yay, I remember erlang crap properly.
[02:07] <jtv> In my case: can't move mouse pointer, and can't log into text console because it keeps typing /////////////
[02:07] <jtv> (Actually my GUI session has been doing that as well, but _there_ at least it stopped)
[02:08] <jtv> And since suspend/hibernate don't work, I need to shut down.  But since the shutdown option doesn't work, what I normally do is log out and then switch to a text console to shut down.
[02:08] <jtv> I think I'll take a bug-filing day this week.
[02:09] <jtv> Well, the pkill didn't work.  :(
[02:15] <jtv> Why is epmd running as rabbitmq even after I stopped rabbitmq?
[02:16] <jtv> And why was it still there after the pkill?
[02:16] <jtv> I killed it by pid, but no change.  :(
[02:16] <lifeless> anything in dmesg?
[02:17] <jtv> A lot of screensaver segfaults
[02:17] <jtv> Complaints about the CD that's in my drive, I think.
[02:17] <jtv> forcedeth, which sounds like a cover band.
[02:18] <jtv> Complaints about unknown SCO packets on hci0.
[02:19] <jtv> Sorry no, about SCO packages for an unknown connection handle.
[02:19] <jtv> “apm: BIOS not found” is probably not as exciting as it sounds.
[02:20] <StevenK> You're on a MacBook which uses EFI
[02:20] <jtv> Not as exciting as it sounds.
[02:21] <jtv> I'll try the pm-suspend then I guess.
[04:09] <lifeless> win 19978  OOPS-2088HWDB303  None
[04:38] <StevenK> wallyworld_: *prod*
[04:38] <wallyworld_> StevenK: hello
[04:38] <StevenK> wallyworld_: var co = Y.one('.yui3-overlay.yui3-lp-app-confirmationoverlay');
[04:38] <StevenK> That still results in co being null
[04:38] <wallyworld_> no work?
[04:39] <wallyworld_> maybe try removing one of the css class selectors
[04:39] <wallyworld_> just to see what happens
[04:40] <StevenK> Can I see all CSS classes at that point int time?
[04:40] <wallyworld_> yes, node.getClass()
[04:41] <wallyworld_> but i thought you looked using firebug
[04:41] <wallyworld_> to see what the classes were
[04:41] <StevenK> I meant in the test itself
[04:42] <wallyworld_> oh, ok, yes that will give you the classes
[04:43] <wallyworld_> once you have the node
[04:43] <wallyworld_> wgrant: wrt the conversation about only removing subscribers for bugs associated with projects with private_bugs=true - it is acceptable to simply look at the default_bugtask to get the project (if any) whose 'private_bugs' may be true/false?
[04:44] <StevenK> wallyworld_: Yes, but I'm having trouble getting the node!
[04:45] <wallyworld_> StevenK: yes. so you probably are best to loosen the selection constraint on css class
[04:45] <wallyworld_> to try and get a node that matches
[04:45] <wallyworld_> you can also use Y.all() and iterate over the node list
[04:46] <wallyworld_> so if you make the constraint .yui3-overlay you can see what overlays there are
[04:46] <StevenK> Y.all('.yui3-overlay'); ?
[04:46] <wallyworld_> yes, i think so
[04:46] <wallyworld_> so long as yui3-overlay is correct in terms of a css class that they have
[04:48] <mwhudson> I couldn't get Y.one('.class-one.class-two') to work the other day
[04:48] <mwhudson> could it be some kind of bug?
[04:48] <wallyworld_> mwhudson: perhaps. i think we are running a rc version of yui 3.4. maybe time to look at upgrading
[04:48] <StevenK> That was silly
[04:49] <StevenK> alert(i) gives me an alert box for each attribute of the node
[04:49] <mwhudson> doh
[04:49] <wallyworld_> StevenK: no i lie. we are running 3.3
[04:49] <wallyworld_> but 3.4 is now out i think
[04:50] <wallyworld_> StevenK: Y.log is your friend
[04:50] <StevenK> AH
[04:50]  * mwhudson asks in #yui, though i expect everyone is asleep
[04:50] <StevenK> Y.all('.yiu3-overlay') has a _nodes property that is [ ]
[04:51] <wallyworld_> StevenK: that implies there are no matching nodes
[04:51] <wallyworld_> since Y.all returns a NodeList afaik
[04:51] <mwhudson> StevenK: don't look behind the curtain
[04:51] <StevenK> Clearly
[04:51] <mwhudson> StevenK: .size() == 0 is a better check :)
[04:52] <mwhudson> (and as for gratuitous differences between Array and NodeList...)
[04:53] <StevenK> Ah ha
[04:53] <StevenK> That function never gets called with "unsubscribe"
[04:53] <StevenK> wallyworld_: Does Y.log() hit stdout/stderr when running under bin/test?
[04:54] <StevenK> mwhudson: My JS knowledge is ... heavily fragmented and mostly missing.
[04:54] <wallyworld_> StevenK: not sure but doubt it. it goes to the console in the browser when you run the test via loading the html page
[04:54] <wallyworld_> i find that the best way to debug
[04:54] <mwhudson> StevenK: mine is heavily fractured but i'm gradually filling in the gaps :)
[04:54] <wallyworld_> since i can also use break points, watches etc etc
[04:58] <StevenK> wallyworld_: Running it via the browser it keeps complaining that "Y.lp.app.confirmationoverlay" is undefined.
[04:58] <wallyworld_> StevenK: that explains a lot
[04:58] <wallyworld_> StevenK: you need to include the module in the html harness
[04:59] <StevenK> Oh, at the bottom of the test js?
[04:59] <wallyworld_> sort of near where the other imports are done nearish the top i thin
[04:59] <wallyworld_> thinkl
[04:59] <StevenK> Oh, in the HTML itself
[04:59] <wallyworld_> yes
[04:59] <wallyworld_> see the <!-- Come required dependencies -->
[05:00] <wallyworld_> comment
[05:00] <wallyworld_> Some, not Come
[05:00] <wallyworld_> can't type
[05:00] <StevenK> Which doesn't appear in that HTML
[05:01] <wallyworld_> StevenK: bin/test tends to hide a lot of errors and just reports failure for whatever reason
[05:01] <wallyworld_> see test_personpicker.html for an example
[05:01] <wallyworld_> bin/test is good for once stuff is debugged and working
[05:02] <wallyworld_> but to see setup errors etc, use the browser and firebug
[05:05] <StevenK> Expected: null (object)
[05:05] <StevenK> Actual: DIV#yui_3_3_0_2_13164951130961890 yui_3_3_0_2_13164951130961894 (object)
[05:05] <StevenK> SUCCESS
[05:05] <wallyworld_> StevenK: excellent!
[05:06] <wallyworld_> StevenK: now you can try the "proper" css class selector
[05:06] <StevenK> That is with the proper CSS class selector
[05:06] <wallyworld_> even better
[05:06] <StevenK> var co = Y.one('.yui3-overlay.yui3-lp-app-confirmationoverlay');
[05:06] <wallyworld_> at least now you know you test fails and you can write the code to fix it
[05:06] <StevenK> Does that strike you as 'proper' ?
[05:07] <wallyworld_> well, so long as it is specific enough to select the confirmation overlay you are trying to get at
[05:07] <wallyworld_> and not find any others
[05:07] <StevenK> wallyworld_: I'm now un-breaking the JS itself to only show the overlay on private bugs
[05:07] <wallyworld_> sounds good
[05:08] <StevenK> And then if the test passes, I can start writing my own
[05:10] <wallyworld_> yep
[05:11]  * wallyworld_ has to go and pick up car from getting new tyres fitted
[05:11] <StevenK> >1 day for 3 lines of JS and 2 lines of HTML
[05:11] <StevenK>  /wrists
[05:11] <wallyworld_> StevenK: at least you know how to do it quicker now :-)
[05:11] <wallyworld_> all the things to look out for
[05:12] <wallyworld_> StevenK: what doesn't kill you makes you stronger :-)
[05:34] <nigelb> Except those that make you want to die.
[05:34] <nigelb> ;)
[05:35] <nigelb> Why does the MP have "Empty diff" ocassionally?
[05:35] <nigelb> I saw it for one of MPs and the other day with one of jtv's MPs.
[06:09] <StevenK> Can I grab hold of a button in JS by using Y.one() ?
[06:10] <huwshimi> StevenK: Does the button have an ID?
[06:10] <StevenK> It does not
[06:11] <StevenK> <button class="lazr-pos lazr-btn ok-btn" type="submit">OK</button>
[06:11] <StevenK> It has a surrounding div (<div class="yui3-lazr-formoverlay-actions">), which I guess I can grab with var div = Y.one('.yui3-lazr-formoverlay-actions');
[06:31] <wallyworld_> StevenK: you can grab a button using attribute matching also eg "button.ok-btn[type='submit']" or something like that
[08:02] <adeuring> good morning
[08:05] <nigelb> Good Morning adeuring & mrevell
[08:05] <mrevell> yo
[08:16] <wgrant> stub: Hmm, so it turns out that all but two of the storm_cache and storm_cache_size directives in the configs are unused.
[08:18] <stub> wgrant: Just the appserver overriding?
[08:19] <stub> wgrant: We currently have a huge value for the appserver because it hasn't been instrumented and are scared of reducing the size.
[08:20] <stub> wgrant: And are scared of using high values in scripts to stop memory ballooning.
[08:20] <wgrant> stub: Well, that's what I thought, but it's a little bit simpler than that.
[08:21] <stub> Its busted and only works in rare cases?
[08:21] <wgrant> The 'launchpad' section is used for everything, except for the librarian (which uses 'librarian').
[08:21] <stub> \o/
[08:21] <wgrant> launchpad is 10000 on production, 100 on dev.
[08:22] <wgrant> Someone somewhere along the line stopped calling setConfigSection in production code, except for the 'launchpad' default in lib/canonical/config/__init__.py, and one other case in librarian.tac.
[08:22] <wgrant> librarian seems to really only care about overriding the dbuser and isolation_level.
[08:22] <wgrant> Which, conveniently, is what everybody else cares about overriding too.
[08:23] <stub> Do we currently have any script memory hogs?
[08:23] <wgrant> Apart from nasty gina and process-death-row worstcases recently, not really.
[08:24] <wgrant> That I know of.
[08:24] <stub> dbuser and isolation_level should really be hardcoded anyway, isolation because things break if you change the config and dbuser because we never make use of the fact we can change the config.
[08:24] <wgrant> Yeah, apart from in tests.
[08:24] <wgrant> ... and formerly in buildd-manager, but that was fixed a year ago.
[08:25] <wgrant> So, I'm probably removing config section support, merging launchpad's settings into the main database section, changing librarian.tac to override directly. And due to the fix I landed this morning, that means that dbconfig.override() is pretty much a direct replacement for initZopeless, and ZTM can finally BURN.;
[08:26] <wgrant> And this stuff that has been a shim for 4 years can finally die :/
[08:34] <wgrant> Uhoh.
[08:34] <wgrant> canonical.lp won't die.
[08:34] <wgrant> It somehow got revived today.
[08:34]  * wgrant blames jtv.
[08:34] <jtv> whuwhuwhu?
[08:34] <wgrant> message: [r=benji][no-qa] Fix lots of lint in recently-changed files.
[08:34] <wgrant> added: lib/canonical/lp/
[08:34] <wgrant> :(
[08:34]  * wgrant remurders.
[08:34] <jtv> Please do.
[08:42] <wgrant> Bah.
[08:42] <wgrant> Looks like I need to keep respecting config.launchpad.dbuser, as it's what all the appserver configs use.
[08:44] <poolie> jtv, i think you mean "symptom, search internet, selfdiagnosis, treatment, conspiracy theories"
[08:45] <jtv> poolie: I am _not_ taking you to any more coffee shops.
[08:45] <poolie> haha :)
[08:46] <bigjools> lifeless: how's the python-oops-twisted thingamujig?
[09:09] <lifeless> bigjools: good news and bad news
[09:09] <lifeless> bigjools: the good news is I figured out what all the tech debt meant
[09:09] <lifeless> bigjools: the bad news is that the new project isn't done yet, because of the good news
[09:09] <lifeless> bigjools: pretty close though, just tests to write now
[09:12] <bigjools> lifeless: well, thanks, you've saved me a bunch of work so it's all good AFAIAC: )
[09:26] <poolie> jelmer, hey that's a really interesting point about the code ui
[09:28] <jelmer> poolie: thanks; I think it's one of those things that are hard to notice once you've gotten used to the existing UI.
[09:29] <poolie> yeah
[09:29] <poolie> i was actually talking to huw about this the other day
[09:29] <poolie> because we did a little on it at the o'rally and it's been idle since then
[09:29] <poolie> i would love to see it reactivate
[09:29] <jelmer> Once the last code-import<->mirror integration branch lands, I'd really like to kill the "Register a branch" button.
[09:29] <poolie> i think it's one of those topics that can hurt user experience a lot, but that won't clearly come up in bug reports or user requests
[09:30] <poolie> s//hurt or help
[09:30] <jelmer> yeah
[09:50] <lifeless> bigjools: turns out our current twisted integration can silently block the librarian etc
[09:50] <lifeless> bigjools: we're calling blocking apis without deferToThread
[09:50] <bigjools> lifeless: awesome
[09:50] <lifeless> I will be fixing one of the two cases
[09:50] <bigjools> what scenarios?
[09:50] <lifeless> oops creation writes files to disk
[09:51] <lifeless> and can trigger a re-read of the directory
[09:51] <lifeless> but the key bit is we thunk logObserver to python logging
[09:51] <lifeless> and thats documented in the twisted docs as 'can block'
[09:51] <lifeless> we should be doing deferToThread
[09:52] <lifeless> and then doing the may-block stuff in a thread
[09:52] <lifeless> this just became blindingly obvious when I started asking 'how to extract this nicely'
[09:52] <lifeless> for bonus points we have two distinct twisted integrations atm
[09:52] <stub> I normally don't mind the spider, but it should get off my damn screen!
[09:52] <lifeless> roughly equally used.
[09:53] <lifeless> I'm not going to try and fix that, but I'm going to bless one - the one I extract :)
[09:53] <bigjools> lifeless: well at least you spotted it
[09:54] <jml> lifeless: which is the blocking API being called?
[09:54] <stub> We need to append pending log messages to a list, and deferToThread something that logs them in the correct order.
[09:55] <jml> Logging a message doesn't normally need to be treated as a blocking operation.
[09:55] <lifeless> jml: PythonLoggingObserver
[09:56] <lifeless> jml: it does, and this is documented in the twisted docs as well as the logging docs.
[09:56] <jml> lifeless: where?
[09:56] <lifeless> jml: on the web page :) - sorry, past EOD and got stuff to do
[09:56] <jml> that's lame
[09:56] <jml> but I understand.
[09:56] <lifeless> the twisted.log api docs specifically
[09:57] <lifeless> wherever they are
[09:57] <stub> Oddities I foresee are log messages being spit out in the wrong order, timestamps being slightly off, and bound variables and stacks being mutated as the callsite proceeds and before the log message is generated.
[09:57] <jml> lifeless: thanks
[09:58] <lifeless> stub: failures already materialise the backtrace IIRC
[09:58] <jml> they do.
[09:58] <lifeless> stub: the rest are already happening because we're in a reactor environment
[09:58] <stub> cool. timestamps will be within precision.
[09:58] <stub> just thinking of why it is blocking in the first place :-)
[09:59] <lifeless> its blocking because the python 'logging' module has a great big lock in the middle
[09:59] <lifeless> (and because file IO and directory listing can block too)
[10:06] <jtv> bigjools: do we have any way to watch the debian domination on production?
[10:06] <bigjools> jtv: the log file?
[10:06] <jtv> I mean the effects of.
[10:07] <jtv> Seeing whether the resulting status of Debian makes sense.
[10:07] <bigjools> jtv: yeah, find a package that's dead in Debian but not in LP's import
[10:07] <bigjools> also see the count of packages in +missingpackages
[10:07] <jtv> Oh, we derive Ubuntu from Debian in production now?
[10:08] <bigjools> have done for a while!
[10:08] <bigjools> see oneiroc
[10:08] <bigjools> oneiric, even
[10:08] <bigjools> that's how this bug was noticed IIRC
[10:09] <jtv> Ooh nice little beta bar
[10:10] <jtv> Mind you, this is transitional domination so it shouldn't mark dead packages as deleted yet; it'll keep the last release alive for permanent domination to deal with.
[10:11] <jtv> Also, gina's still dealing with squeeze.  :/
[10:11] <bigjools> did it do sid yet?
[10:11] <jtv> No, don't think so.
[10:11] <bigjools> if not, take a note of the number of packages now
[10:11] <bigjools> compare after
[10:11] <jtv> Good one.  We also did that on dogfood.
[10:12] <jtv> Packages and statuses, I think.
[10:12]  * jtv cooks up some SQL
[10:21] <bigjools> jtv: you can just look at the package counts in the UI
[10:21] <jtv> The ones that need linking?
[10:22] <bigjools> [11:07:42] <bigjools> also see the count of packages in +missingpackages
[10:23] <jtv> That includes the DSD machinery as well… since I'm not expecting any package deletions, I'll want to watch the DB as well.
[11:07] <jtv> gmb: clearly, you're not bitter but just a tad disappointed in my review style?
[11:12] <gmb> jtv: No, I've just formed an emotional attachment to the branch because I've been working on it for a week and a half.
[11:12] <gmb> ]
[11:12] <gmb> It's been a royal pain in my backside.
[11:12] <gmb> jtv: One of your in depth reviews is always appreciated, unless the reviewee is feeling particularly lazy.
[11:12] <jtv> Says the self-proclaimed Lazy Reviewer.  :)
[11:13] <jtv> We ought to form a duo à la Laurel & Hardy.
[11:13] <gmb> :)
[11:13] <jtv> Hippie & Nazi, Reviewers™
[11:13] <gmb> Yeah, I can see that going down a storm :)
[11:16] <bigjools> lifeless: I need to do a txlongpoll test fixture - any opinion on whether that should be a separate project?
[11:17] <jtv> gmb: compared to what I got away with last week, it ain't so bad.
[11:18] <lifeless> bigjools: I'm torn
[11:19] <lifeless> bigjools: on the one hand it should clearly be reusable, so not part of LP
[11:19] <bigjools> lifeless: we could not decide either :) It'll add more dependencies of course
[11:20] <lifeless> on the other hand if its part of txlongpoll it ties the client language to the server implementation, and implies that a client that can use the fixture could get at the server innards - thats undesirable
[11:20] <lifeless> on the gripping hand adding a new project has some cognitive overhead
[11:22] <lifeless> I think we should try separate-project: we can always massively consolidate later
[11:23] <bigjools> I was erring that way
[11:25] <jtv> gmb: your change to initialize() puzzles me.  Why assign a variable you're not going to use?  Are you trying to force evaluation of a property?
[11:27] <gmb> jtv: Yes; activity_and_comments is a cachedproperty. If it's not loaded at initalize() time you end up with recursion problems in tests (not in actual usage though). I can drop the variable assignment; it just looked odd to me without it.
[11:30] <gmb> jtv: I'm going to go and grab some lunch; feel free to stick any questions in the MP and I'll reply on my return.
[11:31] <jtv> Aye-aye.
[11:38] <danilos> flacoste, lifeless: we can't triage bugs for launchpad-results (like https://bugs.launchpad.net/launchpad-results/+bug/854635), meaning that it's not really our duty, yet it's part of launchpad-project and we can't drive untriaged bugs count to zero: what shall we do about it?
[11:38] <_mup_> Bug #854635: unit model names have leading/trailing spaces <Launchpad Results:New> < https://launchpad.net/bugs/854635 >
[11:41] <danilos> bigjools, the following bug seems to be simple to fix (missing DB user), yet pretty critical: bug 854449. Do you think we should treat it as an incident and start working on it asap?
[11:41] <_mup_> Bug #854449: generate-contents-files.py failing on Ubuntu archive since September 11/12 <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/854449 >
[11:41] <bigjools> danilos: yes
[11:42] <bigjools> danilos: I suspect fallout from recent db user renamings
[11:42] <bigjools> danilos: also it needs a script monitor
[11:43] <danilos> bigjools, right, thanks, I'd appreciate it if you (as someone with more authority on the subject) adds a note to the bug itself, and I'll ensure we get started on it soon
[11:43] <danilos> soon == today
[11:44] <bigjools> ok :)
[11:45] <wgrant> danilos: It is a pretty trivial puppet task.
[11:45] <wgrant> An RT and a LOSA-poke may be in order.
[11:45] <danilos> wgrant, I can guess it is for someone who knows all about the script
[11:46] <wgrant> Hm? It's not got much to do with the script :)
[11:46] <danilos> wgrant, (eg. what DB user it should use)
[11:46] <wgrant> if __name__ == '__main__':
[11:46] <wgrant>     script = GenerateContentsFiles(
[11:46] <wgrant>         "generate-contents", dbuser='generate_contents_files')
[11:46] <wgrant> Problem solved :)
[11:47] <danilos> wgrant, I'd appreciate if you add that to the bug as well, since I am doing my CHR rotation right now
[11:49] <wgrant> Done.
[11:50] <danilos> thanks
[12:27] <wgrant> bigjools: You might recall that I removed txlongpoll a while back.
[12:27] <wgrant> bigjools: lifeless forbids its inclusion in our setup.py.
[12:27] <bigjools> FFS
[12:27] <wgrant> For it is to be a microservice.
[12:27] <bigjools> we need it for make run
[12:27] <bigjools> that is all
[12:28] <bigjools> I don;t know how else to set it up
[12:28] <stub> Is there an RT for Bug #854449  yet?
[12:28] <_mup_> Bug #854449: generate-contents-files.py failing on Ubuntu archive since September 11/12 <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/854449 >
[12:28] <wgrant> bigjools: Neither do I.
[12:28] <lifeless> danilos: -results is in a bit of limbo; we should either have it meet our governance rules or remove it from being part of 'launchpad-project'.
[12:29] <lifeless> danilos: chat to flacoste when he's up, and/or cr3 about which route
[12:29] <lifeless> danilos: cr3 wants to have it properly integrated as a microservice etc
[12:29] <lifeless> danilos: so, I think the right thing is getting it under our regular rules for bug supervisor etc
[12:29] <danilos> lifeless, right, thanks for updating me on it
[12:30] <lifeless> wgrant: bigjools: you use a buildout recipe
[12:30] <lifeless> wgrant: that gets it executable with a bin/txlongpoll entry point, but not importable
[12:30] <wgrant> This is going to get very ugly.
[12:30] <wgrant> But maybe.
[12:30] <lifeless> wgrant: bigjools: my use-gpgfixtures branch on lp has/had an example of doing that for the new keyserver.
[12:30] <lifeless> which flacoste gave me.
[12:30] <wgrant> We'll need a separate buildout target for each dep.
[12:31] <bigjools> lifeless: there is no bin/txlongpoll entry point
[12:31] <bigjools> it's a TAP
[12:32] <lifeless> so, you need the egg unpacked (buildout can do that), and you need a script (the fixture) that knows how to run the tap
[12:32] <lifeless> no ?
[12:32] <lifeless> just txlongpoll itself doesn't end up on our PYTHONPATH
[12:33] <bigjools> can you explain your aversion to setup.py changes?
[12:33] <wgrant> Ah, that's right. You'll need to use buildout to create a second twistd.
[12:33] <wgrant> That has the egg.
[12:33] <lifeless> I love setup.py changes
[12:33] <bigjools> in this context :)
[12:33] <lifeless> https://dev.launchpad.net/ArchitectureGuide/ServicesRequirements#Background_reasoning
[12:34] <bigjools> I'm not sure that answers the question
[12:34] <lifeless> thats the background reasoning
[12:35] <bigjools> I'm not really au fait with buildout so this is a learning exercise
[12:35] <lifeless> for why I want the microservices to not be importable
[12:35] <bigjools> happy to be guided on this
[12:36] <lifeless> wgrant: yes, buildout a z3c.recipe.script that has the additional egg, probably a defaults=... and tada
[12:36] <gmb> jtv: I hadn't noticed the conflicts with devel; have pushed a fix.
[12:37] <jtv> gmb: thanks.  I'm… collating notes.
[12:37] <gmb> ok
[12:37] <lifeless> bigjools: basically I want an ironclad avoidance of the sort of back-door dealing with API's we've had in LP with in-process stuff
[12:37] <bigjools> ok
[12:37] <lifeless> bigjools: so that folk can *confidently* work to the interface, not the implementation
[12:37] <lifeless> this has several corollaries:
[12:38] <bigjools> I'm still unsure what setup.py has to do with that
[12:38] <lifeless>  - there will be some form of split-outs that we can't do, because we don't know how to write an interface that is fast+ etc etc etc
[12:38] <bigjools> I perfectly understand the rationale, just not the "how" :)
[12:38] <lifeless> oh
[12:38] <lifeless> so when you add something to setup.py, buildout adds the resulting egg to the PYTHONPATH
[12:38] <lifeless> it does this transitively.
[12:38] <bigjools> and a simple buildout recipe does not?
[12:38] <lifeless> if you have setup.py reference package A
[12:39] <lifeless> and A references B
[12:39] <lifeless> B will be in the PYTHONPATH setup by bin/py
[12:39] <lifeless> bigjools: the 'scripts' recipe can specify its own additional things
[12:39] <bigjools> how are we going to make a fixture figure out how it can run the TAP then?
[12:40] <jtv> gmb: done.  Frankly it was the name of the branch that attracted my attention in the first place.
[12:40] <lifeless> bigjools: thinking
[12:40] <lifeless> bigjools: got it
[12:40] <lifeless> bigjools: the fixture needs to know the command line to run the thing
[12:40] <gmb> jtv: Heh, thanks.
[12:41] <bigjools> yes, but it also needs to know where the twistd binary and plugin lives to do that
[12:41] <lifeless> bigjools: this doesn't mean importing, it just needs to know that 'bin/twistd-longpoll' will run a twistd invocation that can import longpoll, and it needs the tap file
[12:41] <lifeless> bigjools: yes, this will mean buildout.cfg stuff (sorry to be handwavy, nearly 1am etc)
[12:42] <bigjools> ok, thoroughly confused here :)
[12:42] <lifeless> wgrant: are you less confused?
[12:42] <bigjools> maybe someone who knows buildout better can do this
[12:42] <gmb> jtv: Once again, your review has me saying "Wait, what?" I never knew about zip() (or knew and have forgotten). I shall go and learn about it forthwith.
[12:42] <jtv> gmb: good sport
[12:43] <lifeless> def sudo_make_me_a_fixture(twistd='bin/twistd-longpoll', tap='bin/longpoll.tap'):
[12:43] <lifeless>     return LongPollFixture(twistd=twistd, tap=tap)
[12:43] <lifeless> ^ thats the thunk code to inject the custom twistd script and tap location
[12:44] <lifeless> the other bit is teaching buildout to create the tap and twistd-longpoll
[12:44] <wgrant> bigjools: See txlongpoll's buildout.cfg.
[12:44] <wgrant> The 'interpreter' section there does sort of what we want.
[12:44] <wgrant> Except we probably want to use a script target directly, without an interpreter, if possible.
[12:45] <bigjools> lifeless: how would it know where bin lives in your example?
[12:45] <lifeless> bigjools: in LP it will always be bin/twistd-longpoll
[12:45] <bigjools> even if we have a script that encapsulates the invocation
[12:46] <bigjools> ah, so you want it in LP's bin
[12:46] <lifeless> thats what buildout is for
[12:46] <lifeless> its responsible for making that file
[12:47] <lifeless> this is what flacoste showed me: http://bazaar.launchpad.net/~lifeless/launchpad/usegpgfixtures/revision/13758
[12:47] <bigjools> twistd is not entirely flexible in how it looks for TAPs is it ...
[12:47] <lifeless> wgrant: ^
[12:47] <wgrant> bigjools: Not at all. So we'll need a second twistd that has basically just txlongpoll in its path.
[12:47] <bigjools> right, we have something in the txlongpoll buildout.cfg that builds itself
[12:48] <wgrant> Ahh, z3c.recipe.scripts, handy.
[12:48] <wgrant> Although that still generates an interpreter.
[12:48] <lifeless> wgrant: it didn't
[12:48] <lifeless> I don't know why the line is needed ;)
[12:50] <bigjools> what does that code put in bin/ ?
[12:50] <bigjools> s/code/config/
[12:51] <lifeless> it creates bin/gpgfixtures
[12:51] <lifeless> which has the buildout glue to set pythonpath etc
[12:51] <bigjools> not in my dev area it doesn't :)
[12:51] <lifeless> and ends up running gpgfixtures.keyserver.main(argv)
[12:51] <lifeless> bigjools: what do you mean ?
[12:52] <bigjools> there is no bin/gpgfixtures when I build latest trunk
[12:52] <lifeless> of course
[12:52] <lifeless> thats in a branch
[12:52] <bigjools> unlanded?
[12:52] <bigjools> ok
[12:52] <lifeless> its demonstrating what you need to achieve, for a different but similar case
[12:53] <bigjools> insomuch as I understand roughly what one of those lines is doing :)
[12:53] <lifeless> right
[12:53] <lifeless> this is why I pointed wgrant at it
[12:53] <lifeless> he has more overlap with you
[12:53] <lifeless> I'm dead :)
[12:53] <bigjools> FSVO overlap :)_
[12:53] <wgrant> Well, we actually both have zero overlap.
[12:53] <wgrant> But yes.
[12:54] <bigjools> yeah, you were up at crazy o'clock
[12:54] <bigjools> thanks for the advice so far lifeless, rest well
[12:54] <wgrant> Night lifeless.
[12:56] <bigjools> wgrant: ok so we might be able to get away with the one in txlongpoll, the only issue is what to do with the TAP directory abomination
[12:56] <wgrant> bigjools: What about it?
[12:56] <wgrant> That's all in the egg.
[12:57] <bigjools> wgrant: yes, but it needs to end up in $CWD
[12:57] <wgrant> Nope.
[12:57] <bigjools> otherwise twistd doesn't find it
[12:57] <wgrant> It's in twisted/plugins/blah
[12:57] <bigjools> is there a way of telling twistd where it is then?
[12:57] <wgrant> Just try that buildout rul.e
[12:57] <wgrant> Should work fine.l
[12:57] <wgrant> I can type, see.
[12:57] <bigjools> you miss my point I think
[12:57] <wgrant> twistd looks in twisted.plugins
[12:58] <wgrant> The plugin is in twisted.plugins in the egg.
[12:58] <bigjools> where "twisted" is in $CWD
[12:58] <wgrant> No.
[12:58] <bigjools> ah
[12:58] <wgrant> In pythonpath.
[12:58] <bigjools> ah
[12:58]  * bigjools experiments
[12:58] <wgrant> The egg is all set up. It works fine.
[12:58] <wgrant> If you add it to setup.py and rerun buildout, you'll see it listed when you run bin/twistd
[12:58] <wgrant> So we just need to make a *second* twistd, that only has txlongpoll.
[12:58] <bigjools> we do?
[12:59] <wgrant> Since our normal twistd uses the deps from setup.py
[12:59] <bigjools> ah right
[12:59] <wgrant> It's for running LP stuff.
[13:00] <bigjools> how do you rename the generated script name?
[13:00] <bigjools> ah never mind
[13:02] <deryck> Morning, everyone.
[13:02] <jtv> hi deryck
[13:02] <bigjools> morning deryck
[13:02] <bigjools> wgrant: know what's up here? "Error: Picked: Twisted = 11.0.0"
[13:03] <wgrant> bigjools: Possibly because you're using include_site_packages.
[13:03] <bigjools> ok let's try false
[13:03] <bigjools> nope
[13:03] <bigjools> I have no idea what that error even means
[13:04] <bigjools> I'd not know it was an error if it were not preceded with "Error" ...
[13:05] <bigjools> ah think I found it
[13:05] <bigjools> and no
[13:14] <deryck> abentley, adeuring -- can we standup at 20 after?  I have another call at the bottom of the hour today.
[13:15] <adeuring> deryck: sure
[13:15] <abentley> deryck: sure
[13:16] <deryck> great, thanks guys.
[13:35] <flacoste> bigjools: i'm hopping on call with deryck
[13:36] <flacoste> bigjools: but I could help you with that buildout after it, you could also grab gary_poster or benji to help out in the mean time
[13:37] <gary_poster> bigjools: you need to set versions.cfg to specify Twisted = 11.0.0
[13:39] <wgrant> jelmer: Did you intend to bump the bzr-git revision when you regenerated sourcedeps.cache?
[13:45] <jelmer> wgrant: argh, sorry. That should have been in the original commit.
[13:46] <wgrant> Ah, sure.
[13:47] <danilos> flacoste, hi, do you have any suggestions on what we should do with launchpad-results (it's part of launchpad-project, but we don't have privileges to triage bugs)? lifeless believes we should make it match lp-project standards for bug supervision
[13:54] <mrevell> Hey deryck or gary_poster, do you think you could spare someone to finish implementing Huw's 503 page? (https://code.launchpad.net/~huwshimi/launchpad/503-error-844631) Huw tells me he has taken it as far as he can.
[13:55]  * gary_poster looking, mrevell
[13:57] <gary_poster> mrevell, sure, I can put it in our (pretty short) backlog.  bonus points if you mark the bug escalated or critical :-P but not necessary
[14:01] <mrevell> Thanks gary_poster! We consider Launchpad to be a stakeholder, so perhaps I could escalate it. It's producing an OOPs, which we want to continue logging, but I suppose that makes it critical. I'll mark it critical and ask lifeless' forgiveness if need be :)
[14:01] <gary_poster> mrevell :-) ok cool
[14:03] <wgrant> mrevell, gary_poster: It's fastdowntime-related and an OOPS, so it can be critical. Doesn't need escalation :)
[14:03] <mrevell> superb
[14:03] <gary_poster> wgrant, cool :-)
[14:15] <bigjools> gary_poster: hello!
[14:15] <bigjools> my buildout saviour
[14:15] <gary_poster> hey bigjools
[14:15] <gary_poster> heh
[14:15] <bigjools> gary_poster: what I am doing is adding a script recipe to generate a "microservice"
[14:16] <bigjools> versions.cfg already has Twisted = 11.0.0
[14:16] <gary_poster> bigjools, script recipe from what
[14:16] <gary_poster> this is in Launchpad
[14:16] <gary_poster> 's setup.py I assume
[14:16] <bigjools> not in setup, I am taking the txlongpoll egg and writing some buildout config to try and make it generate me a script
[14:17] <bigjools> lifeless has banned changing setup.py for external scripts
[14:17] <bigjools> which is fair enough
[14:17] <gary_poster> bigjools, ok.  Oh, interesting.  (I don't think I'm breaking that in my current branch..._
[14:17] <gary_poster> )
[14:18] <gary_poster> bigjools, my memory is a bit fuzzy on all this, but I bet if I look at it I'll have an idea.  Do you have a branch for me?
[14:18] <bigjools> I'll paste you my change, one sec
[14:19] <bigjools> gary_poster: http://pastebin.ubuntu.com/693799/
[14:19] <bigjools> gary_poster: argh
[14:19] <bigjools> sorry hang on
[14:19] <bigjools> gary_poster: http://pastebin.ubuntu.com/693800/
[14:19] <bigjools> the first one is the whole file, that's just the diff
[14:19] <gary_poster> bigjools, An error with "Picked" is definitely complaining about "You didn't tell me which version to use, so I had to guess, and you told me to complain, so I'm complaining".  So the question is, why isn't versions.cfg good enough
[14:19] <gary_poster> ok
[14:20] <bigjools> gary_poster: oh I wonder if it doesn't like the txlongpoll egg then
[14:21] <bigjools> since that's the part that requires twisted
[14:22] <gary_poster> um
[14:22] <gary_poster> maybe.  I wouldn't have guessed so.
[14:22] <gary_poster> lemme try applying this.  1 sec
[14:22] <bigjools> you'll need to update your eggs
[14:22] <bigjools> well, dists
[14:23] <gary_poster> k
[14:26] <gary_poster> bigjools, I see "Error: Picked: txlongpoll = 0.2".  Fixing versions.cfg for that...
[14:26] <bigjools> gary_poster: weird, I don't see that
[14:28] <gary_poster> bigjools, ok now duped Twisted problem.  Looking more...
[14:28] <bigjools> gary_poster: ah right sorry, I had already applied the change to versions.cfg and didn't tell you :)
[14:28] <gary_poster> :-) cool
[14:28] <rvba> gmb: Could you mentor a review of mine? (the branch it self is from allenap)
[14:33] <gary_poster> bigjools: txlongpoll says it depends on twisted not Twisted.  The name is Twisted, and everything else spells it as such.  Apparently this confuses setuptools and/or buildout code.  You can verify by editing eggs/txlongpoll-0.2-py2.6.egg/EGG-INFO/requires.txt to have Twisted, not twisted.  Then build will complete successfully.  I suggest changing setup.py in txlongpoll and rolling a new release.
[14:33] <bigjools> argh
[14:33] <bigjools> I thought it might be something like that
[14:33] <bigjools> thanks gary_poster
[14:33] <gary_poster> welcome bigjools
[14:34] <bigjools> I can't do enough releases
[14:34] <gary_poster> :-)
[14:36] <flacoste> danilos: i agree with lifeless
[14:36] <danilos> flacoste, cool, so what do we do about it? ask cr3 to fix it all for us? :)
[14:37] <cr3> danilos: oh oh, what's this I hear about work?
[14:38] <flacoste> danilos: or ask a losa  if cr3 isn't responsive enough :-)
[14:39] <cr3> flacoste: good assumption! it would indeed make sense to have danilos on /ignore
[14:39] <gmb> rvba: Sorry, was otp. Certainly, I'd be happy to.
[14:39] <rvba> gmb: Thanks, here you go: https://code.launchpad.net/~allenap/launchpad/longpoll-storm-events/+merge/76215
[14:40] <gmb> rvba: Okay, I'll take a look shortly.
[14:40] <cr3> flacoste: seriously though, is this about builders, hardwaredb, results tracker or something else? I'm not seeing an obvious thread by scrolling above
[14:41] <flacoste> cr3: it's about the bug supervisor for launchpad-results
[14:41] <benji> gmb: if you get a minute to look at a simple lazr.restful branch, I'd appreciate it: https://code.launchpad.net/~benji/lazr.restful/bug-854695/+merge/76230
[14:41] <cr3> aha! I see now, bugs in launchpad-results. where can I familiarize myself with lp-project standards for bug supervision, I'm all for following that too
[14:41] <gmb> benji: I'll add it to my list.
[14:42] <benji> thanks
[14:42] <cr3> flacoste: someone did ask me to triage them more quickly before, which I've been doing so far.
[14:42] <flacoste> cr3: we'd like to change the bug supervisor so that the lp team can triage the bugs
[14:42] <cr3> flacoste: I suspect that "critical" might appear as a big red light on your radar though
[14:43] <flacoste> also
[14:43] <cr3> flacoste: if you change the bug supervisor to launchpad itself and I'm not a member of launchpad engineers, won't that case problems for me?
[14:43] <cr3> s/case/cause/
[14:44] <flacoste> cr3: we should create a new team and make ~launchpad part of it
[14:44] <cr3> flacoste: we've got ~launchpad-results, could we use that?
[14:46] <cr3> flacoste: I changed bug supervisor of launchpad-results to ~launchpad-results so, if you add that team to ~launchpad, we should be good to go
[14:46] <sinzui> gmb, do you have time to review https://code.launchpad.net/~sinzui/launchpad/dsp-official-branches-0/+merge/76128
[14:47] <flacoste> cr3: we want to add ~launchpad to ~launchpad-results
[14:47] <gmb> sinzui: I'll add it to my queue. Shouldn't be a problem.
[14:47] <cr3> flacoste: done
[14:53] <flacoste> cr3: thanks
[15:12] <danilos> cr3, thanks from me as well (if I am still not on your /ignore list :)
[15:13] <danilos> cr3, and I hope you won't be bothered with lp-devs mistriaging bugs for launchpad-results from now on, because that's what we do :)
[15:14] <adeuring> gmb: could you please review this MP: https://code.launchpad.net/~adeuring/launchpad/bug-739052-9/+merge/76241?
[15:15] <gmb> adeuring: There's a couple of branches in the queue in front of you, but I'll try to get to it.
[15:15] <adeuring> gmb: ok, thanks
[15:15] <cr3> danilos: bugs for launchpad-results are on my super sonic radar, so I'd like to see you try mistriaging bugs :)
[15:53] <bigjools> flacoste: your guess was right about the clashing twisted paths
[15:54] <flacoste> bigjools: do we need to use a plugins? can't we use a regular tac file?
[15:54] <bigjools> flacoste: we can't
[15:54] <bigjools> tacs don't let you pass command line args
[15:55] <bigjools> flacoste: ah I may be talking cobblers
[15:55] <bigjools> it does find it but there's an import error that twisted was masking
[15:55] <bigjools> hence ignoring the plugin
[16:05] <bigjools> gary_poster: I have an extra directory in txlongpoll that also needs to be in the egg. How do I make that happen?
[16:09] <gmb> sinzui: r=me with grammatical nitpicks
[16:10] <sinzui> thank you
[16:11] <nigelb> sinzui: Heh, re: the mailing list thread - Of course, you're the expert in mass bug status changes :P (j/k)
[16:12] <sinzui> nigelb, indeed. This script is actually from my 18 month effort to make sense of Lp's bugs
[16:13] <nigelb> sinzui: Its interesting how LP bugs are all Critical, High, or Low.
[16:13] <nigelb> I liked what stub suggested
[16:13] <nigelb> Critical should be reserved for things that need overnight/weekend fixing.
[16:14] <sinzui> There are only three states. LP engineers like to bend Lp rules while telling other projects not to do it
[16:15] <nigelb> sinzui: Which turns out to be - "Now!", "Some time in the next 6 months", "not any time soon"
[16:15] <sinzui> nigelb, The three states are: do now (move to the top of the schedule), do next (schedule), do whenever (wait for an opportunity when fixing another bug)
[16:17] <nigelb> sinzui: ah! that makes sense, yes.
[16:17] <nigelb> I tend to pick bugs from the last queue since those are the most unloved.
[16:18] <sinzui> nigelb, right. The performance-bugs-critical experiment failed because we could not distinguish between operational-critical bugs. maintenance squads work on critical (yet tagged work), feature squads work on high(yet tagged work)
[16:18] <nigelb> Ah.
[16:19] <bigjools> sinzui: case in point being the fact that poppy is still not fixed
[16:19] <nigelb> I was curious how feature squads picked work
[16:20] <bigjools> it's down to the lead, who is the project manager for that feature
[16:20] <sinzui> We tag bugs to be part of a feature. We mark the required ones as high, and the optional ones as low.
[16:21] <sinzui> nigelb, oh, and we mark those that happen to be oopes/regressions/timeouts as critical to remind our selves they really need to be fixed
[16:21] <nigelb> ah
[16:21] <nigelb> so, that explains the tags that I've seen
[16:22] <nigelb> and somewhere in betweeen the escalated bugs also come into play. I'm guessing those go to maintenance queue.
[16:22] <sinzui> nigelb, I would like to user words that help developers and users know what is going to happen when the bug's importance is set. maybe essential, expected, optional
[16:23] <nigelb> sinzui: Actually, it would be awesome if teams had the ability to Change bug statuses.
[16:23] <nigelb> Like, a project says, we will rename Critical to -> X, High -> Y, Low -> Z. We won't use the others.
[16:24] <nigelb> s/teams/projects
[16:26] <bigjools> flacoste: do you know how to get a non-python file in an egg?
[16:26] <sinzui> nigelb, I put some thought to that. We already map external importance to Lp importance. We could support a project mapping that permits qualification of the importance. There could be three mapping to low, one meaning  a feature request, a bug in the rules, a rare oops that users can recover from
[16:27] <nigelb> sinzui: But those can be done with status + tags. I like having fewer statuses than more.
[16:28] <sinzui> nigelb, me too. I never suggested we support that level of customisation. project owners sometimes ask for it, but that undermines inter-project collaboration
[16:28] <sinzui> User just want meaningful labels.
[16:29] <gary_poster> bigjools, /me lunching, but just saw your question.  The sarcastic solution is to use subversion, since setuptools has automatic support for that and only that.  The real solution is to use MANIFEST.in.  This is an underdocumented Python thingy.  Lemme see if I can find you the docs...
[16:30] <bigjools> gary_poster: ok thanks.  It's an xml file that the project needs to load at runtime :(
[16:32] <gary_poster> bigjools, ack.  So, the docs are http://docs.python.org/distutils/sourcedist.html and in particular http://docs.python.org/distutils/sourcedist.html#manifest-template .  A number of ye olde lazr.* packages have them, for .txt files and so on.  Here's an example: http://bazaar.launchpad.net/~lazr-developers/lazr.restful/trunk/view/head:/MANIFEST.in
[16:32] <bigjools> gary_poster: you rock, thanks
[16:32] <gary_poster> welcome
[16:33] <bigjools> gary_poster: ah so does it override the packages= on the setup() ?
[16:33] <nigelb> sinzui: Agreed (sorry, connection is being flaky today)
[16:34] <gmb> adeuring: I'm not going to be able to get through your branch before my EoD. Might be worth asking the next OCR, which is... StevenK, if I'm not mistaken.
[16:34] <adeuring> gmb: sure, no problem.
[16:35] <gmb> Thanks.
[16:46] <sinzui> jcsackett, do you have time to mumble
[16:48] <gary_poster> bigjools, sorry, had wandered away again.  AFAIK, it is different.  It describes what files locally in this directory tree should be included.  I don't think you can tell python files specified in packages= to take a hike, but then I've never tried.  Maybe it does override.  I've always done both.
[16:49] <bigjools> gary_poster: yeah I have it working nicely now, thanks
[16:49] <gary_poster> awesome
[17:30] <jcsackett> sinzui: i can mumble now--i was grabbing lunch when you pinged me. does now work for you?
[17:30] <sinzui> jcsackett, too late. I have a meeting with flacoste in 0 seconds
[17:30] <sinzui> Can we talk in about an hour?
[17:30] <jcsackett> sinzui: certainly.
[17:31] <flacoste> sinzui: skype time?
[17:31] <sinzui> flacoste, I am ready
[18:00] <cr3> is there a difference between the verb "new" and "create" in the launchpad api? is one preferred over the other in some circumstances?
[18:19] <flacoste> cr3: no. there isn't, fixing this inconsistency would be nice
[18:59] <sinzui> hi jcsackett. Do you have time to mumble?
[18:59] <jcsackett> sinzui: sure, just a moment.
[19:01] <jelmer> abentley: I'm pretty sure bug 854654 is a dupe
[19:01] <_mup_> Bug #854654: Cyrylic nicknames in ADC are not allowed <FlexHub:Confirmed> < https://launchpad.net/bugs/854654 >
[19:02] <jelmer> ehm, bug 854964
[19:02] <abentley> jelmer: I couldn't find another bug like it.
[19:02] <_mup_> Bug #854964: 2a format permits fetching tree-reference entries <2a> <nested-trees> <Bazaar:New> < https://launchpad.net/bugs/854964 >
[19:02] <jelmer> I recall filing one in the past, but can't find it now either..
[19:03] <abentley> jelmer: anyhow, it damages the prospects of converting the subtree branches to 2a, because we don't know what might be in their history.
[19:05] <abentley> jelmer: even though lp:~ebbe/+junk/game is the only one that could not be pulled into a 2a branch.
[19:46] <lifeless> sinzui: your summary of medium bugs includes low bugs
[19:46] <lifeless> sinzui: is it stale?
[19:48] <sinzui> lifeless, I think I need to recheck the rules. I expected duplicates from multiple bug tasks, but not actual errors
[19:49]  * sinzui rechecks the script
[19:49] <lifeless> sinzui: I just invalidated the bug about email processing not being tested enough
[19:49] <lifeless> as a not-useful-bug
[19:49] <lifeless> but
[19:49] <lifeless> it was low
[19:49] <lifeless> and in your list of mediums :)
[19:49] <lifeless> you made it low yourself not long ago
[19:51] <sinzui> ha, I tend to do that when I view a Medium bug. My new report will be done in a few minutes.
[19:52] <lifeless> it was bug 30138
[19:52] <_mup_> Bug #30138: Notifications generated by the email interface should be properly tested <email> <lp-bugs> <story-better-notification-sending> <test-system> <Launchpad itself:Invalid> < https://launchpad.net/bugs/30138 >
[19:53] <sinzui> ah, I am not getting open-only bugs. So much for the default search rules.
[19:53] <lifeless> sinzui: you are
[19:53] <lifeless> sinzui: I *closed* it when I saw it in the list.
[19:53] <sinzui> :)
[19:54] <lifeless> sinzui: my concern is that it was *low* since '2011-08-26'
[19:54] <lifeless> so your list must be a month old or something
[19:54] <lifeless> (a month old | buggy)
[19:54] <lifeless> if its a month old its fine. If its buggy its not :)
[19:55] <sinzui> While the script pre-exists, the list was made this morning. I wonder if I have cached bugs
[19:55] <timrc> anyway to get at ppa creation date from the web service api?
[19:55] <lifeless> then there was something significantly wonky
[19:55] <timrc> does not look like it from my cursory check :/
[19:56] <lifeless> sinzui: I see 967 medium bugs
[19:56] <lifeless> sinzui: ah, thats lp; lp-project: 1068
[19:57] <sinzui> yes, I am searching lp-project
[19:57] <lifeless> sinzui: I think we can just close many of these
[19:57] <lifeless> e.g. https://bugs.launchpad.net/launchpad/+bug/3454
[19:57] <_mup_> Bug #3454: Should have a UI for assigning multiple tasks to a milestone <lp-bugs> <milestone-management> <Launchpad itself:Triaged> < https://launchpad.net/bugs/3454 >
[19:57] <sinzui> Well I think that of many low bugs. as well
[19:58] <lifeless> its obviously a work item in planned work, rather than a defect report describing a users issue / limitation the user encountered.
[19:58] <lifeless> I will do a table scan of these.
[19:58] <sinzui> I remind myself that if a user provided a patch, I would accept it
[19:58]  * lifeless opens 100 tabs
[19:59] <lifeless> okok, 75
[19:59] <nigelb> ...
[19:59] <nigelb> lifeless: Aren't you supposed to be away today?
[19:59] <sinzui> lifeless, the feature aspect of the bug is an interesting point considering that many of the bugs are reported by us as an idea that seamed relevant 3 years ago
[20:00] <lifeless> sinzui: I agree
[20:01] <lifeless> sinzui: but I think for most things we have no shortage of ideas on how to improve; they don't generally have value like a report of how something affected a user.
[20:01] <lifeless> sinzui: I won't be cavalier
[20:01] <lifeless> sinzui: if you want to take the second page of a web search for medium bugs in -project, default sort order; we could triage 10% of the total in about 10 minutes.
[20:02] <lifeless> nigelb: yes, but thats never stopped me.
[20:02] <sinzui> jml said something similar. I wish I could remember the exact phrasing of his witticism.
[20:02] <nigelb> lifeless: Good point. I was planning to pick your brains tomorrow morning.If you will be around later today, I might just do that :)
[20:02] <lifeless> nigelb: Think of it as priorities: today my priority is my family. But I may do somework. On work days my priority is work, but I may look after my family.
[20:02] <nigelb> lifeless: Well said :)
[20:04] <sinzui> lifeless, the difference in my numbers and lp-projects numbers is that I not subscribed to all private bugs :)
[20:06] <lifeless> sinzui: sure, but how did that low bug get in the list ?
[20:07] <sinzui> lifeless, I cannot explain. My revised report only shows mediums: http://pastebin.ubuntu.com/694004/
[20:09] <sinzui> lifeless, sorry. I ran against qastaging!
[20:09]  * sinzui runs against lpnet
[20:10] <lifeless> sinzui: haha :)
[20:14] <lifeless> do we support debtags yet ?
[20:15] <lifeless> no :)
[20:19] <lifeless> bug 4730 - does the publisher have a --dry-run ?
[20:19] <_mup_> Bug #4730: Publisher tool option to only change the database, not the archive <lp-soyuz> <Launchpad itself:Incomplete> < https://launchpad.net/bugs/4730 >
[20:20] <lifeless> hah
[21:05] <sinzui> jcsackett, r=me
[21:05] <jcsackett> sinzui: hurray!
[21:05] <jcsackett> sinzui: any chance this can wait a bit too land? i'd like to take some time to debug my ec2 issues and having a branch to send out would be nice. :-)
[21:06] <jcsackett> s/too land/to land/
[21:06] <sinzui> land as you you wish
[21:07] <lifeless> sinzui: https://bugs.launchpad.net/launchpad/+bug/34343
[21:07] <_mup_> Bug #34343: Shouldn't allow task or blueprint reassignment to an upstream that doesn't use Launchpad <lp-blueprints> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/34343 >
[21:08] <lifeless> sinzui: did we perhaps fix-by-driveby that ?
[21:08] <sinzui> hmm
[21:09] <sinzui> lifeless, I do not think so. I reported that bugs has the same error last month
[21:09] <lifeless> ah, so there is a dupe out there ? :)
[21:10] <sinzui> lifeless, this they are not since we need three vocabs, each to represent valid spectarget, bugtarget, and questiontarget
[21:10] <sinzui> The current fields only require an active target
[21:11] <lifeless> ahhh! - you know that librarian bug
[21:11] <lifeless> waaaay old dup
[21:11] <lifeless> https://bugs.launchpad.net/launchpad/+bug/34758
[21:11] <_mup_> Bug #34758: librarian will set type to text/html though it should be text/plain <infrastructure> <librarian> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/34758 >
[21:12] <lifeless> ah no its not
[21:12] <sinzui> I do not think it is either.
[21:23] <lifeless> do we have a formatter for libraryfilealias ?
[21:28] <lifeless> nearly done
[21:38] <lifeless> \o/
[21:38] <lifeless> 10% done
[21:53] <lifeless> I hope I didn't overwhelm anyone's mail queue :)
[22:40] <sinzui> wallyworld_, wgrant, StevenK. I will be 15 minutes late to the standup
[22:40] <wallyworld_> sinzui: ok
[22:50] <lifeless> james_w: hi