[12:06] <segfault> jordi: pong
[12:07] <lifeless> LarstiQ: dunno
[12:09] <LarstiQ> lifeless: ok, I'll see if I can find some documentation
[12:14] <LarstiQ> https://wiki.launchpad.canonical.com/BranchActivityVisualization is the closest I get to having activity explained
[12:26] <lifeless> LarstiQ: yah, but thats not per product :)
[12:27] <LarstiQ> lifeless: right, and I also found activity reports on https://wiki.launchpad.canonical.com/LaunchpadTeamFAQ. Completely different, although interesting.
[12:27] <lifeless> :)
[12:27] <lifeless> you can see one of those in the bzr list archives
[12:28] <LarstiQ> lifeless: yes, I remember that one
[12:28] <LarstiQ> and Martin's reaction to it ;)
[12:42] <jordi> segfault: we need to talk. There are way too many split files. Maybe we can do something.
[12:51] <segfault> jordi: sure! can you tell me how? :)
[12:59] <carlos> jordi, yes, one potemplate can be moved from the +admin page but only by you or any Rosetta admin
[01:01] <carlos> night!
[01:01] <Kinnison> night carlos
[01:07] <Kinnison> What's the right way to flush the sqlobject cache?
[01:07] <Kinnison> and subsequently what's the right way to get python to GC the objects?
[01:08] <Kinnison> This is actually kinda important I think
[01:10] <spiv> Kinnison: flush_database_caches from canonical.database.sqlbase
[01:11] <spiv> Kinnison: Although, can you explain a little more about why you need this?
[01:11] <spiv> And why do you care about when objects are GCed?
[01:11] <Kinnison> spiv: because the domination in the publisher uses ca. 900M *per distrorelease*
[01:11] <Kinnison> 900M of sodding sqlobjects
[01:12] <Kinnison> hmm, perhaps 600M
[01:12] <Kinnison> No, 900
[01:12] <spiv> Ok.  To get Python to GC objects, just make sure you don't have any references to objects you don't need.
[01:12] <spiv> And don't define __del__ :)
[01:12] <Kinnison> so flushing the db cache should do the trick?
[01:12] <Kinnison> and python will gc merrily from there?
[01:12] <spiv> Perhaps.
[01:12] <spiv> Depends on if you have any other references to them :)
[01:13] <Kinnison> well, I'm not keeping 'em around
[01:13] <Kinnison> if there are cycles what will python do?
[01:13] <spiv> It will merrily collect them.
[01:13] <Kinnison> good, I know perl won't
[01:13] <Kinnison> because it's shit
[01:13] <spiv> *Unless* you have __del__, in which case they'll probably end up in gc.garbage instead.
[01:13] <Kinnison> do sqlobjects have __del__ ?
[01:14] <spiv> Nope.
[01:15] <spiv> SQLObject does define it on connections iirc, but that shouldn't matter.
[01:15] <spiv> Btw, how do you know that that 900MB is sqlobjects?
[01:16] <Kinnison> Well, I'm assuming it is
[01:16] <spiv> Ah :)
[01:16] <spiv> You're probably right.
[01:16] <Kinnison> because if it's not, I don't see what it can be
[01:16] <Kinnison> since the code is essentially
[01:16] <spiv> But just to make sure, take a look at http://twistedmatrix.com/users/spiv/countrefs.py
[01:16] <Kinnison> for some_sql_object in gigantic_select_result:
[01:16] <Kinnison>    do_stuff(some_sql_object)
[01:17] <SteveA> spiv: we'd need to totally stop the sqlobject cache from running i think
[01:17] <Kinnison> it's too scary
[01:17] <spiv> SteveA: That may be possible.
[01:18] <spiv> Kinnison: Also, if flushing the cache is inadequate, gc.get_referrers(some_object_I_thought_should_be_gced) may be helpful.
[01:18] <Kinnison> spiv: doesn't that kinda imply keeping a reference to it to check?
[01:18] <spiv> Kinnison: Well, that's the trick ;)
[01:19] <spiv> Kinnison: Either find the object the same way countrefs.py does (by crawling over gc.get_objects()), or keep a weakref to an object you suspect isn't gc'd.
[01:20] <spiv> You can force a gc run with gc.collect(), btw, but that's almost certain to make no difference -- by default it runs pretty frequently already.
[01:22] <Kinnison> Okay, a distrorelease is actually taking closer to 1.2G
[01:27] <Kinnison> b
[01:28] <Nafallo> Kinnison: tired? :-)
[01:29] <Kinnison> annoyed with sqlobject mostly
[01:29] <Nafallo> oki
[01:29] <Kinnison> takes it ages to flush its cache and that in itself doesn't appear to have helped a great deal
[01:30] <Kinnison> In fact, regardless of how much sqlobjects there are, it really seems to hammer the cache
[01:30] <Kinnison> I.E. taking upwards of 30 CPU seconds to empty a cache of the security pocket's sources
[01:30] <Kinnison> this is bad
[01:31] <spiv> Kinnison: in theory adding cache=False to the connectionURI for the database should help.
[01:31] <Nafallo> that does not sound healthy indeed
[01:31] <Kinnison> spiv: how do I do that?
[01:31] <spiv> But that code appears to be buggy.  Hmm.
[01:31] <Kinnison> txn = initZopeless( dbuser='lucille' ) 
[01:31] <spiv> Kinnison: by abusing dbname ;)
[01:31] <spiv> But let's not do that.
[01:32] <Kinnison> Why would flushing the cache take so long?
[01:32] <Kinnison> unless it's not really flushing the cache and is just calling .sync() on all the objects in it
[01:33] <Kinnison> argh
[01:33] <Kinnison> that's exactly what it's doing
[01:33] <Kinnison> useless
[01:34] <spiv> Kinnison: try "Person._connection.cache.kw['cache']  = False" at the very start of your transaction.
[01:35] <spiv> (s/Person/any convenient sqlobject/ if you like)
[01:35] <Kinnison> AttributeError: 'NullCache' object has no attribute 'kw'
[01:36] <spiv> Hah.
[01:38] <Kinnison> very odd
[01:43] <spiv> Kinnison: Hmm.
[01:43] <spiv> Kinnison: If you're seeing a NullCache, you must be doing that too soon.
[01:44] <spiv> Kinnison: Are you using zopeless? with or without implicitBegin?
[01:46] <user__> Ahoy
[01:46] <Kinnison> zopeless with
[01:48] <spiv> Kinnison: Odd.   And yet Person._connection is a NullConnection?
[01:50] <Kinnison> spiv: not entirely sure
[01:50] <Kinnison> I think .cache was a NullCache
[01:50] <Kinnison> calling SQLBase.flush_database_updates()
[01:50] <Kinnison> then SQLBase._clearCache()
[01:50] <Kinnison> then gc.collect()
[01:50] <Kinnison> keeps the RAM usage at a steady half-gig
[01:50] <spiv> Which is still huge.
[01:50] <Kinnison> instead of climbing into the 3.5g range
[01:51] <Kinnison> each gc.collect() is collecting ca 200,000 objects
[01:51] <spiv> Also, _clearCache is always called when you start a new transaction.
[01:51] <Kinnison> this is mid-transaction
[01:51] <spiv> Ah.
[01:51] <Kinnison> I already had some txn.commit()s in there
[01:51] <Kinnison> which reduced it from >4G==explode to 3.5G==goslow
[01:52] <Kinnison> DEBUG:Dominator:Performing domination across hoary/Release (i386)
[01:52] <Kinnison> DEBUG:Dominator:Sorting binaries...
[01:52] <Kinnison> DEBUG:Dominator:Dominating binaries...
[01:52] <Kinnison> DEBUG:Dominator:Flushing SQLObject cache.
[01:52] <Kinnison> DEBUG:Dominator:GC.Collect()
[01:52] <Kinnison> DEBUG:Dominator:Returned: 244005
[01:52] <Kinnison> yay for sqlobject
[01:52] <spiv> The right answer is to set the cache=False on the Cache.
[01:52] <Kinnison> but that'll make each domination much slower
[01:52] <Kinnison> won't it?
[01:52] <spiv> Well, maybe.
[01:52] <spiv> Maybe not.
[01:52] <spiv> It still keeps weakrefs.
[01:53] <spiv> So depending on other code, it may still be able to return the objects.
[01:53] <spiv> And how often are your queries returning the same object, anyway?
[01:53] <Kinnison> foo.bar
[01:54] <spiv> But it's very weird that you're getting a NullCache, but that _clearCache works.
[01:54] <spiv> Because they're accessing the same attribute.
[01:54] <spiv> I guess try s/Person/SQLBase/ to narrow it down.
[01:55] <spiv> Hmm, or do an explicit txn.begin(), perhaps...
[01:56] <Kinnison> for now
[01:56] <Kinnison> we can look at it together in montreal
[01:58] <spiv> Ok.
[01:58] <spiv> I would like to understand what's going on here.
[01:59] <spiv> So I'll corner you in Montreal.
[02:00] <Kinnison> cool
[02:00] <Kinnison> in the meantime, for the first time in days, a publisher run on staging will complete
[02:00] <spiv> 500MB is still huge, though.
[02:01] <spiv> We'll figure it out in Montreal... there are a couple too many mysteries here :)
[02:01] <Kinnison> aye
[02:01] <Kinnison> almost certainly all my fault
[02:31] <Kinnison> Hmm, 11 minutes to do a full publishing run now
[02:31] <Kinnison> much better than before
[02:57] <Kinnison> hey stubbaroony
[03:46] <Kinnison> ciao all
[10:14] <BjornT> stub: is production running a baz branch? that is, if i want you to cherry pick something, should i branch off the production branch?
[10:14] <stub> BjornT: production is currently running a baz branch
[10:15] <BjornT> stub: which branch?
[10:15] <stub> launchpad--production--1.38
[10:41] <BjornT> stub: when adding some sample data and running make newsampledata, i get >1Mb diff... any ideas of what could be wrong?
[10:42] <stub> I've seen that happen before. No idea why it does that. IIRC newsampledata is supposed to be doing some sorting to minimize that sort of stuff.
[10:43] <carlos> BjornT, usually it implies new fields additions 
[10:43] <carlos> BjornT, someone added new fields but no new sampledata was added so with your export you update those tables
[10:45] <BjornT> carlos: no, that's not it
[10:46] <carlos> BjornT, then there are two more options
[10:46] <BjornT> it seems like make newsampledata decided that all tables should be in alphabetical order, which wasn't the case before
[10:46] <carlos> 1.- If the diff has case changes, someone did a manual addition to the sampledata (IMHO is a bad way to add it)
[10:46] <carlos> oh
[10:46] <carlos> that's new
[11:30] <zyga> carlos: hi
[11:30] <zyga> carlos: I've created #ubuntu-hardware, who should I contact to put this into topic line at #ubuntu
[11:30] <carlos> zyga, don't know, perhaps jdub
[11:31] <zyga> carlos: thanks, I'll try
[12:04] <cprov> morning guys
[12:35] <Kinnison> Who here is going to UBZ flying tomorrow on BA95 from LHR->YUL 17:25 -> 19:25 ?
[01:00] <BjornT> stub: sent you a cherry pick request
[01:06] <matsubara> good morning!
[01:09] <Kinnison> Okay, so I have a bzr branch of launchpad
[01:09] <Kinnison> I've done some work in it
[01:09] <Kinnison> and I want to push those changes to chinstrap
[01:09] <Kinnison> how do I do that?
[01:12] <siretart> hi
[01:13] <siretart> I've sent a feature request for being able to close malone bugs via debian/changelog, but havn't heard any response yet :( - did you overlook me or is this way to hard to implement or way to low priority?
[01:14] <Kinnison> It's currently low priority I imagine
[01:14] <Kinnison> We'll certainly be looking into that though
[01:14] <siretart> okay. thanks for considering
[01:38] <LarstiQ> Kinnison: does something like 'bzr push chinstrap:/home/warthogs/archives/$yourusername/launchpad/branch-name' work?
[01:38] <LarstiQ> Kinnison: (shamelessly stolen from https://wiki.launchpad.canonical.com/MoveToBazNG)
[01:39] <LarstiQ> ssh chinstrap mkdir -p /home/warthogs/archives/$yourusername/launchpad 
[01:39] <LarstiQ> ;)
[01:41] <Kinnison> aye
[01:41] <LarstiQ> Kinnison: did you get it to work now?
[01:42] <Kinnison> aye
[01:42] <LarstiQ> sweet
[02:42] <lifeless> stub: ping
[02:47] <stub> lifeless: pong
[02:48] <lifeless> stub: why did you need to use trunk? I used the rollouts stuff with jamesh successfully yesterday
[02:50] <stub> lifeless: Mirroring branches with rsync to make branches locally
[02:53] <stub> lifeless: I was about to commit a modern refuel script that creates local mirrors of branches using rsync, allowing you to update and build trees much quicker.
[02:54] <lifeless> stub: well, three thoughts
[02:54] <lifeless> stub: firstly, make sure .bzr/parent is set correctly.
[02:55] <lifeless> stub: secondly, tree *building* should be a once per developer and install activity. After that it should be pull/merge/pull --overwrite.
[02:56] <stub> lifeless: I have several trees open at a time in general and find I'm building trees quite often
[02:57] <lifeless> stub: so, cp -a between them - thats fully supported
[02:57] <stub> lifeless: Yup. But update is painful
[02:57] <lifeless> stub: but there should be no need for full builds, in general.
[02:57] <lifeless> stub: update of the nested trees ?
[02:58] <stub> rsynced trees seem quite servicable to me. What is the issue?
[02:58] <lifeless> its doable, no particular issue. But you need to run revert in every tree, as I explained. in email.
[02:59] <lifeless> also it seems ugly that rsync is needed, martin and I hope to make non rsync performance as good or better for 0.7
[03:01] <stub> lifeless: Sure. This is just a temporary measure.
[03:02] <stub> lifeless: But until then building a tree remotely is just impractical
[03:02] <lifeless> stub: note that I have not said 'dont do it'
[03:02] <lifeless> just raised some thoughts
[03:03] <stub> Any hints on how to use bzrlib to do a revert?
[03:03] <lifeless> yah, look in bzrlib/builtins.py and cargo cult from cmd_revert
[03:04] <lifeless> SteveA: comign down ?
[03:05] <SteveA> sure.  have you had breakfast yet?
[03:05] <lifeless> yes
[03:05] <lifeless> we're starting work :)
[03:05] <SteveA> successfully?
[03:05] <stub> Ahh.... bzrlib.branch.Branch.revert might be a start
[03:05] <lifeless> no
[03:17] <kiko> SteveA, coming down too
[03:42] <SteveA> hi stub.
[03:42] <stub> SteveA: hi
[03:42] <SteveA> lifeless / stub: the 'trivial, steve's spec hacks in production' email from pqm seemed to include a LOT of stuff
[03:43] <SteveA> stub: do you know what the problem with your address and shipit is?
[03:44] <stub> Too many lines, lines too long. I got it in my abusing the organization field. But the issues outlined remain.
[03:45] <SteveA> i don't think "we're losing orders because of this" is a convincing enough argument on its own
[03:45] <SteveA> is there a way we can ask people "are you having problems entering your address into our system?"
[03:46] <SteveA> salgado /  mpt: what do you think?
[03:47] <mpt> Something like "If you think ShipIt should accept addresses like this, __report this as a bug__"?
[03:48] <mpt> where the link automagically squirts the address into the Description field of the bug report? :-)
[03:48] <stub> Oh. My main issue would be why the hell are we bending over backwards to meet the demands of a company we are pumping millions of euros through when they should be the ones meeting our requirements and asking if we would like a blow job with that?
[03:50] <stub> ASCII only, no commas, very restrictive fields. I recall the encoding issues gave mako a lot of headaches, and the ascii names have already given us grief.
[03:51] <mpt> so the company's using CSV, huh
[03:51] <SteveA> using *shitty* csv
[03:52] <mpt> We could convert commas to semicolons behind the scenes, I don't think anyone would mind
[03:52] <salgado> mpt, I already do that
[03:52] <SteveA> i thought we already did that
[03:52] <mpt> so did I
[03:52] <SteveA> so stub is saying, why can't the shippiing company
[03:52] <mpt> ok
[03:52] <lifeless> SteveA: yes, and to add insult, pqm died after sending the email, before completing the push
[03:53] <SteveA> whither transactions?
[03:53] <lifeless> the failure was during sending the mail
[03:54] <lifeless> 'mail' considered the pipe closing to be 'please send.'
[03:54] <SteveA> ah
[03:54] <lifeless> ascii codec, failure to encode, ordinal not in range.
[03:57] <SteveA> stub: jdub wants to hassle you
[03:57] <jdub> HEY STUB!
[03:58] <jdub> SteveA said i should bug you about me being JeffWaugh2 on the wiki
[03:58] <SteveA> screw you hippy
[03:58] <SteveA> i'm channeling stub here
[03:59] <SteveA> spiv: hello
[03:59] <SteveA> spiv: can we talk about some minor moin integration stuff?
[04:00] <stub> jdub: What do you log in as? The DB says username jdub's wikiname is JeffWaugh
[04:01] <SteveA> lifeless: the load on chinstrap goes up to 11
[04:01] <lifeless> actually, it goes up to 200
[04:01] <lifeless> but we're being nice to it right now
[04:01] <SteveA> but 11 is louder
[04:01] <stub> And JeffWaugh2 is owned by an atavism from an account merge
[04:06] <elmo> kiko, you slack jawed hippy, what's your launchpad ID?
[04:07] <lifeless> kiko
[04:07] <jdub> stub: but on the wiki, i'm logged in as JeffWaugh2
[04:07] <elmo> no, numerically
[04:07] <uws> heya jdub sign my gpg key! :P
[04:07] <stub> (21:00:24) stub: jdub: What do you log in as? The DB says username jdub's wikiname is JeffWaugh
[04:08] <lifeless> elmo: numerically, he wont know, its in person.id
[04:09] <lifeless> elmo: you have db access ?
[04:09] <elmo> I have root, that doesn't mean I go around running SQL queries on the production DB for giggles
[04:10] <stub> 1387, although I'd love to know what that is being used for apart from an internal database key?
[04:10] <jdub> stub: yes, in launchpad, it just says JeffWaugh. when i log in to the wiki as jeff.waugh@ubuntu.com, the wiki user is JeffWaugh2
[04:11] <lifeless> elmo: well, you could ask 'staging' the query, which is where stub does most of his adhoc stuff, IRRC>
[04:11] <stub> jdub: That is very wierd. That email address is linked to JeffWaugh
[04:11] <elmo> stub: moin
[04:12] <stub> elmo: oh... the perferences cache? I see.
[04:13] <elmo> well not so much a cache as a data store, but yeah
[04:13] <stub> jdub: The database is correct. I think you need to hassle spiv, or maybe those files elmo is poking in right now have the answer.
[04:14] <stub> (Jeff is 6727)
[04:16] <LarstiQ> uws: tsk
[04:23] <elmo> I think you want spiv first, as it's not obvious how id maps to name, and the code to do it is square in the middle of stuff he patched
[04:23] <elmo> kiko: as for yours, your account doesn't say disabled...
[04:25] <elmo> kiko: as for yours, your account doesn't say disabled...
[04:26] <kiko> elmo, that's odd, but it is disabled. I can't log in at least.
[04:38] <spiv> elmo: The file name in moin for a user should be the launchpad ID, I think.
[04:39] <elmo> spiv: yes, it is
[04:39] <elmo> spiv: I more meant the mapping of launchpad ID -> wiki User Name
[04:40] <spiv> Oh, right.
[04:40] <spiv> That's from the database -- the query stub would have done earlier would be right.
[04:41] <spiv> i.e. select wikiname from wikiname where person = X and wiki = 'http://whatever';
[04:42] <stub> Which gives JeffWaugh, not JeffWaugh2
[04:42] <spiv> Moin asks the authserver for that info, and it does (essentially) that query.
[04:43] <spiv> The authserver says jeff.waugh@ubuntu.com has a wikiname of JeffWaugh.
[04:44] <kiko> spiv, mine is ChristianReis, right?
[04:45] <spiv> kiko: right
[04:46] <mpt> Who's lalo@canonical.com?
[04:46] <kiko> mpt, someone who used to work with us
[04:46] <spiv> jdub: https://wiki.ubuntu.com/JeffWaugh?action=info shows "JeffWaugh" in the edit history.
[04:47] <spiv> jdub: Where are you seeing the string JeffWaugh2?
[04:47] <mpt> They're the ancestor of all my branches
[04:47] <jdub> spiv: moin
[04:47] <jdub> oh, hold on
[04:47] <spiv> jdub: Be more specific, please :P
[04:47] <kiko> mpt, have you asked lifeless?
[04:47] <mpt> kiko, it seems to be working fine, I was just wondering
[04:48] <jdub> spiv: yeah, sec :)
[04:48] <jdub> spiv: hrm, i'll bug you when i see it
[04:49] <spiv> Heh.
[04:49] <kiko> mpt, sounds like a bug to me but..
[04:50] <spiv> I'll just assume that means jdub can't reproduce his problem ;)
[04:50] <mpt> ok, lifeless: ping
[04:51] <kiko> I can however, spiv :)
[04:51] <spiv> kiko: Does that mean you have a URL for me? :)
[04:53] <LarstiQ> mpt: Lalo Martins?
[05:00] <jamesh> spiv: pending-reviews/ doesn't currently URL-decode the %2F in your branch name
[05:01] <spiv> jamesh: I wondered about that... I couldn't remember if the @ confused it or not.
[05:02] <spiv> jamesh: Although, %2f is slightly more correct, isn't it?
[05:04] <jamesh> spiv: the '@' did confuse it at one point, but doesn't now
[05:07] <kiko> spiv, well, I can' t log in to the wiki, period.
[05:07] <jamesh> spiv: if you're done with your baz branches, you can move the contents of the andrew.bennetts@canonical.com/ directory up one level too
[05:07] <LarstiQ> kiko: do you get an error?
[05:08] <spiv> kiko: Using your launchpad login?
[05:08] <kiko> spiv, yep
[05:08] <spiv> (i.e. logging in as "kiko" not "ChristianReis")
[05:08] <spiv> (or with your email address)
[05:08] <kiko> spiv, as kiko@async.com.br
[05:09] <spiv> That should work.
[05:09] <spiv> Do you have access to macquarie?
[05:09] <kiko> spiv, I /think/ I once clicked on "disable my account forever"  because a user had done it and I wanted to reproduce
[05:09] <kiko> spiv, no, I don't
[05:09] <spiv> Oh.
[05:09] <kiko> and in fact I lost it forever
[05:09] <spiv> Heh.
[05:10] <jamesh> kiko: create a new launchpad account, merge your existing one into it, and use that ...
[05:10] <spiv> That option probably needs to die.
[05:10] <jamesh> that'll get a new user ID
[05:10] <kiko> no
[05:10] <jamesh> no?
[05:11] <kiko> that option should be nuked AND all disabled accounts should be reenabled
[05:11] <spiv> kiko: re-enabling that needs elmo or someone else with direct access to wiki files.
[05:11] <kiko> spiv, elmo is a step away from me
[05:12] <elmo> it's not disabled
[05:12] <kiko> but he apparently said that my account isn' t disabled
[05:12] <kiko> right
[05:12] <jamesh> kiko: he might have been looking at your pre-launchpad user ID
[05:13] <spiv> elmo: you checked file 1387?
[05:14] <elmo> root@palmer:/srv/wiki.launchpad.canonical.com/www/data/user # grep disabled 1387
[05:14] <elmo> disabled=0
[05:14] <spiv> Hmm.
[05:14] <kiko> hmmm
[05:15] <kiko> hey stub, did you get my email?
[05:15] <spiv> kiko: Hmm.
[05:15] <stub> eh?
[05:17] <kiko> stub, the one I sent yesterday, on gina?
[05:17] <spiv> kiko: On chinstrap, could you fire up a python prompt, and do: >>> import xmlrpclib; s = xmlrpclib.Server('http://macquarie:8999/v2'); print s.authUser('kiko@async.com.br', 'xxx')
[05:17] <stub> i rolled out a patch of yours on staging and fired off a gina run
[05:17] <spiv> kiko: Only, with your actual password ;)
[05:17] <spiv> And tell me if it returns an empty dictionary or not.
[05:18] <kiko> stub, you /rock/
[05:18] <kiko> whee
[05:18] <kiko> spiv, let me try.
[05:19] <kiko> spiv, it returns my data correctly.
[05:19] <kiko> {'wikiname': 'ChristianReis', 'emailaddresses': ['kiko@async.com.br', 'kiko@canonical.com'] , 'displayname': 'Christian Reis', 'id': 1387, 'teams': [{'displayname': 'Ubuntu Drivers', 'id': 322877, 'name': 'ubuntu-drivers'}, {'displayname': 'Christian Reis', 'id': 1387, 'name': 'kiko'}, {'displayname': 'Launchpad Developers', 'id': 15158, 'name': 'launchpad'}, {'displayname': 'Launchpad Administrators', 'id': 2794, 'name': 'admins'}, {'displayname': 'ShipIt 
[05:19] <kiko> Administrators', 'id': 243601, 'name': 'shipit-admins'}] }
[05:19] <spiv> Ok, so the authserver end is working just fine.
[05:19] <spiv> So the problem must be in moin somewhere.
[05:20] <kiko> yeah, I knew it was because I can log in to any other wiki
[05:21] <kiko> I think the issue is related to what I suggested before 
[05:21] <kiko> but.. I don't know for sure.
[05:21] <spiv> Weird.
[05:21] <spiv> I didn't realise it was just the one moin.  That's doubly weird.
[05:21] <spiv> elmo: maybe diff kiko's moin user file from a working wiki?
[05:21] <spiv> kiko: You're seeing "Sorry, wrong password", or something else?
[05:22] <kiko> Sorry, wrong password.
[05:23] <spiv> elmo: is there a "valid=0" in kiko's user file?  (there should be no valid=foo line at all, but who knows...)
[05:29] <elmo> spiv: no, valid=0, and diff to a random other ID looks sane
[05:29] <elmo> http://people.ubuntu.com/~james/tmp/1387
[05:30] <spiv> elmo: thanks
[05:31] <spiv> Yeah, certainly looks sane.
[05:31] <spiv> kiko: I've got *no* idea.  Must be a browser bug ;)
[05:31] <spiv> The user code in moin is pretty horrible, but I can't see how it's horrible enough to muck that up.
[05:32] <kiko> spiv, you are very funny
[05:32] <spiv> Well, it is considerably past my bedtime :)
[05:32] <jamesh> kiko: maybe you shouldn't have logged out forever
[05:36] <kiko> jamesh, maybe not. I was trying to help verify a problem a user reported.
[05:37] <spiv> Anyway, the patch to remove that option should be a simple one-liner (delete the obvious line from MoinMoin/user.py:User._checkbox_fields), but I'm not going to trust my testing of that at this time of night.
[05:43] <lifeless> SteveA: ping
[05:43] <lifeless> SteveA: can we get the lp test runner to not buffer everything until the end ?
[05:44] <lifeless> SteveA: for pqm.
[05:47] <Kinnison> my merge was "Terminated"
[05:47] <Kinnison> I assume by pqm
[05:47] <lifeless> I dont know what that means
[05:48] <Kinnison> Well, I sent off a merge
[05:48] <Kinnison> it failed
[05:48] <SteveA> lifeless: the point of that originally was to give no output on success, and only output on failure, because the test suite was too darn noisy.
[05:48] <SteveA> now it is much less noisy
[05:48] <Kinnison> The end of the log was :
[05:48] <Kinnison> make: *** [check_merge]  Terminated
[05:48] <lifeless> oh, I stomped on a merge
[05:49] <lifeless> there was a bug I needed to correct that would have cuased a later failure.
[05:49] <Kinnison> Oh
[05:50] <kiko> stub, where are the logs going?
[05:50] <stub> kiko: Same place as always
[05:50] <Kinnison> certainly speeds up the subsequent push
[05:50] <lifeless> Kinnison: read the MoveToBazNG page
[05:50] <Keybuk> ...hmm, my Karma has been stuck on 69 for ages
[05:50] <Keybuk> why do I think someone's hardcoded that
[05:50] <kiko> stub, /srv... right?
[05:50] <Kinnison> lifeless: erm, perdon?
[05:51] <lifeless> Kinnison: its documented 
[05:51] <Kinnison> oh right
[05:51] <LarstiQ> Kinnison: no reason, no reason at all
[05:51] <stub>  /srv/launchpad.ubuntu.com/gina-logs
[05:51] <Kinnison> LarstiQ: whowhat?!
[05:52] <LarstiQ> argh
[05:52] <LarstiQ> s/Kinnison/Keybuk/
[05:52] <LarstiQ> Kinnison: sorry!
[05:57] <SteveA> lifeless: https://wiki.launchpad.canonical.com/AssertionsInLaunchpad  btw
[05:59] <lifeless> yah
[06:00] <lifeless> I had read that
[06:00] <lifeless> and it doth not say 'in tests, do /donot'
[06:00] <SteveA> yes
[06:01] <SteveA> you should update it, or get someone else to do so, when this is all agreed
[06:17] <stub> lifeless: Will brads merge fail? The pqm message is different to the others (no sftp)
[06:17] <stub> I just documented 'setting the parent' in the rsync recipe
[06:29] <salgado> how big is a launchpad tree with all dependencies in bzr?
[06:31] <lifeless> stub: yes, it will fail
[06:31] <lifeless> bradb: ^^^
[06:37] <stub> bzr: ERROR: 'ascii' codec can't encode characters in position 25-26: ordinal not in range(128)
[06:37] <stub>   command: '/usr/bin/bzr' 're-sign' '-r' '1681..'
[06:37] <stub>       pwd: u'/home/stub/tmp/da'
[06:37] <stub>     error: exceptions.UnicodeEncodeError
[06:37] <stub>   at /usr/lib/python2.4/site-packages/bzrlib/testament.py line 168, in as_short_text()
[06:37] <stub>   see ~/.bzr.log for debug information
[06:37] <stub> lifeless: Trying to resign one of my branches
[06:39] <lifeless> stub: grah
[06:39] <lifeless> stub: what bzr are you running ?
[06:39] <stub> 23:39:21~/lp/da $ bzr --version
[06:39] <stub> bzr (bazaar-ng) 0.6pre
[06:39] <stub> jbaileys
[06:40] <stub> I can reinstall integration from source easily enough
[06:40] <lifeless> stub: can you file a bug, with the backtrace from bzr.log
[06:40] <stub> Where are bugs filed? Launchpad?
[06:40] <lifeless> bzr - malone
[07:02] <lifeless> stub: so, please try with integration
[07:05] <lifeless> stub: also, what was the problem with rollouts ?
[07:05] <stub> rollouts?
[07:05] <lifeless> you emailed saying you could not use the rollouts bzr 
[07:05] <SteveA> mpt: ping
[07:06] <stub> Oh. Erm. I forget :-(
[07:06] <stub> cm.py was hanging trying to get the first bzr branch (hct I think). Using the head of the integration branch fixed it.
[07:18] <stub> lifeless: dies at the same place
[07:40] <salgado> lifeless, ping
[07:41] <salgado> so, I was running "cm.py build configs/configs/canonical.com/launchpad/development
[07:41] <salgado> " for more than 20 hours when we had a power outage. how can I resume that?
[07:42] <bradb> salgado: dude, run that on chinstrap
[07:42] <bradb> it'll be done in under an hour, IIRC (like, a lot under an hour IIRC)
[07:44] <salgado> bradb, thanks dude. I thought I've seen someone saying some requirement for that wasn't installed on chinstrap
[07:45] <salgado> looks like I got it wrong. :-(
[07:45] <bradb> yeah, that was me :) lifeless installed bzr
[07:45] <bradb> so, the instructions for doing it remotely should work fine now
[07:46] <salgado> bradb, not really. :-(
[07:46] <salgado> cm.py build configs/configs/canonical.com/launchpad/development
[07:46] <salgado> Traceback (most recent call last):
[07:46] <salgado>   File "/usr/local/bin/cm.py", line 21, in ?
[07:46] <salgado>     from config_manager import main
[07:46] <salgado> ImportError: No module named config_manager
[07:46] <salgado> did you run it there?
[07:46] <bradb> i ran the instructions verbatim
[07:47] <salgado> oh, okay. the instructions on MoveToBazNG are different
[07:47] <bradb> salgado: just follow the instructions word-for-word in "Using bzr remotelly and rsyncing locally" on that page
[07:47] <bradb> s/lly/ly/
[07:50] <bradb> no prob
[07:54] <salgado> bradb, do you know why the hell we need to configure a greedy revision library?
[07:55] <bradb> not really, no. I've already removed baz from my machine though, and I'd rather not think too much more about the way it "works". :)
[08:14] <lifeless> salgado: see 'MoveToBazNG'
[08:15] <lifeless> stub: I'll try getting hct with integration
[08:43] <kiko> bradb?
[08:43] <bradb> yo
[08:43] <kiko> how goes it duderino
[08:43] <bradb> pretty good, you?
[08:44] <kiko> bradb, not entirely ungood
[08:44] <kiko> bradb, privmsg alert ;)
[08:44] <bradb> good thing you told me! colloquy is teh suck for privmsg's
[08:47] <kiko> I've since learned
[08:47] <kiko> hey sabdfl, how's the other hemisphere? 
[08:50] <SteveA> salgado: seen mpt?
[08:53] <matsubara> SteveA: I think he's on portuguese class
[09:22] <lifeless> SteveA: ping
[09:22] <SteveA> yes
[09:22] <lifeless> 19:02:56 INFO    Applying comments.sql
[09:22] <lifeless> createdb: database creation failed: ERROR:  source database "launchpad_ftest_template" is being accessed by other users
[09:22] <lifeless> Traceback (most recent call last):
[09:22] <lifeless> ...
[09:22] <lifeless>   File "/home/pqm/arch/queue/workdir/home/---devel/launchpad/database/schema/../../lib/canonical/database/sqlbase.py", line 577, in connect
[09:22] <lifeless>     return psycopg.connect(con_str)
[09:22] <lifeless> psycopg.OperationalError: FATAL:  database "launchpad_empty" does not exist
[09:22] <SteveA> any processes sitting around?
[09:22] <lifeless> no, its not the normal.
[09:23] <lifeless> rather than 'in use', its 'missing'
[09:23] <SteveA> full disks?
[09:23] <SteveA> let's ask elmo to look into it, from a sysadmin level
[09:23] <lifeless> Filesystem            Size  Used Avail Use% Mounted on
[09:23] <lifeless> /dev/sda3             537G  263G  247G  52% /
[09:23] <lifeless> elmo: ping
[09:23] <SteveA> hmm
[09:25] <sabdfl> stub around at all?
[09:26] <lifeless> hes asleep I think
[09:26] <sabdfl> lifeless: in montreal? or in thailand still?
[09:27] <lifeless> AFAIK, thailand.
[09:27] <bradb> lifeless: did you try running the command more than once?
[09:27] <bradb> sometimes it works the second time
[09:27] <SteveA> SteveA: 
[09:27] <lifeless> bradb: thats pqm
[09:27] <SteveA> sabdfl: according to the wiki, stub arrives on 1 nov
[09:27] <SteveA> so, still in thailand
[09:27] <bradb> lifeless: oh
[09:28] <sabdfl> SteveA: i have a baz branch that contains last nights work. should i merge latest baz rocketfuel?
[09:28] <sabdfl> it has a db patch that is good but needs a numberfrom stub.
[09:28] <sabdfl> if you could merge it, morving the db patch to the official place, it will give you the Not for us bits and quite a bit of general cleanup
[09:29] <sabdfl> it specifically needs a review from you, though
[09:29] <sabdfl> because i was inspired finally to sort out the generalform infrastructure i created
[09:29] <sabdfl> it now supports zcml directives
[09:29] <SteveA> does that make it clearer?
[09:29] <sabdfl> its really a much simpler form infrastructure for the non-trivial add/edit cases
[09:30] <sabdfl> SteveA: yes, besides, it just feels proper
[09:30] <sabdfl> but, there's some cargo culting of zope magic
[09:30] <SteveA> i'm very keen to move as much as possible out of the zcml
[09:30] <sabdfl> so a review would be welcomed
[09:30] <SteveA> ok
[09:30] <sabdfl> i'll mirror up the current branch, which passes tests
[09:30] <SteveA> please add the details to the PendingReviews page so james' script can pick it up
[09:31] <sabdfl> then i'll merge rocketfuel, and if that passes tests, will mirror it up too so a landing will be conflict-free
[09:31] <sabdfl> i haven't done the bzr switcheroo
[09:31] <SteveA> it takes a while
[09:31] <SteveA> to convert your branches
[09:31] <SteveA> a long while
[09:32] <bradb> the baz -> bzr branch conversions will be running all next week, at this pace
[09:32] <SteveA> yes
[09:32] <SteveA> but, they also make pqm really slow
[09:32] <bradb> yep :/
[09:32] <SteveA> because it is all running on chinstrap
[09:32] <SteveA> the load was about 12 earlier
[09:33] <sabdfl> mark.shuttleworth@canonical.com/launchpad--pre-ubz-specs--0
[09:33] <sabdfl> elmo: is that integration box ready for lifeless love?
[09:33] <sabdfl> sounds a bit like dating an english chick
[09:34] <sabdfl> SteveA: plan is to move pqm to a dedicated fast box
[09:34] <SteveA> yep
[09:34] <SteveA> but i don't know what the ETA for that is
[09:42] <mpt> lifeless: ping
[09:42] <lifeless> pong
[09:43] <mpt> lifeless: For every branch that's baz-imported, it gets to nearly finished, then says "ancestor of lalo@canonical.com--canonical-work-2004/pytranslations--devel--0.1--version-0 is lalo@canonical.com--canonical-work-2004/pytranslations--devel--0.1--patch-17", then begins the next one
[09:43] <mpt> Is that any cause for concern?
[09:43] <lifeless> nope
[09:44] <mpt> good good
[09:44] <lifeless> its just that the emission of the debug statement there means you do not see the end of the scroll bar
[09:44] <mpt> ok
[09:44] <mpt> I reported that as a bug, I just wanted to know whether the import was still being useful
[09:46] <lifeless> very much so
[09:46] <lifeless> thank you
[09:56] <sabdfl> SteveA: mail from jamesh sais baz branches are being ignored by his script
[09:57] <kiko> that is true
[10:01] <jamesh> sabdfl: yeah.  since they can't be landed.
[10:02] <sabdfl> jamesh: np
[10:02] <sabdfl> SteveA: you could tag from mine, fix db patch number, review, and land
[10:02] <sabdfl> however
[10:02] <sabdfl> i'm worried that it would make my work tonight behave weirdly w.t.o. conflicts etc
[10:04] <SteveA> sabdfl: okay.  i can review etc. without using james' script
[10:06] <SteveA> do you have any idea what you will work on during the flight back?
[10:07] <sabdfl> SteveA: privmsg todo list
[10:31] <SteveA> mpt: how do you specify a minimum table cell height?
[10:32] <mpt> SteveA: min-height: whatever;
[10:33] <SteveA> thanks
[10:33] <elmo> can you safely modify a list you're iterating over?
[10:33] <SteveA> no
[10:33] <SteveA> well
[10:33] <elmo> bother
[10:36] <lifeless> elmo: new_list = list(old); for member in old:
[10:36] <elmo> is that more idiomatic than copy.copy() ?
[10:36] <SteveA> yes
[10:37] <lifeless> its easier :)
[10:37] <SteveA> copy.copy() attempts a deep copy
[10:37] <SteveA> or does it
[10:37] <lifeless> err no
[10:37] <SteveA> whatever
[10:37] <SteveA> it's all CRACK anywya
[10:37] <elmo> copy.deepcopy() does a deep copy, copy.copy() is shallow
[10:37] <lifeless> Help on function copy in copy:
[10:37] <lifeless> copy.copy = copy(x)
[10:37] <lifeless>     Shallow copy operation on arbitrary Python objects.
[10:37] <lifeless> 
[10:37] <SteveA> elmo: if you're iterating over the list, you can modify its members.
[10:37] <lifeless> elmo: list(foo) is nice in that it ensure you have a list
[10:37] <lifeless> copy.copy is nice in that it preserves the type
[10:38] <SteveA> but you can't add to or remove elements from the list
[10:38] <elmo> SteveA: sorry, by "modify", I mean use .remove()
[10:38] <SteveA> yeah, don't
[10:38] <SteveA> use a copy
[10:38] <LarstiQ> for item in old[:] : is also iodmatic, but list(old) is nicer
[10:38] <elmo> yeah, I'd done that by 'bother' :)
[10:39] <bradb> elmo: you might want to use something like "newlist = [foo for foo in bar if foo == something] " to filter items out of a list.
[10:55] <TylerM> anyone here got a geographic data or mapping project on the go via launchpad?
[10:56] <kiko> not yet, TylerM!
[11:06] <bradb> hm, by the time one writes an interface, a content class, a dbschema vocab, a *Set utility (and a doctest for that), and hooks it all up in ZCML, it seems to take about 150-200 lines of code/doctest/config to expose a new domain object in LP (of course, that's not counting any extra logic beyond the minimum CRUD APIs)
[11:09] <SteveA> why do you need a *Set ?
[11:09] <SteveA> shuldn't need that
[11:09] <lifeless> because he is writing stars!
[11:09] <bradb> SteveA: to create the object
[11:09] <SteveA> we generally create objects in the context of something
[11:10] <SteveA> you're probably not creating a new context object
[11:10] <SteveA> don't create unnecessary content sets
[11:12] <bradb> SteveA: that's interesting that you say we "generally" do that, because we have already 79 *Set interfaces
[11:13] <bradb> and it often seems like 1-to-1 domain object to *Set
[11:14] <SteveA> we should get rid of most of them
[11:14] <bradb> indeed :)
[11:15] <bradb> i hope we can trim down to under 10,000 lines of XML config too :)
[11:15] <SteveA> i'm going to be getting rid of much of the zcml in time
[11:15] <bradb> it sounds like you want less of that. simplicity is the new black.
[11:16] <bradb> so, in this case, I'll do the create in IDistributionSourcePackage.subscribe
[11:19] <TylerM> kiko: thanks :)
[11:19] <kiko> sounds interesting though
[11:26] <TylerM> it's what I really care about :)  http://oreillynet.com/pub/au/1898
[11:26] <TylerM> the commercial realm is quite monopolised and the open source geospatial realm is exhilirating...
[11:33] <jdub> spiv: ping
[11:35] <jdub> spiv: that 'JeffWaugh2' user is now 'MrPantless'
[11:35] <jdub> https://wiki.ubuntu.com/UbuntuBelowZero/LoveDay?action=info