[12:07] <sabdfl> good work bradb
[12:07] <lifeless> sabdfl: revisions 2121/2373 1:09:24
[12:08] <lifeless> hiatus while I went to the xtc meeting
[12:08] <lifeless> will let it run overnight, but I have high hopes
[12:08] <sabdfl> lifeless: no ways, still 1:09?
[12:08] <bradb> there's some improvements i'd like to jump in on right after this branch lands, like adding a sane distro sp details portlet (the DR SP doesn't feel right for a DSP, to me)
[12:08] <lifeless> sabdfl: yeah, it was suspended :)
[12:08] <sabdfl> bradb: i will do fresh content objects for D+SPN, DR+SPN, etc soon
[12:09] <bradb> noted
[12:09] <sabdfl> lifeless: if it crashes, can you resume it gracefully?
[12:09] <lifeless> sabdfl: no, though you can run it in segments and resume frm those
[12:23] <mdz> kiko: wasn't I supposed to get a langpack export a few "tomorrows" ago?
[12:29] <mpool> #malone
[12:30] <mpool> hi, BjornT or bradb?
[12:30] <bradb> mpool: hi
[12:32] <mpool> hi bradb
[12:32] <mpool> so we'd like to start tracking bzr bugs on malone
[12:33] <mpool> as you (probably) know, we have two codebases in one product, with one of them probably fading away
[12:33] <mpool> how should we set this up in malone
[12:33] <mpool> the main requirement is that users or developers interested in the bzr python codebase should never see baz bugs
[12:33] <mpool> and vice versa
[12:33] <mpool> it would be confusing and annoying if they get mixed in together
[12:33] <mpool> should we just create two products, or is there some way to keep them separate within one product?
[12:34] <mpool> oh, maybe we should have two products inside one project?
[12:34] <bradb> There's already a bazaar product in Malone
[12:34] <mpool> yes i know
[12:34] <mpool> but there doesn't seem to be any way to segregate bugs within it?
[12:34] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=SteveA]  clean up spec tracker pages (patch-2403: mpt@canonical.com)
[12:35] <bradb> mpool: Nope. Can you just create another product specific to bzr?
[12:35] <mpool> sure
[12:35] <mpool> just wanted to check if i was missing something
[12:35] <mpool> thanks!
[12:35] <bradb> no prob
[12:35] <mpool> btw, what do you expect the weather will be like at UBZ?
[12:35] <bradb> mpool: slightly BZ probably :)
[12:36] <mpool> but not -10 yet?
[12:36] <bradb> possibly, but i wouldn't expect that to be the average at that time of year
[12:37] <mpool> thanks
[12:56] <bradb> "124 files changed, 2033 insertions(+), 1107 deletions(-)" -- in BjornT's queue now
[12:59] <lifeless> night all
[12:59] <lifeless> sabdfl: looking good : revisions 2307/2373 0:18:08
[01:07] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=SteveA]  clean up spec tracker pages (patch-2404)
[01:38] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=SteveA]  clean up spec tracker pages (patch-2405)
[03:47] <dilys> Merge to rocketfuel@canonical.com/dists--devel--0: [trivial]  Next production config (patch-112: stuart.bishop@canonical.com)
[04:52] <dilys> Merge to rocketfuel@canonical.com/dists--devel--0: [trivial]  Fix production version number in config (patch-113: stuart.bishop@canonical.com)
[05:45] <dilys> Merge to rocketfuel@canonical.com/launchpad--production--1.32: Cherry pick patch-2399 into production (patch-1: guilherme.salgado@canonical.com, rocketfuel@canonical.com)
[06:13] <dilys> Merge to rocketfuel@canonical.com/launchpad--production--1.32: Cherry pick patch-2400 into production (patch-2: mpt@canonical.com, rocketfuel@canonical.com)
[06:49] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Switch on db_statement_timeout in production Launchpad instances (patch-2406: stuart.bishop@canonical.com)
[08:28] <stub> Anyone going to bitch loudly if I take Launchpad down now for upgrades? Might be two hours or so this time.
[08:29] <spiv> stub: Database too?
[08:29] <stub> Yup
[08:29] <spiv> Hmm, the authserver might be an issue for some people :/
[08:29] <stub> Need to do a full dump/restore I've been putting off for a while
[08:29] <lifeless> think of the children
[08:30] <spiv> I should implement AuthServerCaching, I guess ;
[08:30] <spiv> ;)
[08:30] <stub> spiv: I think that is pretty much in my court for 'setup a read only replica'
[08:32] <spiv> stub: Hmm, there's a small amount of authserver code required too :)
[08:32] <stub> But I think I've worked out how to do that with a minimum of hassle, but need to clear out a few other tasks first. Will give steve his readonly db too.
[08:33] <stub> spiv: Yer, but that will only take you a few minutes ;)
[08:33] <spiv> Heh.
[08:33] <SteveA> morning people
[08:36] <stub> hail
[08:38] <stub> And SteveA can see the launchpad down for maintenance page right now if he likes
[08:39] <stub> Pitty Pound roots it by sticking its own headers at the top
[08:41] <SteveA> ewww
[08:41] <SteveA> does it *have* to?
[08:42] <jamesh> it is probably a simple matter of code to fix it
[08:42] <stub> Looks like it. We could hack Pound (and then we would need to repackage it for installation), or just do it in Apache.
[09:36] <spiv> Eek, gotta go...
[09:58] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Tweak Gina warning levels (patch-2407: stuart.bishop@canonical.com)
[10:27] <mdke> hi all
[10:27] <mdke> what is the ETA for lp being back?
[10:27] <SteveA> 20 mins
[10:27] <mdke> thanks
[10:49] <sivang> Morning all!
[11:04] <Kinnison> stub: did you mean to merge the fix-whitespace stuff in -2407?
[11:05] <stub> That's fine. PQM just ate my previous [trivial]  on that branch.
[11:07] <Kinnison> righ
[11:07] <Kinnison> +t
[11:07] <Kinnison> just thought I'd point it out in case it wasn't meant to have happened
[11:07] <lifeless> Kinnison: are you coming up tonight ?
[11:08] <Kinnison> lifeless: No, tomorrow morning
[11:08] <lifeless> Kinnison: K
[11:08] <Kinnison> any earlier and I'd have to leave tonight practically
[11:09] <Kinnison> and I have a date with a steel rule and a circular saw tonight
[11:09] <Kinnison> gotta prepare the kitchen for having the floor put in
[11:15] <sivang> Kinnison: into home improvements eh? :)
[11:15] <sivang> Kinnison: howdy 
[11:15] <mdke> jordi, around?
[11:15] <Kinnison> sivang: aye
[11:21] <mdke> SteveA, how about now?
[11:21] <sabdfl> stub: ping
[11:21] <stub> sabdfl: Pong
[11:21] <sabdfl> stub: can i privmsg you a db patch?
[11:22] <jordi> mdke: for a few mins
[11:22] <mdke> jordi, we have a huge problem with the faqguide.pot :/
[11:22] <stub> paste is better -- https://chinstrap.ubuntu.com/~dsilvers/paste/ 
[11:22] <jordi> mdke: really? what is it?
[11:23] <mdke> jordi, launchpad is down so I can't show you it in rosetta, but if you go to sg you a db patch?
[11:23] <mdke> argh
[11:23] <mdke> start again
[11:23] <jordi> yeah, I can't parse that at all :D
[11:23] <mdke> if you go to https://docteam.ubuntu.com/repos/branches/breezy/generic/faqguide/C/faqguide.pot
[11:24] <jordi> ok
[11:24] <mdke> jordi, then search for installing-applications.xml:10(para)
[11:24] <jordi> done
[11:24] <mdke> that line is totally ridiculously long and includes a number of paragraphs in the actual text
[11:25] <jordi> wow
[11:25] <jordi> there's "See . " stuff in there.
[11:25] <jordi> Have you contacted shaunm about it?
[11:25] <jordi> I suspect somethign in your xml is not so good.
[11:25] <jordi> wher'es the xml?
[11:25] <mdke> jordi, i pinged him now
[11:26] <jordi> I see it
[11:26] <mdke> https://docteam.ubuntu.com/repos/branches/breezy/generic/faqguide/C/installing-applications.xml
[11:27] <mdke> jordi, moving channel
[11:28] <jordi> #docs?
[11:33] <mdke> jordi, what really worries me is that if we use a different utility to create a better pot file, then upload it, a lot of translation will be lost :/
[11:43] <stub> SteveA: ping
[11:46] <sabdfl> stub: mailed
[11:46] <sabdfl> mdke, jordi: PO is really not ideal for documents
[11:46] <sabdfl> but i can't think of a better plan right no9w
[11:47] <mdke> :(
[11:55] <sabdfl> stub: s/person/owner/g
[11:56] <stub> lifeless: If there are no dependancies of cscsv on launchpad, why do we need to run cscvs tests when we commit launchpad changes? It would be impossible for a launchpad commit to stop cscsv tests passing.
[11:57] <mdke> sabdfl, jordi, i don't know whether I should send an email to warn translators to stop translating the guide until the issue with the pot is resolved, what do you think?
[11:57] <lifeless> stub: eh? cscvs uses lp interfaces
[11:57] <stub> It does? Ahh bugger
[11:58] <lifeless> are you referring to the race condition with nc ?
[11:58] <stub> sabdfl: Argh.... a diff. Now I need to strip all the '+' signs :-(
[12:01] <sabdfl> stub: if you are happy with the comments i can send you the patch directly
[12:01] <sabdfl> sorry, the .sql file
[12:01] <stub> sabdfl: Nah - got it. 
[12:02] <stub> sabdfl: Looks fine. patch-25-26-0.sql. 
[12:03] <sabdfl> stub: super, thanks
[12:03] <stub> sabdfl: (pending the person->owner change of course)
[12:04] <sabdfl> stub: done
[12:05] <jordi> mdke: maybe it's wise. Let's see if you get something from the mailing list.
[12:05] <jordi> Hopefully you will
[12:15] <Kinnison> anyone want to review a quick publisher change?
[12:15] <Kinnison> It's a touch large to [trivial]  but it needs to get in fairly soon
[12:16] <Kinnison> https://chinstrap.ubuntu.com/~dsilvers/paste/fileiJyx2B.html
[12:16] <Kinnison> It's d-i support for the C.A.P.
[12:17] <lifeless> pep8ness
[12:17] <lifeless> self._has_di, not _hasdi
[12:17] <lifeless> dituples->di_tuples
[12:18] <lifeless> also tup and tuples are really hirrble variable names
[12:18] <lifeless> what is a didr ?
[12:19] <lifeless> whats a comp ?
[12:19] <Kinnison> a didr is a debian_installer_distrorelease
[12:19] <lifeless> if you have to explain it, the variable name is probably wrong
[12:19] <Kinnison> the variable's existence is there purely because otherwise the line is too long
[12:20] <Kinnison> I wanted to do self._has_di.setdefault(dr, Set()).add(comp)
[12:20] <Kinnison> but that wraps
[12:20] <Kinnison> and I think it's less ugly to use a temp var than to split it on the comma
[12:20] <lifeless> its also pretty darn opaque
[12:20] <Kinnison> I'd docstring self._has_di if you could do that sort of thing
[12:20] <lifeless> I didn't critque the temp vars existnece, I critiqued its name
[12:21] <lifeless> you'll have less problems with line wrapping if you write smaller functions too
[12:22] <Kinnison> Hmm
[12:22] <Kinnison> Okay, I'll tidy up the pep8ness and try and make the stuff more understandable
[12:22] <lifeless> so rather than a detailed review, I suggest you read it out loud to a teddy bear.
[12:23] <lifeless> and anytime its face gets blank, make the code more clear
[12:24] <lifeless> freddybear obviously knows too much about buildds
[12:24] <Kinnison> He helped me write the publisher :-)
[12:25] <mdke> jordi, mailed
[12:25] <jordi> mdke: the list?
[12:25] <jordi> oh, the translators.
[12:25] <jordi> let's hope we can resolve this ASAP
[12:25] <mdke> everything :D
[12:26] <mdke> jordi, i'm going to try the kde util and see if the pot file is any better
[12:26] <jordi> mdke: xml2po was missing info, or was it just doing huge para's?
[12:26] <jordi> mdke: nod
[12:26] <mdke> jordi, both I think
[12:26] <jordi> let's see what you find out
[12:26] <jordi> maybe <answer> confuses it.
[12:26] <Kinnison> What's the dict iterator which gives you key,value tuples?
[12:26] <Kinnison> is it .items()
[12:26] <Kinnison> ?
[12:27] <lifeless> ddping
[12:27] <mdke> jordi, yes, it may not support qanda set
[12:29] <mdke> jordi, can you push my mail through to rosetta-users, it needs to be moderated
[12:29] <jordi> in a min
[12:30] <mdke> thanks
[12:30] <mdke> it hasn't got through to any list :/
[12:31] <mdke> i'll cancel and try again
[12:32] <jordi> yours is accepted
[12:32] <mdke> thanks
[12:35] <WaterSevenUb> mdke, thx
[12:56] <SteveA> stub: pong
[12:56] <stub> SteveA: We are still getting lockups. Looks like long running or blocked queries.
[12:57] <stub> SteveA: Possibly update-stats.py is the culprit
[12:57] <SteveA> interesting.  why would that lock up the webapp?  because the postgres backend is so busy?
[12:57] <SteveA> or are some tables locked?
[12:58] <stub> SteveA: If a process has updated rows, but not committed, anything selecting on that table will block
[12:59] <SteveA> does update-stats.py do that?  as in, not commit for a while after updating stuff?
[01:00] <SteveA> if you selectively kill off cron jobs, does the webapp return?
[01:00] <stub> SteveA: Yes. But I'm not 100% sure yet.
[01:01] <stub> SteveA: It might also be these rosetta queries too just taking too long
[01:10] <SteveA> well, i can't access launchpad.net now
[01:10] <SteveA> can you kill all cron scripts ?
[01:11] <SteveA> would the DB need bouncing too?
[01:12] <Kinnison> lifeless: is https://chinstrap.ubuntu.com/~dsilvers/paste/file9TWzrW.html better?
[01:12] <SteveA> has_di ?
[01:12] <SteveA> what's a "di" >?
[01:13] <SteveA> comment or better variable name please
[01:13] <lifeless> ahahaha
[01:14] <lifeless> Kinnison: see!
[01:15] <lifeless> Kinnison: still very opaque. steve's commend is right on
[01:15] <lifeless> s/mend/ment
[01:15] <lifeless> Kinnison: i.e. whats a di_tuple ? really, what does it _mean_ not what typ eit is.
[01:17] <Kinnison> okies
[01:18] <lifeless> better names >> comments
[01:18] <Kinnison> so _has_debian_installer_inside_components_for_distrorelease ?
[01:18] <Kinnison> I'm all for good variable names for simple things :-)
[01:19] <lifeless> I don't get whaat has debian installer inside components for distrorelease means
[01:19] <lifeless> tell me about this, here, in englihsh
[01:19] <lifeless> I'll try and translate to english.
[01:19] <Kinnison> Okay
[01:19] <Kinnison> so each distrorelease has a bunch of components in it
[01:20] <Kinnison> some of those components will contain binaries which are for debian-installer rather than the distrorelease itself
[01:20] <Kinnison> we have to note down which components of which distroreleases have debian-installer bits in them so that we can construct the correct configuration for apt-ftparchive later
[01:20] <Kinnison> in _has_di I store (keyed by distrorelease name) a Set of the component names which contain debian-installer binaries
[01:21] <lifeless> so that is the 'debian installer components for distrorelease' ?
[01:21] <Kinnison> More 'components for debian-installer by distrorelease'
[01:22] <lifeless> ok.
[01:22] <lifeless> thats understandable.
[01:22] <Kinnison> But that's 'what' rather than 'why'
[01:22] <lifeless> now, you have a dictionary of distroreleases with the components for d-i in that release
[01:23] <lifeless> what about _di_release_components ? with a comment that this is the components for d-i in each distro release
[01:23] <lifeless> or release_di_components
[01:24] <lifeless> may well still need a comment, but at least is a vaguely informative variable name
[01:24] <sabdfl> is PQM jammed?
[01:24] <Kinnison> I've put a comment in anyway, detailing what it stores, where it is generated and where it is consumed
[01:24] <Kinnison> because I think that'll be useful
[01:25] <Kinnison> so it's just chosing a name
[01:25] <lifeless> sabdfl: was
[01:26] <SteveA> pqm didn't allow my merge, with ERROR: testAnwersOnce (CVS.tests.test_CVS.PServerHelperTest)
[01:26] <lifeless> SteveA: thats the CVS race condition
[01:26] <SteveA> lifeless: can we disable these CVS tests for a while, until they are reliable again?
[01:28] <lifeless> SteveA: up to you, do you trust us not to break launchpad via cscvs, or vice verca
[01:28] <lifeless> s/launchpad/importd
[01:28] <lifeless> Kinnison: moving right aling
[01:28] <SteveA> i don't care about breaking the specific code that the tests that have a race condition test
[01:28] <SteveA> because the tests are faulty
[01:29] <lifeless> uhm, they aren't testing a race condition, there is a race condition in th etests that is causing the problem
[01:29] <SteveA> that's what i meant.  my english was ambiguous.
[01:30] <SteveA> jamesh: ping
[01:31] <jamesh> SteveA: pong
[01:32] <SteveA> hi.  stub says that the code that is supposed to make long-running queries time-out doesn't seem to be working.
[01:32] <Kinnison> lifeless: okay, added explanatory comment in __init__ and renamed _has_di to _di_release_components
[01:32] <SteveA> i'm looking at canonical/database/adapter.py now
[01:33] <lifeless> Kinnison: rediff, lets have a look
[01:33] <Kinnison> running now
[01:33] <SteveA> jamesh: can you take a fresh look at it, just to see if anything obvious looks wrong
[01:34] <jamesh> SteveA: what value do you have db_statement_timeout set to in the launchpad.conf?
[01:36] <stub> 60
[01:36] <SteveA> we should have at least a manually runnable functional test for that
[01:36] <stub> (Originally 4000, but I knocked it down a bit in case it was seconds instead of ms)
[01:36] <SteveA> like, a deliberately slow query on a page on the debug skin
[01:37] <stub> Doesn't need to be a page test. Can fake a slow query easily enough using a Python server side procedure.
[01:37] <jamesh> it seems to work here
[01:38] <SteveA> jamesh: how did you test it?
[01:38] <jamesh> SteveA: set it to a low value, and then ran some other job to burn CPU time
[01:38] <lifeless> ddaa: ping
[01:38] <SteveA> also, the "print" should be a log surely
[01:38] <ddaa> lifeless: pong
[01:39] <lifeless> ddaa: how did pythons cvs import go ?
[01:39] <lifeless> ddaa: and how is the svn fi for samba looking ?
[01:39] <jamesh> I got a "ProgrammingError: ERROR:  canceling query due to user request" exception
[01:40] <ddaa> python has failed twice since the sprint for various connection problems, right now it's at changeset 10043
[01:40] <jamesh> SteveA: unfortunately, it is a statement timeout rather than a transaction timeout
[01:40] <lifeless> ddaa: out of ?
[01:40] <jamesh> so it is possible for a query to do a lot of work and still not hit the timeout
[01:40] <ddaa> out of 32425
[01:41] <lifeless> ddaa: thanks.
[01:41] <SteveA> jamesh: okay.  so, we should also have an overall request processing timeout.
[01:41] <SteveA> stub and i discussed this before.
[01:41] <SteveA> one way to do it is to have the database adapter check some value before each query
[01:42] <ddaa> yesterday, had a short day to sort some appartment related issues, and spent it all on replying spiv's review for the nested log parsing (python fix) patch for cscvs
[01:42] <SteveA> and have that value change when the request has gone on too long
[01:42] <stub> jamesh: Can you issue a few more requests and see if it still happens (ie. that the setting isn't reset next time that handler thread handles a query)
[01:42] <ddaa> so, nothing new for samba, but it's the next thing to do
[01:42] <Kinnison> lifeless: https://chinstrap.ubuntu.com/~dsilvers/paste/fileXl82lz.html
[01:42] <SteveA> either the value can be the latest time some query can start to be executed
[01:42] <SteveA> or the value can be a boolean that is set by an event
[01:42] <lifeless> ddaa: ok. please keep me posted, Its very urgent
[01:43] <jamesh> I suppose we could do that by recording when the transaction started, and rollback/fail any future statements past the timeout
[01:43] <SteveA> setting to a max value is probably the simplest, although it does mean regular calls to time.time() i guess
[01:43] <SteveA> i don't know how expensive time.time() is
[01:43] <SteveA> not for a transaction -- for the whole web request.
[01:43] <SteveA> so, the web publisher would set the value upon receiving the request for processing
[01:44] <SteveA> and unset the value at the end of that request's processing
[01:44] <SteveA> the value would be thread.local
[01:44] <SteveA> or, set on the connection used for that thread, if there is definiely one connection per request.
[01:45] <SteveA> a thread.local seems less tightly coupled to connection policies though
[01:45] <SteveA> and, i want to decouple these things for supporting read-only connections for GETs 
[01:45] <jamesh> so at what points do we check the timeout?
[01:45] <stub> You could perform the check in the database adapter - that seems a common point to do the check and raise an exception if the request has taken too long
[01:45] <jamesh> okay
[01:45] <SteveA> stub: yes, i think that's what i meant to say above
[01:47] <SteveA> both these things together, that is, max request time and max single query time, should make the webapp more available in general.
[01:47] <stub> Read only connections are just a case issuing  'set transaction read only' it turns out btw.
[01:47] <SteveA> oh
[01:47] <SteveA> so, no need for an extra user
[01:47] <SteveA> that's cool
[01:47] <SteveA> i can do that today ;-)
[01:47] <SteveA> so, that can be added to the launchpad database adapter too
[01:47] <SteveA> i mean, a method to say "set transaction read only"
[01:48] <stub> Just make sure it gets set back again too ;)
[01:48] <SteveA> hmm...
[01:48] <SteveA> but there can be many transactions in a single request
[01:48] <SteveA> i want all transactions for that request to be read only
[01:49] <stub> eh? There is only one transaction per request. You are thinking connections.
[01:50] <SteveA> there can be more than one transaction per request
[01:50] <SteveA> for example, when someone commits 
[01:50] <stub> Nobody should be committing in the webapp
[01:51] <stub> And Zopeless doesn't use the DA anyway
[01:51] <SteveA> according to my grep, only script code is committing
[01:51] <SteveA> so, that's good
[01:52] <SteveA> i'd still rather do it right, if it isn't so hard to do
[01:53] <jordi> mdke: oh dear. 
[01:53] <jordi> I suspected xml2po didn't like something in the doc.
[01:54] <stub> We should make the publisher raise a 503 or something if there are more than X requests in the queue waiting to be handled
[01:54] <stub> erm... the http service I mean, not the publisher
[01:55] <lifeless> Kinnison: your comment talks about _has_di!
[01:55] <Kinnison> lifeless: arse, well spotted
[01:56] <lifeless> still go tthis 'di_tuples' thing
[01:56] <lifeless> tell me about di_tuples
[01:56] <Kinnison> it is a list of the tuples we save to output to the di overrides instead of the normal overrides
[01:56] <lifeless> thats in these tuples ?
[01:57] <lifeless> s/that/what/
[01:57] <Kinnison> assuming you mean "what's in these tuples?" the answer is "a set of columns to be output tab-separated to the override files"
[01:57] <Kinnison> specifically package name, priority and section
[01:57] <lifeless> so it would be reasonable to call them 'di_overrides' ?
[01:57] <Kinnison> aye, I guess that'd be sane
[01:58] <lifeless> would it be clearer :)
[01:59] <lifeless> calling something that is a list of type-X's thing-'Xs' or 'X'-things is usually very unclear
[01:59] <lifeless> its like 
[01:59] <lifeless> ints = [1,2,3,5,7,11,13 ..] 
[02:00] <lifeless> when what you use it for is 'for prime in ..'
[02:00] <lifeless> so, rule of thumb I'd like you to imprint on your brain: when you see a type name in a variable name, THINK HARD.
[02:01] <lifeless> for name in names -> what are they names of? package_names ? file_names ?
[02:02] <Kinnison> file_names
[02:02] <lifeless> drfullname <- pep8ify please
[02:02] <SteveA> stub: surely apache / pound can do the "too many requests" error, and not even pass it on to zope
[02:03] <Kinnison> I do so hate under_scored_variable_names
[02:03] <Kinnison> they're uggerlee :-)
[02:03] <SteveA> https://launchpad.net/ gave me a 502 proxy error, with a nasty error page.
[02:03] <stub> SteveA: Pound can't. No idea about Apache.
[02:04] <SteveA> i'm getting launchpad pages again. hurrah
[02:04] <stub> Yay specs page not found
[02:04] <dilys> Merge to rocketfuel@canonical.com/launchpad--production--1.32: Cherry pick patch-2406 into production (patch-3: stuart.bishop@canonical.com, rocketfuel@canonical.com)
[02:04] <SteveA> stub: one line fix
[02:05] <SteveA> stub: the link in the menu is to /+specs, but the page is (and should be) just /specs
[02:05] <SteveA> it is correct in staging
[02:05] <SteveA> want me to find you the line that needs to change?
[02:06] <lifeless> Kinnison: +                        cnf.write(s % {
[02:06] <lifeless> +                            "LISTPATH": self._config.overrideroot,
[02:06] <stub> I'm working on lockups atm ;)
[02:06] <lifeless> that stuff, could benefit by being put in a smaller more readable funtion
[02:06] <lifeless> Kinnison: i.e. 'self.write_component'
[02:07] <Kinnison> given that it's a long argument list, so it'd be best served with named arguments
[02:07] <lifeless> the calling code will be a shorter semantic statement
[02:07] <Kinnison> and thus won't be any timpler
[02:07] <lifeless> the dirty stuff will be out of the way
[02:08] <Kinnison> you mean hide the d-i changes behind some "isDebianInstaller=True" argument or something?
[02:08] <lifeless> def write_di_component (self, dr, pocketsuffix[pocket] , component, arches)
[02:08] <lifeless> dor instance.
[02:08] <lifeless> bah, for.
[02:08] <Kinnison> it'd have to cope with the non-di situation too
[02:09] <lifeless> def write_component(...)
[02:09] <lifeless> let me put it another way. you ahve a _long_ function that you are making longer.
[02:10] <Kinnison> it doesn't feel right/useful to me to split it out, but I'll do so if you think it's important
[02:11] <lifeless> can you paste the entire file up?  I'd like to see it in context
[02:11] <mdke> jordi, yeah. well at least hopefully we can figure out how to fix it
[02:11] <mdke> jordi, this danilo guy sounds helpful :D
[02:11] <Kinnison> https://chinstrap.ubuntu.com/~dsilvers/publishing.py
[02:12] <jordi> mdke: danilo is the man
[02:12] <lifeless> Internal Server Error
[02:12] <mdke> jordi, cool
[02:12] <Kinnison> lifeless: wowyay
[02:12] <Kinnison> https://chinstrap.ubuntu.com/~dsilvers/publishing.py.txt ?
[02:12] <jordi> mdke: plus, lives in a decent timezone :)
[02:12] <lifeless> Internal Server Error
[02:12] <lifeless> try publishing.txt
[02:13] <Kinnison> pub.txt
[02:14] <lifeless> ok.
[02:14] <lifeless> this makes some stuff clearer
[02:14] <lifeless> 's' is a template for the apt output yes ?
[02:14] <Kinnison> yeah
[02:14] <Kinnison> It's a poor name
[02:14] <Kinnison> I've already changed it to "stanza"
[02:14] <lifeless> why is it in the for pocked in loop ?
[02:14] <Kinnison> but I didn't upload that
[02:14] <lifeless> thats ok, I'm not blaming you :)
[02:15] <Kinnison> because it's dumb
[02:15] <Kinnison> updated pub.txt
[02:16] <lifeless> ok, I suggest this, before # replace those tokens
[02:16] <sabdfl> stub, jamesh: what's the best way to store a date, rather than a datetime?
[02:16] <SteveA> depends what you want to do with it
[02:17] <SteveA> for example, the string YYYY-MM-DD is good for some things
[02:17] <SteveA> a date is good
[02:17] <sabdfl> for example, the date a sprint starts, and the date it ends
[02:17] <SteveA> if it is a date you want
[02:17] <SteveA> a datetime.date object then
[02:17] <sabdfl> also, the date a person arrives at a sprint, and the date they depart
[02:17] <sabdfl> in SQL?
[02:17] <SteveA> this is why i dislike our use of datecreated etc. in the database
[02:17] <SteveA> because these are datetimes created
[02:17] <lifeless> def write_pocket(components, sections, extensions, cache_prefix):
[02:17] <SteveA> a better name would be "whencreated"
[02:17] <jamesh> sabdfl: postgres has a date type.  I haven't tried it with DateTimeCol or UtcDateTimeCol though
[02:17] <SteveA> so as not to confuse things with pure dates
[02:18] <SteveA>     def getPendingTasksEstimate():
[02:18] <SteveA>         """Returns an estimate of the number of tasks waiting to be serviced.
[02:18] <SteveA>         This method may be useful for monitoring purposes.  If the
[02:18] <SteveA>         number of pending tasks is continually climbing, your server
[02:18] <SteveA>         is becoming overloaded and the operator should be notified.
[02:18] <SteveA>         """
[02:18] <lifeless>     cnf.write(stance ...)
[02:18] <SteveA> stub: see above
[02:18] <spiv> jamesh: There's a DateCol in SQLObject.
[02:18] <spiv> jamesh: Which expects a column of type DATE in postgres.
[02:18] <SteveA> stub: we can hook something in that uses that on accepting new connections
[02:18] <sabdfl> jamesh: is it smart about things like start and end dates? the tricky questions are, like, if your "departure date is 11/09/01, are you still around on that date?"
[02:18] <Kinnison> lifeless: as a nested function?
[02:18] <lifeless> that will nicely factor this out, without a stupidly long parameter list
[02:18] <lifeless> Kinnison: yes
[02:19] <Kinnison> Okay, I'll try
[02:19] <Kinnison> one sec
[02:19] <lifeless> it also makes the stanza template local.
[02:19] <jamesh> sabdfl: it simply stores yyyy-mm-dd.  You can do arithmetic at the granularity of days
[02:19] <Kinnison> Y'know, I'm still unconvinced
[02:20] <Kinnison> consider how different the input is for the d-i stanzas
[02:20] <Kinnison> it'll be an ugly param list there anyway
[02:20] <sabdfl> jamesh: i think it might be easiest just to use datetimes, and use 8am for arrival, and 5pm for departure
[02:20] <sabdfl> jamesh: this is in support of your schedul-o-matic, anyhow ;-)
[02:21] <lifeless> actually, thats a question. why do you write one di component at a time, when you write all of them above ?
[02:21] <lifeless> thats probably the root of my confusion
[02:21] <Kinnison> because they're different tree {} stanzas in apt-ftparchive's config
[02:22] <Kinnison> check out /tmp/fileklVXM9 on mawson if you want to see an example
[02:22] <Kinnison> as elmo said, d-i is a "fucking bodge"
[02:22] <spiv> sabdfl: Hmm, wouldn't an second column, datekind, that is an enum of ARRIVAL_DATE or DEPARTURE_DATE be better than magic time components?
[02:22] <jamesh> sabdfl: that might be easiest.  If you just store dates, you'd need to assign some time of day to them before being able to tell if someone is available at a given time
[02:22] <lifeless> Kinnison: I belive you. ok, lets move on
[02:23] <lifeless> minor factor out:
[02:23] <lifeless> def safe_makedirs(path):
[02:23] <sabdfl> spiv: accurate times allow us to say "John is here till 1pm on Friday"
[02:24] <lifeless>   if not os.path.exists(path):
[02:24] <lifeless>         os.makedirs(path)
[02:24] <SteveA> sabdfl: that happens a lot with special guests
[02:24] <lifeless> will simpify the end
[02:24] <Kinnison> lifeless: *nod* I like that
[02:25] <sabdfl> SteveA: yup
[02:25] <lifeless> the di makdirs should be outside the arch list anyway
[02:25] <lifeless> as they dont use the arch variable
[02:25] <Kinnison> yep
[02:25] <Kinnison> that was an oopsie in indentation
[02:26] <spiv> sabdfl: ah, I thought you were proposing using something different (using 5pm to mean "the date component of this timestamp is a departure date"), rather than actually using the time.  That makes sense, then.
[02:26] <lifeless> this may be clearer:
[02:26] <lifeless> +                    if drfullname in self._di_release_components:
[02:26] <lifeless> +                        if comp in self._di_release_components[drfullname] :
[02:26] <lifeless> ->
[02:26] <Kinnison> lifeless: I've updated pub.txt
[02:26] <lifeless> if dr_fullname, componens in self._di_release_components.items():
[02:26] <lifeless>     if comp in components
[02:27] <Kinnison> lifeless: ergh
[02:27] <Kinnison> that would confuse the hell out of me
[02:27] <mdke> jordi, it might be a good idea to get yourself added as moderator for ubuntu-translators@lists too, for when carlos isn't here
[02:27] <Kinnison> magically instantiating the "components" bit in the if statement
[02:27] <Kinnison> (I assume)
[02:27] <lifeless> Kinnison: its a standard use of tuple expansion. what is confusin about ? 
[02:28] <Kinnison> lifeless: if it's standard for python programmers, and stevea says it's not confusing, I'll use it
[02:28] <Kinnison> it looks confusing to me
[02:28] <Kinnison> because I'd be looking above to see where 'components' came from and thusly what was I looking for in the dict
[02:28] <lifeless> Kinnison: hmm, I misread that, I was thinking for, not if
[02:28] <Kinnison> oh thank christ
[02:28] <SteveA> i'd put that one in explicit ()
[02:28] <Kinnison> I thought I'd got another reason to dislike python
[02:28] <lifeless> if (drfullname, comp) in self._di_release_components.items():
[02:29] <lifeless> that is the correct usage
[02:29] <Kinnison> eh?!
[02:29] <Kinnison> and that'll automatically do the "if comp in self._di_release_components[drfullname] " ?
[02:29] <spiv> lifeless: hmm, except it's O(n) not O(1).
[02:29] <lifeless> spiv: erk.
[02:29] <lifeless> .me twiddles fingers
[02:30] <lifeless> the code looks unneecessarily complex there
[02:30] <spiv> "if self._di_release_components.get(drfullname, None) == comp"?
[02:30] <spiv> Assuming comp cannot be None.
[02:30] <Kinnison> FFS, self._di_release_components[drfullname]  will be a *Set*
[02:30] <Kinnison> (or None)
[02:30] <lifeless> yes yes
[02:30] <Kinnison> not a component name
[02:30] <Kinnison> You're all confusing me a hell of a lot here
[02:30] <spiv> Kinnison: Er, right.
[02:30] <lifeless> lets move on
[02:31] <spiv> "if comp in self._di_release_components.get(drfullname, set())"
[02:31] <spiv> Kinnison: blame lifeless ;)
[02:31] <spiv> Kinnison: But I think two lines is still clear enough.
[02:31] <lifeless> [ os.path.join(
[02:31] <lifeless>                          self._config.distsroot,
[02:31] <lifeless>                          dr+pocketsuffix[pocket] ,
[02:31] <lifeless> -                        comp)
[02:31] <lifeless> that is used a couple of times too, factoring it would make it cleaner, and shut me up about the two if lines
[02:32] <Kinnison> okay
[02:32] <Kinnison> updated pub.txt
[02:32] <lifeless> def component_path(*args): return os.pth.join ...
[02:33] <lifeless> spiv: generally I do to, its just this thing is seriously opaque already, dont want it to get worse.
[02:34] <spiv> lifeless: Fair enough.  I didn't mean that to be comment on your reviewing; I don't have the context to do that :)
[02:34] <BjornT> stub: have you seen the process-mail.py failure?
[02:34] <lifeless> Kinnison: I'm happy enough now. There are still occasional foobar not foo_bar names
[02:34] <lifeless> Kinnison: if you audit your diff for those, I'm happy.
[02:34] <stub> BjornT: no
[02:34] <spiv> I was more meaning that I was tempted to go off and fiddle more with that expression, which would silly of me :)
[02:34] <Kinnison> lifeless: okay, I'll try and get as many of them as I can stomach
[02:35] <BjornT> stub: if fails with: ZConfig.ConfigurationSyntaxError: no values for 'buildd_download_url'; 1 required
[02:35] <BjornT> (line 164 in file:///srv/launchpad.net/production/launchpad/configs/production/launchpad.conf)
[02:35] <stub> ok
[02:35] <mpt> whoo
[02:35] <asmodai> yea
[02:36] <SteveA> lifeless: are you going to disable those particular CVS tests that are causing problems?
[02:36] <lifeless> SteveA: I don't known which specific ones are causing problems.
[02:37] <lifeless> SteveA: I'd rather just up the delay before the thing tries to connect TBH
[02:37] <SteveA> ok
[02:38] <SteveA>  ERROR: testAnwersOnce (CVS.tests.test_CVS.PServerHelperTest)
[02:38] <SteveA> that's one of them
[02:38] <SteveA> i can't find my reply from pqm with the full list of errors
[02:38] <SteveA> maybe i deleted it in disgust ;-0
[02:38] <SteveA> ;-)
[02:39] <lifeless> SteveA: so thats in the pserver tests, wthere are also virtual server usage in the main tests, its going to be ~= disableing most tests
[02:40] <SteveA> or upping the timeout on most tests
[02:41] <lifeless> right. upping the timeout is my preferred course of action
[02:41] <lifeless> ddaa: is there code to deal with '<<< no such revision >>>' in pybaz already ?
[02:42] <lifeless> ddaa: and how much breakage does archivelocations patch cause ?
[02:42] <ddaa> nah
[02:42] <lifeless> ddaa: lastly, is the archivelocations patch in pubic pybaz yet ?
[02:42] <ddaa> I do not understand your second question.
[02:42] <SteveA> lifeless: okay, so please up the timeout in those tests
[02:43] <lifeless> ddaa: what incompatabilities does the archivelocation pybaz patch inttroduce ?
[02:43] <lifeless> ddaa: can you please double the timeout used for the local-pserver startup?
[02:44] <ddaa> lifeless: [incompatibilities]  not much that I recall. The biggest issue was deprecation of all registered-name related things, that SteveA made me remove from the rocketfuel branch.
[02:44] <ddaa> mh...
[02:44] <ddaa> in the light of the new baz roadmap, I guess there's little point in having those deprecations in the public branch either
[02:46] <ddaa> [public]  yes it's there
[02:47] <ddaa> s/biggest issue that I recall/only issue that I recall/
[02:47] <ddaa> lifeless: I'll try to do the cscvs fixing once I managed to merge my nested-log patch. Which was rejected because of that exact problem.
[02:48] <lifeless> ddaa: please just do it today, its 10 minutes max.
[02:49] <ddaa> I thought that's what I said...
[02:49] <spiv> :q
[02:49] <lifeless> no, you said you'l do it after some other thing, which is AIUI after the samba fix in your pipeline
[02:50] <ddaa> the some other thing is actually merging the python fix
[02:50] <lifeless> ddaa: it may have been clear to you but it wants to me.
[02:51] <lifeless> ddaa: I asked for 'do X', and got 'sure, after Y' where 'Y' had no eta.
[02:51] <ddaa> okay, I guess I'm expecting you to carry too much state
[02:51] <lifeless> ddaa: I have no issue if you do it as after Y, but I want to keep steve et al happy, so I'm asking for anm ETA of X for today, irrespctive of the ta for Y
[02:51] <lifeless> s/ ta/ eta/
[02:52] <ddaa> So, short answer, yes.
[02:52] <lifeless> thanks
[02:53] <lifeless> I've just put a     *
[02:53] <lifeless>       robert.collins@canonical.com/pybaz--devel--0--patch-9
[02:53] <lifeless>           o
[02:53] <lifeless>             support for <<< no such revision >>> and !!!!nothing should depend on this.
[02:53] <lifeless>             needs-review [@DATE@] 
[02:53] <lifeless> review request up for pybaz code.
[02:54] <ddaa> Ack. How urgent is that? Today? Once I'm bored with the samba fix? Once I'm done with it?
[02:55] <lifeless> wjust letting you know, it will pass normal review process and then I'll land it, but I'll want it i nthe public branch too 
[02:55] <ddaa> I thought you requested a review.
[02:57] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: r=spiv new tests for some menu system functionality.  reorganisation of browser publication code. (patch-2408: steve.alexander@canonical.com)
[02:58] <lifeless> ddaa: yes, from the review team.
[02:58] <lifeless> ddaa: very happy for you to review it too.
[02:59] <ddaa> Oh, right. You are not requesting a review but you'd be happy for me to do one "If I have the time"... I'll try to.
[03:01] <SteveA> kiko-zzz: dude?
[03:02] <SteveA> BjornT, lifeless, salgado, jamesh, spiv
[03:02] <SteveA> reviewers team meeting on #canonical-meeting
[03:03] <SteveA> stub: you're invited too, as dba fascist
[03:16] <segfault> is there any problem with LP?
[03:17] <spiv> I'm getting 502 proxy error.
[03:17] <dilys> Merge to rocketfuel@canonical.com/cscvs--devel--1.0: [r=spiv]  nested log parsing, cleanups (patch-108: david.allouche@canonical.com)
[03:19] <Kinnison> ciao dudes
[03:21] <mdke> jordi, i have created a new pot from danilo's instructions, already it has twice the entries than the original one...
[03:22] <mdke> jordi, we're going to have to angry translators I think
[03:22] <ddaa> yay!
[03:26] <Kinnison> lifeless: Given that cprov has fixed all the stuff you pointed out in your review, can he now merge with r=lifeless? (You seem to have missed saying that bit)
[03:27] <lifeless> kiko-zzz:  said I was happy once pep8ificastion was audited by you
[03:27] <lifeless> kiko-zzz: oh, you mean his doc branch ? I'lll check the current diff
[03:29] <kiko-zzz> hey ho
[03:29] <lifeless> bzr branch of rocketfuel is now being uploaded to chinstrap:/home/warthogs/archives/rocketfuel-bzr-demo
[03:29] <kiko> sorry guys, had a lame morning
[03:29] <lifeless> you will need the symlink baz2bzr branch of bzr to pull this, its at people.ubuntu.com/~robertc/baz2.0/bzr-baz2bzr
[03:30] <lifeless> ITS NOT FINAL. warning warning warning alert alert alert danger will robinson
[03:30] <Kinnison> lifeless: I'm very confused. What is the status of the review of cprov's buildui branch?
[03:31] <lifeless> Kinnison: I sent a review to him and the list, then steve and I talked about one aspect of that reviw, and I have not heard from cprov since
[03:31] <Kinnison> cprov: status?
[03:31] <cprov> lifeless: will check
[03:32] <lifeless> https://chinstrap.ubuntu.com/~jamesh/pending-reviews/ - its in needs-reply
[03:32] <sabdfl> kiko: the distro boys are baying to LangPacks, what's the latest status?
[03:33] <lifeless> it currently has conflicts with rf
[03:34] <cprov> lifeless: Sep 12 8:08PM at LP-reviews lists, the reply is there
[03:34] <kiko> sabdfl, stuart did an overnight (for me) whitespace fix run, I need to generate a new pack to see
[03:34] <kiko> sabdfl, we can talk about this at the reviewer's meeting, but the whole lag is very frustrating -- I feel like I have my hands tied
[03:34] <kiko> s/reviewers/mgmt
[03:35] <kiko> stub, rock on -- has the script finished running?
[03:37] <spiv> lifeless: permission denied.
[03:38] <cprov> lifeless: moved the bits in the wiki page, but I don't believe you haven't seen the email ... anyway, it was my fault.
[03:39] <Keybuk> the ssssssh.py in Launchpad seems to be taking my stderr away and not giving it back
[03:43] <Kinnison> Keybuk: aye, it does that unless you exit non-zero
[03:44] <Keybuk> no, it exited non-zero and still hid stderr
[03:44] <Keybuk> :'(
[03:44] <Kinnison> oh :-(
[03:44] <Kinnison> sux
[03:44] <Keybuk> the "ZOPE CAN'T WRITE CONFORMANT C" error got hidden
[03:44] <Kinnison> yeah there is that
[03:44] <Kinnison> is this a launchpad-on-breezy issue?
[03:45] <Keybuk> yes
[03:45] <Kinnison> can we "fix" it by saying CC=gcc-3.4
[03:45] <lifeless> cprov: I hadn't, it was waay down my inbox in a thread
[03:45] <Kinnison> or are you on a mission to make it gcc4 compliant?
[03:45] <Keybuk> Kinnison: you can fix it by editing the C file and fixing the one bug
[03:45] <lifeless> cprov: I've replied - short answer, lastBuilds can too move.
[03:45] <Keybuk> niemeyer found it
[03:46] <Keybuk> a variable is declared both static and extern
[03:46] <Kinnison> wooyay
[03:46] <cprov> lifeless: again, sorry, it was really my fault ... thank you 
[03:47] <lifeless> np
[03:49] <stub> kiko: Yes, the script is finished (which is why the email said 'run' instead if 'is running')
[03:50] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  add table and classes for development manifests (patch-2409: mark.shuttleworth@canonical.com)
[03:51] <kiko> stub, yeah, I assumed so, just wanted to double-check because language can be oh so subtle
[03:52] <stub> You accusing me of being subtle?
[03:52] <kiko> stub, language is subtle. you're just australian
[03:53] <ddaa> lifeless: 100ms pserver spawn delay in cscvs on course
[03:53] <kiko> ddaa, aha
[03:54] <ddaa> kiko: just a band-aid, I think the proper fix would involve special casing so "connection refused" would cause "fast" retries only on tests...
[03:54] <ddaa> Not trivial by any mean.
[03:54] <lifeless> ddaa: thanks
[03:55] <ddaa> Crododile Dundee is my bible about .au subtlety :P
[03:56] <sabdfl> stub: another little landing on the way, sent mail, will you have a chance to look at it this evening? straightforward, i think
[03:57] <stub> I'll have a look
[04:02] <stub> sabdfl: Will you be converting walltimes for scheduling into utctimes for storage?
[04:02] <sabdfl> stub: faahrk
[04:02] <sabdfl> faahaaark
[04:02] <sabdfl> so yes, i guess so. jamesh, you prefer to store everything in UTC, right?
[04:03] <sabdfl> i mean, the db does anyway
[04:03] <stub> If we assume sprints are physical, and not virtual, there is a use case for storing them in localtime
[04:03] <stub> Are we going to have attendees via IRC? ;)
[04:04] <Kinnison> always store in UTC and translate for timezones (IMO)
[04:05] <dilys> Merge to rocketfuel@canonical.com/zope--test--3.0: Fix apidoc interface/class browser and GCC 4.0 fix (patch-19: stuart.bishop@canonical.com)
[04:05] <lifeless> only sane way
[04:05] <lifeless> oh, hello dilys, you're back
[04:06] <mpt> sabdfl: Why are "Edit Ticket", "Edit Priority and Assignee", and "Administer" separate pages? They partly intersect with each other, so I guess they're meant to be used by different people, but they all show up in the portlet for everyone
[04:06] <SteveA> stub: mailed you a test webserver that cancels connections when there's more than 3 pending
[04:06] <stub> lifeless: I can provide counter arguments, but in general I agree ;)
[04:07] <sabdfl> mpt: just trying a slight variation in style
[04:07] <stub> SteveA: I'll look at that tomorrow
[04:08] <sabdfl> some folks will get irritated at having to visit three pages if they want to change everything
[04:08] <stub> SteveA: I've sorted the current production issue anyway.
[04:08] <SteveA> stub: just stick the file in launchpad/lib/ and run it, then go to localhost:8080 and hit reload lots
[04:08] <sabdfl> but i'm guessing people will generally be touching one, or the other page
[04:08] <sabdfl> and then they will prefer tighter, more focused pages
[04:09] <SteveA> stub: can you check it works for you now?  should only take a moment.
[04:09] <stub> SteveA: Table statistics for some of the bigger tables had gotten out of date, so some of the scary queries where choosing really stoopid plans and running in glacial time.
[04:09] <mpt> sabdfl: There's only six fields in total involved here, so I doubt tightness is an issue really
[04:10] <SteveA> stub: does staging use teh same query plans as production?
[04:10] <stub> SteveA: It does when the table statistics are similar on both, which guided me to the real issue.
[04:13] <SteveA> https://chinstrap.ubuntu.com/~dsilvers/paste/fileYoiFDV.html
[04:13] <SteveA> stub, lifeless: this is what happens when you make a request that my zope.server additions will reject
[04:14] <SteveA> i could conceivably make it reject the connection earlier
[04:14] <SteveA> but it would be more work
[04:14] <SteveA> the current experiment is simple to make work with launchpad as it is now
[04:14] <SteveA> lifeless: i'm interested in getting your opinion on this
[04:15] <lifeless> if you want pound etc to think the host is down, it should not call accept()
[04:15] <kiko> stub, I have a question about the 503 page if I may
[04:15] <lifeless> (the host should not)
[04:15] <stub> sabdfl: In case you are bored, this is the log of queries executed to render a single one of the translation pages. There are rather a lot of queries... https://chinstrap.ubuntu.com/~dsilvers/paste/fileM78Eyf.html
[04:15] <kiko> stub, when the server is down, I've never seen this "launchpad is down page"
[04:16] <spiv> kiko: I have :)
[04:16] <SteveA> kiko: i saw it today
[04:16] <SteveA> it has to be a 503
[04:16] <SteveA> not a 504
[04:16] <stub> kiko: That is because you havn't seen the server down in the last week, which is about how long it has been installed
[04:16] <kiko> SteveA, spiv: why don't we see it when the server crashes?
[04:16] <SteveA> beacuse that is often a 504
[04:16] <spiv> Depends on how it's down.
[04:16] <kiko> stub, no, we saw it down yesterday
[04:16] <SteveA> it was a 504 yesterday
[04:16] <kiko> ah.
[04:16] <stub> Launchpad wasn't down, it was happily accepting connections...
[04:16] <SteveA> lifeless: so, i have to stop the connection at a lower level?
[04:16] <kiko> and there's no such thing as a 504 page, I imagine?
[04:17] <SteveA> i'm sure there is
[04:17] <SteveA> we'd just have to make one, and ask elmo to install it
[04:17] <SteveA> or ask him to use the same one... although "down for maintenance" would be untrue in that case
[04:17] <lifeless> SteveA: yah. IIRC we can leave the socket bound, and not call accept(), and then the proxy will see tcp fail and know to fail over
[04:18] <lifeless> so your accept loop needs a flag, if(!busy): faccept
[04:19] <spiv> s/do//
[04:19] <lifeless> from label: come [do something here.] 
[04:19] <spiv> lifeless: :)
[04:19] <lifeless> 5 points if you spot the language that was in
[04:20] <stub> Pound doesn't do 504
[04:20] <stub> But Apache probably does.
[04:20] <lifeless> pqm going down
[04:20] <lifeless> magic wand time
[04:20] <SteveA> spiv: would be easy if zope3 used twisted already.  sadly, doesn't
[04:21] <spiv> Yeah.  (Not that it's clearly documented how to do this with Twisted... just that I happen to know the trick)
[04:22] <lifeless> the issue is, once yyou call accept() the 3-way handshake has been shook
[04:22] <SteveA> i think i see where i need to do this
[04:22] <lifeless> and your load balancer now has to deetect application level errors, not tcp errors.
[04:22] <lifeless> IIRC squid does app level errors :)
[04:23] <SteveA> stub: i'll send you a new version in a few minutes
[04:30] <stub> SteveA: With that version I'm getting a 500 error
[04:30] <SteveA> is that good?
[04:31] <ddaa> lifeless: what is the trick to make "cscvs log" work with svn checkouts?
[04:31] <SteveA> i can easily make it explicitly give a particular error
[04:31] <lifeless> ddaa: erm, cscvs -d :pserver:ficticious@home log 
[04:32] <ddaa> bwahaha
[04:32] <stub> SteveA: It means the load balancer thinks it is still up and running
[04:32] <lifeless> SteveA: as I sexpected
[04:32] <stub> SteveA: Which isn't good, if only one of the backends is screwed
[04:32] <SteveA> ok
[04:33] <stub> Ahem
[04:34] <ddaa> lifeless: SCM.NotAWorkingTree: Path is not a CVS working directory
[04:34] <ddaa> I mean, I know it's not a CVS working tree, it's a SVN one...
[04:34] <ddaa> okay, I guess the answer is "you don't"
[04:35] <lifeless> ddaa: hmm, it *should* be able to work, but anway, I use svn log as it good enough
[04:35] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Make publisher aware of d-i. Fix up some non-PEP8ish code along the way. Make sure overrides are pocket aware. r=lifeless (patch-2410: daniel.silverstone@canonical.com)
[04:36] <mdke> jordi, around?
[04:36] <SteveA> stub: there's an argument to socket.listen() which is the "backlog"
[04:37] <SteveA> that is the max number of queued connections
[04:37] <SteveA> maybe reducing that would work
[04:37] <lifeless> SteveA: what is your bavcklog set to ?
[04:37] <SteveA> 1024
[04:37] <lifeless> jesus
[04:37] <ddaa> lifeless: I you recall what it is that needs to be fixed for samba, I'd appreciate some refreshing. I sort of remember I must do something just like DeletedAdapter but the other way around, maybe for nested adds whatever that means, but I'm a bit at a loss.
[04:37] <SteveA> we have two things: one is the backlog.  the other is the number of queued tasks.  these are of course related
[04:37] <lifeless> how many threads to we have? 4 ?
[04:38] <SteveA> maybe just reducing the backlog will be enough.
[04:38] <stub> 4 by default, and I think an upper limit of 7 still
[04:38] <lifeless> if we have 4 threads, I would suggset a backlog of 40
[04:38] <SteveA>     # Stop accepting new connections if too many are already active.
[04:38] <SteveA>     connection_limit = maxsockets.max_select_sockets() - 3  # Safe
[04:38] <SteveA> aha
[04:38] <SteveA> so, there is a connection_limit too
[04:38] <SteveA> don't know if it is used or not, though
[04:39] <SteveA> yep, it ought to be
[04:40] <SteveA> so, we can probably do it by changing backlog and connection_limit
[04:43] <SteveA> connection_limit is 97 on my machine
[04:44] <lifeless> 97 is _way_ to high for something that does synchronous service on 4 requests at once
[04:45] <lifeless> theres incredibly little point in having more than 8 connections if you do 4 things ar once.
[04:46] <lifeless> ddaa: adds of a dir that have a copyfrom_revision set need to to a recursive copy
[04:46] <lifeless> i.e the inverse of deleted adapter
[04:47] <ddaa> mhr, right what I recall
[04:47] <ddaa> thx
[04:48] <stub> SteveA: if connection limit works, could be worth defaulting it to 4*threads upstream (assuming there isn't already a config item to set it...)
[04:48] <SteveA> i'm going to add some config items for these
[04:48] <stub> (or 10* as per robs suggestion)
[04:49] <SteveA> but, i'm still trying to get them to show the desired behaviour
[04:49] <stub> Bed!
[05:12] <jordi> mdke: yeah
[05:12] <jordi> mdke: I'm following this discussion..
[05:12] <jordi> hm
[05:14] <bradb> mpt: http://69.70.209.33:8086/products/ubuntu/+bug/1
[05:14] <bradb> mpt: spot the demystification in under 5 seconds.
[05:14] <mdke> jordi, i wanted your opinion on the question of how many translations will get lost, and how many might be kept
[05:15] <jordi> mdke: did many translate the huge line?
[05:15] <mdke> jordi, if the msgid string is exactly the same, but with a different comment, will the existing translation be kept, or lost?
[05:15] <jordi> or lines?
[05:15] <jordi> kept
[05:15] <mdke> ok then we should be good to go
[05:15] <jordi> comments are not taken into account when merging.
[05:16] <mdke> great
[05:16] <mdke> so, I think that we can consider uploading the new pot
[05:17] <mdke> jordi, the only question is whether to merge the original into one file first, or to do it later
[05:17] <mpt> SteveA: fyi, I added a couple of problems (that might be the same problem) to LaunchpadMenusInProgress
[05:18] <SteveA> okay, cool
[05:18] <jordi> mdke: if xml2po will handle a well formed file with xincludes, I would do different xml files, for manageability
[05:18] <jordi> mdke: but would of course generate just one pot file.
[05:18] <jordi> mdke: the GNOME docs are like this and they work ok.
[05:18] <jordi> mdke: if you want help with setting up makefiles, we can have a look too.
[05:18] <mpt> bradb: whoa
[05:18] <mdke> jordi, yeah, it's just a question of whether we can get different xml files back from the translations
[05:19] <mpt> bradb: Tony Robbins would love that page, it has a Massive Actions portlet :-)
[05:19] <mdke> there's not much point having different xml files for the original and single ones for the translations
[05:20] <bradb> mpt: massive? heh, it's a mini portlet compared to, say, the person page.
[05:20] <mpt> true, but more of them here are multiple lines
[05:21] <mpt> maybe that's just my minimum font size talking
[05:21] <bradb> but it's big. it's also got useful links, and it's been observed then when users want to do something, they quickly adapt to always looking in that space to find the golden path
[05:22] <jordi> mdke: gnome release notes have 10 xml files, the process generates 1 though.
[05:22] <mpt> maybe, but adaptable != pleasant
[05:22] <jordi> It may still be useful to have your sources in multiple, but distribute the final, single doc.
[05:22] <mpt> It's still daft that subscribing is on the opposite side of the page from the list of subscribers
[05:22] <mpt> bradb: What's that "Subscribe someone else" for?
[05:23] <bradb> mpt: Indeed it is. Maybe at some point we'll be able to sell the idea of putting links in logical, easy to trip over (in a good way) places.
[05:23] <jordi> mdke: scratch that for a minute
[05:23] <bradb> mpt: To Cc someone else on the bug report. I believe sabdfl was the one that tweaked those bits.
[05:23] <jordi> totally wrong
[05:25] <jordi> mdke: 10 source xml files, 10 output xml files for each language.
[05:25] <bradb> I believe this last tweak will significantly reduce the repeated (and well-merited, I might add) whining about not being able to figure out how to assign a bug.
[05:25] <jordi> mdke: so way to go
[05:26] <mdke> hmm
[05:26] <mdke> jordi, just a question of whether we can do that too
[05:27] <sabdfl> salgado, kiko: the "preserve edit message" landing, does that use the general mechanism we described in Brazil?
[05:27] <jordi> yeah?
[05:27] <salgado> sabdfl, "preserve edit message"?
[05:28] <sabdfl> yes
[05:28] <sabdfl> Fix the person-edit view to preserve the message displayed by the edit view when we redirect to their new canonical_url (as a consequence of a name change). r=kiko'
[05:28] <bradb> mpt: There are various ways we can pull stuff out of the actions portlet though. e.g. [Edit]  link beside the description (afterall, you decide to edit a description when you're looking at the description, more-than-likely); same principle with "secrecy", subscriptions (which is a portlet that should always be present, I think), we can drop adding web links, etc.
[05:28] <sabdfl> is that done without a tacky ?message=Your%20Edit%20Message url?
[05:28] <salgado> sabdfl, ah, no. AFAICT that mechanism is not yet implemented
[05:29] <sabdfl> bradb, mpt: the main way to pull stuff out of the actions portlet is to get the menu system implemented. please stuff everything in the actions portlet until menu systems are done
[05:29] <salgado> so, yes, it does use a special GET parameter, but the message is not in the GET itself
[05:29] <sabdfl> don't spend any effort trying to optimise the actions portlet, which is obsoleted by the menu system
[05:29] <bradb> sabdfl: yep, i'm stuffing everything in there: http://69.70.209.33:8086/products/ubuntu/+bug/1
[05:30] <sabdfl> we wanted menu systems in before UDU, I will BREAK BALLS IN MONTREAL if it's not done by the time our session starts there
[05:30] <sabdfl> bradb: good man
[05:30] <sabdfl> errr
[05:30] <sabdfl> special get parameter?
[05:31] <salgado> just an ?updated=date
[05:35] <SteveA> sabdfl: stu is working on the messages stuff
[05:36] <sabdfl> salgado: that's rather minor bling, and we have a general mechanism on the way, so let's not do that anywhere else?
[05:37] <salgado> sabdfl, you mean, simply redirect without any message until we have the mechanism implemented?
[05:41] <sabdfl> salgado: yes please
[05:41] <sabdfl> bradb: you'll like the new FormView
[05:42] <sabdfl> it's under review, will hopefully land tomorrow
[05:42] <sabdfl> pending my hearing back from jamesh ;-)
[05:42] <bradb> sabdfl: It's got some support for notices?
[05:43] <sabdfl> bradb: yes
[05:43] <sabdfl> more importantly, its a simpler and more flexible thing than addform
[05:44] <sabdfl> and with some tweaks it could improve editform too (just need to figure out how to pre-set the fields)
[05:45] <bradb> sabdfl: I think setUpWidgets knows how to init edit fields.
[05:46] <bradb> Unless you were referring to something else.
[05:51] <jordi> sabdfl: do you know by chance what needs to be done with those "dont-use" or "breezy-review" pots in rosetta?
[05:51] <jordi> ie, what do I need to do exactly to "fix" them? I don't want to fuckup.
[05:51] <sabdfl> bradb: the problem is that an editform assumes that you are editing the context
[05:52] <sabdfl> i want to be a bit more relaxed than that
[05:52] <sabdfl> editforms, so far, are ok, so i'm leaving it as it is for the moment
[05:52] <sabdfl> jordi: i don't know. i think there is a "hide" checkbox somewhere. BUT, the real solution is not to import them in the first place
[05:53] <sabdfl> i'll want carlos to address that first thing when he's back
[05:53] <sabdfl> because those damn things are building up
[05:53] <bradb> sabdfl: right. i look forward to being liberated from browser:addform, at least. :)
[05:53] <sabdfl> bradb: the new form is a good replacement for addform, yes
[05:54] <jordi> sabdfl: yeah :(
[05:54] <jordi> sabdfl: so should I hold this until next week?
[05:54] <sabdfl> jordi: yes
[05:54] <sabdfl> it would be possible to put "DO NOT USE THIS" on the description of each of them, but i don't think it's worth doing that
[05:55] <jordi> ok. I'll do some email processing and FAQ work
[05:56] <jordi> I think mdke has the faqguide problem under control now. That was worrying for a moment, but it boiled down to a not so well formed xml
[05:56] <kiko> gool
[05:56] <dilys> Merge to rocketfuel@canonical.com/cscvs--devel--1.0: [trivial]  wait for local psever to spawn for 100ms (patch-109: david.allouche@canonical.com)
[06:15] <bradb> woohoo, stub's form error message thing seems pretty straightforward
[06:19] <SteveA> bradb: it's implemented already?
[06:19] <SteveA> i didn't see it land
[06:21] <kiko> me neither
[06:22] <SteveA> mpt: ping
[06:23] <Kinnison> elmo: ping?
[06:27] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Fix the person-edit view to preserve the message displayed by the edit view when we redirect to their new canonical_url (as a consequence of a name change). r=kiko (patch-2411)
[06:28] <Kinnison> SteveA: what's the best way to get "now" formatted as a string in UTC in python?
[06:28] <Kinnison> SteveA: this is independant of the database
[06:28] <SteveA> now is what?
[06:28] <SteveA> a time
[06:28] <SteveA> a datetime?
[06:29] <SteveA> import datetime ; datetime.datetime.utcnow().strftime('....')
[06:29] <SteveA> >>> datetime.datetime.utcnow().isoformat()
[06:29] <SteveA> '2005-09-14T16:29:16.310295'
[06:29] <salgado> elmo, around?
[06:29] <SteveA> >>> datetime.datetime.utcnow().ctime()
[06:29] <SteveA> 'Wed Sep 14 16:29:33 2005'
[06:29] <Kinnison> """Date: Fri, 13 May 2005 12:42:31 UTC"""
[06:29] <Kinnison> I want that format
[06:30] <Kinnison> I can obviously shove the 'Date: ' on the front myself
[06:30] <SteveA> http://docs.python.org/lib/module-time.html
[06:31] <SteveA> >>> datetime.datetime.utcnow().strftime('Date: %a, %d %b')
[06:31] <SteveA> there's the first part
[06:31] <Kinnison> ta
[06:33] <Kinnison> Now all I need is to work out how to do a buggerload of md5sums and sha1sums and how to format things like I would in perl using a format string
[06:55] <SteveA> bradb: ping
[06:56] <SteveA> BjornT: ping
[06:56] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Use a different <form> for adding a new email address in a person's email address page. Fix https://launchpad.ubuntu.com/malone/bugs/1348. (patch-2412)
[06:57] <SteveA> brad filed this bug: https://launchpad.net/malone/bugs/1515   i want to know if it is still an issue, as written, or if it needs updating
[06:58] <Kinnison> alright, who is sending empty merges into pqm?
[06:58] <Kinnison> and why haven't we modified check_merge to spot these and error out?
[07:00] <SteveA> maybe someone isn't mirroring, and is using tree-version rather than tree-id in their submit script
[07:00] <cprov> Kinnison: it's probably related to a non mirrored change ..
[07:00] <cprov> ;)
[07:01] <Kinnison> indeed, but even so, surely it's easy to spot?
[07:01] <SteveA> in what script?
[07:02] <Kinnison> how about in the check_merge target of the top level makefile
[07:03] <SteveA> isn't it too late by then?
[07:03] <SteveA> i mean, the merge has already taken place
[07:03] <mpt> SteveA: pong
[07:03] <SteveA> hi
[07:04] <cprov> mpt: let me know when you have 10 min for help me with some facets issues in builddUI
[07:29] <bradb> SteveA: pong. yes, it's landed (i saw it land, i also tried it out before going for lunch). as for 1515, I don't know whether or not it's still an issue, because I haven't looked at Malone menu code since before brazil.
[07:48] <Kinnison> ciao, dinner time
[07:48] <cprov> Kinnison: see you
[07:48] <mdke> jordi, got the new pot ready. shall I upload it straight away or do you want to have a quick look?
[07:53] <SteveA> mp1: network back?
[07:54] <cprov> SteveA: it is ...
[07:54] <mpt> SteveA: yup
[08:25] <mdke> jordi, uploading, fingers crossed
[08:26] <SteveA> mpt: i'm off home shortly.  can you mail me details of the branch, or patch or whatever for those person menus we discussed?
[08:26] <bradb> BjornT: Do you think you'll have a chance to review the URL change patch tomorrow?
[08:26] <SteveA> i'll continue work on that tomorrow morning.
[08:27] <mpt> SteveA: ok
[08:27] <mdke> jordi, eureka
[08:31] <BjornT> bradb: don't know. i'll definitely dedicate some time tomorrow for reviewing it, but i'm not sure that i will be able to review all of it.
[08:31] <bradb> BjornT: ok, thanks
[08:31] <bradb> I'm working on a branch that's branch off of it atm, to improve our failure modes in forms and such.
[08:31] <bradb> s/branch off/branched off/
[08:32] <jordi> mdke: that's great
[08:32] <BjornT> cool
[08:33] <mdke> jordi, looks like the translations have not been lost
[08:33] <mdke> jordi, thanks very much indeed for your help
[08:35] <jordi> mdke: no worries!
[08:35] <jordi> mdke: used -e?
[08:36] <mdke> yes
[08:36] <WaterSevenUb> mdke, https://launchpad.net/distros/ubuntu/breezy/+sources/ubuntu-docs/+pots/faqguide/pt/+translate?offset=210 
[08:37] <WaterSevenUb> mdke, excellent... these big lines though :)
[08:37] <WaterSevenUb> mdke, great job! ;)
[08:37] <mdke> big lines?
[08:38] <WaterSevenUb> mdke, a little detail... they don't fit in the screen ... something completely different.. nevermind :)
[08:38] <mdke> gah, that can't be my fault
[08:38] <mdke> blame jordi 
[08:38] <WaterSevenUb> mdke, eheh
[08:48] <kiko> SteveA, as for your question, salgado has tested the email locally but not in production or staging
[08:48] <kiko> staging doesn't send email
[08:48] <kiko> production...
[08:48] <kiko> there are tests for it in the code though
[08:49] <salgado> we can test it in production now
[08:50] <kiko> ah, /shipit
[08:50] <salgado> kiko, shhhhhh
[08:55] <kiko> :)
[09:20] <kiko> jordi?
[09:22] <sabdfl> kiko: pong
[09:23] <kiko> sabdfl, did you ever give elmo his gift? :)
[09:23] <lifeless> later all
[09:23] <kiko> laters lifeless 
[09:39] <salgado> sabdfl, should we have a separate ShippingAddress table (as stub suggested) or should we put the addresses in the ShippingRequest table?
[09:49] <cprov> PQM seems to be stalled, processing my job for 1,5 hours
[09:50] <elmo> it's doing stuff
[09:50] <elmo> pqm      10134 40.8  1.8 112584 68780 ?        R    20:41   3:25                  \_ /usr/bin/python2.4 test.py -vv --dir hct --dir sourcerer
[09:52] <cprov> elmo: ok, thank you for looking, let's wait 
[10:07] <sabdfl> salgado: it's fine where it is for the moment
[10:07] <sabdfl> kiko: doh
[10:07] <sabdfl> now i need to find them
[10:11] <salgado> sabdfl, we need to allow Marilize to place new orders for people which she doesn't have an email address, and thus we can't create a person for these requests. Jane said this is a real use case and we need to implement it soon
[10:12] <sabdfl> salgado: we do not require an email address for a user in LP
[10:12] <kiko> sabdfl, stub has reservations to adding dummy users to launchpad
[10:13] <sabdfl> kiko: they would be real users with real names, would they not?
[10:13] <kiko> there is also the issue of supporting users that want to request to multiple addresses
[10:13] <kiko> sabdfl, I don't think so -- think S-n-A.
[10:13] <kiko> do you really have names for all the recipients?
[10:13] <sabdfl> mm... The Manager, Foo Bar Internet Cafe
[10:13] <kiko> and by name I mean "George T. Washington" not "New Delhi Computer Outlet"
[10:13] <sabdfl> i guess not...
[10:14] <sabdfl> so who logs in to request another order?
[10:14] <kiko> It appears to me that it's a lot cleaner to decouple addresses from people
[10:14] <kiko> shipit admins can generate requests as well
[10:14] <kiko> the data model would allow for the shipment to indicate a recipient name
[10:15] <kiko> and thus not using the name of the person who created it.
[10:15] <kiko> otoh we could also just piggyback request and add address information there
[10:15] <kiko> there is little difference between the two models
[10:16] <sabdfl> yes there is
[10:16] <kiko> (if using a separate shippingaddress table, users' edits to it will be used in non-exported shipments, otherwise, it's fire-n-forget)
[10:16] <sabdfl> followon requests should be tied to the same address
[10:16] <kiko> there is difference
[10:16] <kiko> oh
[10:16] <kiko> sorry
[10:16] <kiko> I was incomplete
[10:17] <kiko> person would have address information -- and we'd copy that into a shippingrequest when placed.
[10:17] <kiko> that's the other alternative
[10:19] <kiko> the disadvantage is that it duplicates information
[10:19] <kiko> preferences, sabdfl?
[10:20] <sabdfl> if we leave address in person, and copy over, how does that decouple requests from people?
[10:20] <sabdfl> do we just allow the person to be NULL?
[10:20] <sabdfl> and have a mechanism to create the person if they come back with their token?
[10:20] <kiko> right
[10:20] <kiko> that's precisely what stuart suggested, too
[10:21] <kiko> he reckons few people are actually going to validate their tokens, which means that most users will just be used as a hanger for address information.
[10:21] <kiko> I can't say I disagree
[10:22] <kiko> I mean, salgado and I don't /want/ to change the data model, but acknowledge it's the right thing to do
[10:23] <sabdfl> ok
[10:23] <sabdfl> then put the address in the shippingrequest
[10:24] <sabdfl> leave address details in the person record
[10:24] <sabdfl> we can copy it there for defaults if the person has filled it in, and comes back
[10:24] <sabdfl> other way around
[10:24] <sabdfl> we can copy from person to shipping request if they come back to make a new shipping request
[10:24] <sabdfl> amazon allows you to add  addresses
[10:24] <sabdfl> and then select one for each order
[10:24] <sabdfl> but we don't want to get that fancy
[10:25] <kiko> okay
[10:25] <sabdfl> good call, stub
[10:25] <kiko> I think you're right -- it's the simpler solution.
[10:26] <sabdfl> and it's easy to refactor that later
[10:26] <kiko> well, it involves some cut-n-pastage of data
[10:27] <sabdfl> they are two different bits of data
[10:27] <sabdfl> one is "my current address"
[10:27] <sabdfl> the other is "the address of this shipping request"
[10:27] <sabdfl> it's not a badness to have it in both places, in this case
[10:27] <kiko> yes
[10:27] <kiko> agreed, entirely
[10:28] <kiko> I was just saying that if you want to move to having multiple addresses per person, it involves moving the address out of person. but anyway..
[10:28] <sabdfl> well, not even
[10:28] <sabdfl> maybe
[10:28] <sabdfl> cross that bridge when we get to it
[10:28] <kiko> right
[10:31] <salgado> we would need to have a displayname together with the address (in the shippingrequest table), so Marilize can place orders for other people (not S-n-A). otherwise all requests would be sent with Marilize's name. either we do that or we'll be creating person objects for this people?
[10:34] <kiko> salgado, the former -- a displayname with the address
[10:34] <kiko> it appears to be the best way to handle this
[10:34] <salgado> that's what I think too
[10:34] <kiko> you might get smart and make the code pull owner.displayname when displayname is NULL, but..
[10:43] <sabdfl> jamesh: ping
[10:55] <sabdfl> salgado: make the shipping address have a .addressee attribute, which looks at a local field, or person.browsername
[11:00] <salgado> sabdfl, yeah, that will make life easier for client code