[12:00] <ddaa> I made a very stupid one once...
[12:01] <ddaa> One have to say thank you for every received penalty card...
[12:01] <BradB> sadistic!
[12:01] <ddaa> Obviously, this rule becomes very annoying when it stacks up...
[12:02] <ddaa> And giving the bad calls becomes devilishly complex.
[12:02] <BradB> yep, the joy of mao
[12:02] <ddaa> Kinnison plays a fearsome mao.
[12:02] <BradB> yes!
[12:03] <BradB> his rules have plotlines
[12:03] <ddaa> Though, the "initial rubrique/rethoric"  is best said with Keybuk's accent :-)
[12:03] <BradB> heh
[12:04] <ddaa> And sadistic glint in the eye :-)
[12:09] <ddaa> lifeless: you might want to know, the import i started friday morning is still running...
[12:32] <lifeless> ddaa: hmm
[12:33] <lifeless> what is it? ?
[12:33] <ddaa> vte...
[12:33] <lifeless> how many revisions on MAIN ?
[12:33] <ddaa> Well, that's the debug output that's killing it...
[12:33] <lifeless> and where has it got to?
[12:33] <ddaa> It gets into the slave logs... but they 
[12:34] <ddaa> stay limited at 100 logs.
[12:34] <ddaa> My point is that we should probably take another approach to debug the hangs...
[12:34] <lifeless> ah.
[12:34] <ddaa> Debug logging is not practical...
[12:35] <lifeless> not for full import runs.
[12:35] <lifeless> agreed.
[12:35] <ddaa> Unless we have multiple levels of debug logging...
[12:36] <lifeless> we can in principal, do what scotts done, which has different child debuggers.
[12:36] <lifeless> we hammer that out in oxford.
[12:36] <lifeless> but I haven't applied the principal to cscvs
[12:36] <ddaa> Maybe we could use gdb as spiv suggested.
[12:46] <lifeless> sure
[12:46] <ddaa> He said there are gdb macros around that display the current python backtrace.
[12:46] <ddaa> Probably it's a simpler to figure out where it's breaking.
[12:46] <ddaa> But the recent evidence suggests that the hangs happens in cscvs process handling as well as in pyarch...
[12:46] <ddaa> So, I'm thinking more and it might be something Bad.
[12:46] <ddaa> Like a Python or kernel bug...
[12:46] <ddaa> Haha!
[12:46] <ddaa> I looked at the logs.
[12:46] <ddaa> Actually, there are 316 log files...
[12:46] <ddaa> and the current slave logs are all:
[12:46] <ddaa> 2004/11/01 00:40 CET [-]  sendStatus {'stdout': 'Server response ""\n'}
[12:46] <ddaa> vte is finished
[12:46] <ddaa> but apparently a a point I got angry and started a bunch of builds...
[12:46] <ddaa> So, it looks like taxi did not break, at least.
[12:48] <ddaa> But it also looks like I have an infinite loop situation for some reason.
[01:01] <ddaa> There is even sensible-looking stuff in the database.
[01:01] <ddaa> Not checked they are consistent, but there are archnamespace, archarchives, and archarchivelocation tuples for the imported packages.
[01:49] <dilys> Merge to thelove@canonical.com/bazaar-debian--debian--1.0: drop the debian version number to a pre-release (patch-3)
[04:12] !dmwaters:*! Hi all! In a few minutes there will be a small split while I move one server from one box to another
[04:22] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: add vim hint lines to libarch/a*.c (patch-51)
[04:33] !dmwaters:*! Ok, here goes that small server I mentioned earlier:)
[04:44] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: add vim hint lines to libarch/b*.c (patch-52)
[06:47] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: Pulling version string out of individual commands into one included file (patch-53)
[07:14] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: Hitting cmd-switch.c for version pullout and header fix for cmd-switch.c (patch-54)
[07:17] <dilys> Merge to rocketfuel@canonical.com/dists--devel--0: new production config (patch-30)
[09:08] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: Fixing up some copyright issues (patch-55)
[09:37] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: Arch no longer breaks a mirror if you try to commit to it (patch-56)
[11:04] <Kinnison> Morning
[11:05] <lifeless> hey
[11:19] <lulu> stub:around?
[11:20] <stub> lulu: Yup
[11:20] <lulu> stub: hey!
[11:21] <lulu> Are you working with Mako and Spiv on getting the shippit account holders into launchpad so our users don't have to create new accounts? 
[11:22] <stub> I wasn't aware of that until your email came in. I haven't talked to Mako or Spiv about it yet (or received anything from them about it).
[11:24] <stub> mako: ping
[11:24] <stub> spiv: ping
[11:25] <lulu> Ok - we have opened the site now for editing as cacheing is supposed to be fixed, and now we need to integrate the two asap. 
[11:25] <lulu> I think it's still early for them :o)
[11:26] <stub> So the goal is for shippit account holders to also have access to Plone I take it? Not Rosetta alpha or any other tools.
[11:28] <lulu> stub: shippit account holders - yes - to have access to the website.
[11:28] <lulu> what is the plan for further authentication for Launchpad tools?
[11:29] <stub> They will all be using the same account database, when they go 'production'. At the moment we only have dogfood and alpha servers which are not linked to the production database at all.
[11:29] <lifeless> stub: *cough* macquarie *cough*
[11:30] <stub> lifeless: :-P
[11:30] <stub> Ok.... one production server with only a handful of people using it.
[11:30] <lulu> Yes - so Launchpad tools, when public, will use the same account as launchpad=plone=shippit accounts.
[11:30] <stub> yes
[11:30] <lulu> So, we need to do Step 2 of the process: Integrate shippit with Plone
[11:31] <stub> ok. I'll chase it up with Spiv and Mako - they might already have it under control.
[11:32] <lulu> yes - let's check status with spiv and mako - I haven't heard from them on it yet - I'd like for us to set a deadline to get this done and who will be making it happen, asap.
[11:32] <lulu> thanks stub - catch ya later :o)
[11:32] <stub> np
[11:39] <lulu> stub:P.S. thank you for all your hard work on getting authentication/cookies sorted - much appreciated :o)
[11:44] <lulu> elmo: ping
[12:03] <sabdfl> hi everybody
[12:03] <sabdfl> stub: around still?>
[12:03] <stub> yup
[12:03] <sabdfl> quick call to catch up?
[12:04] <stub> 15 mins?
[12:04] <sabdfl> in 15 mins?
[12:04] <stub> yup
[12:04] <sabdfl> ok
[12:06] <lulu> sabdfl:hey Mark! good to be home?
[12:07] <sabdfl> lulu: glorious sunshine, lots to do but it's nonetheless great to be doing it from here :-)
[12:08] <sabdfl> have we done anything odd to chinstrap, or is it just my local connection over here?
[12:09] <stub> fine from here
[12:10] <lulu> sabdfl: lekker :o)
[03:48] <BradB> stub: other than 1. product/package reassignments and making sure the functional test is complete in a way that makes in really hard for people to break things that currently work, what other stuff do we need to do to malone before ubuntu people can start using it?
[03:48] <BradB> s/and making/and 2. making/
[03:49] <BradB> (other than roll out a new version and test for a little while)
[03:50] <stub> I don't think there is anything else that *has* to go in - plenty of stuff that will need to be in sometime or nice-to-haves.
[03:50] <BradB> sure
[03:51] <BradB> global notification is horrifying right now, since all i did was add another constant in mailnotification.py. I don't think it matters for a first release though.
[03:52] <BradB> stub: oh, hm, i guess we need to add some edit/delete stuff too, e.g. for ext refs
[03:52] <BradB> and for unsub'ing people from bugs, etc.
[03:52] <stub> If we bring in the Ubuntu people as well as using it for Launchpad, our focus will be spit (for example, Daf and people really want a graphical view of bug dependancies but the Ubuntu people need 'fix for distro x' flags).
[03:52] <kiko> morning
[03:52] <kiko> hey stub, BradB
[03:52] <BradB> hi
[03:52] <kiko> spiv, are you around?
[03:53] <stub> Morning.
[03:53] <kiko> did I scare you with my view proposals/
[03:54] <stub> kiko: Can you stick db patches in database/schema/pending (but still heads up the mailing list)? Makes sure they don't get lost and less error prone.
[03:54] <stub> kiko: Nothing particularly scary about what I saw.
[03:55] <Kinnison> kiko: Your views are less scary than mine :-)
[03:55] <kiko> stub, hum hum, I can try!
[03:56] <stub> kiko: They don't have to be correct or actually run btw. 
[03:57] <kiko> oh, they run!
[03:57] <kiko> the code I checked into the brazilian mirror uses it extensively
[03:57] <kiko> I'm hoping cprov or debonzi wait till they land it
[03:57] <kiko> cprov, ping?
[04:03] <cprov> kiko: pong
[04:05] <cprov> kiko: btw, I can't land your changes, ask debonzi ...
[04:05] <stub> BradB|brb: Possibly 'private' bugs for security issues. I don't know if that is a must have or not for the Ubuntu dudes. I do believe we need private for the Launchpad stuff, as the launchpad bugs are not supposed to be displayed to the world.
[04:05] <kiko> cprov, one sec, I'm with tiago
[04:06] <cprov> kiko: ok, don't worry 
[04:08] <kiko> cprov, I'm on my desktop, so I was wondering if you could add those views I emailed yesterday into database/schema/pending?
[04:10] <cprov> kiko: sorry, I didn't understand what's is your aim .
[04:10] <kiko> cprov, to have the views added into database/schema/pending as patches?
[04:11] <cprov> kiko: ohh yes, of course you can, add a patch by yourself (if stub allows you ...)
[04:12] <kiko> cprov, I was wondering if *you* could it do it since I'm not on my laptop :)
[04:13] <cprov> kiko: ok, I can, only the view doesn't represents any changes on lp code ...
[04:13] <cprov> kiko: send me the patch, 'show me the code !'
[04:14] <stub> kiko: Don't worry about the last two (index and views) - I'll handle them the old way. This is just for new patches that come through
[04:16] <kiko> stub, ah, okay. it's annoying because my desktop can't run lp, so everything's on my lappie
[04:21] <Kinnison> INFO: Chosen DR(1), PROC(1), DAR(1) from SUITE(hoary), ARCH(i386)
[04:21] <Kinnison> w00p, patch working
[04:23] <kiko> heh
[04:33] <Kinnison> What's the recommended way to parse commandline arguments in python? the getopt module is a bit sucky
[04:34] <kiko> there's optparse dude!
[04:35] <Kinnison> cripes that looks complex
[04:35] <BradB> Kinnison: what don't you like about getopt?
[04:35] <Kinnison> BradB: the way it doesn't seem to canonicalise the - vs -- args
[04:36] <Kinnison> BradB: of course that might be that I'm not calling it properly
[04:36] <kiko> canonicalise?
[04:36] <BradB> what does it mean to canonicalise - and -- args exactly?
[04:37] <BradB> -avz vs -a -v -z?
[04:37] <kiko> that works I believe
[04:37] <Kinnison> --arch -> -a
[04:37] <Kinnison> that sort of thing
[04:39] <Kinnison> like gnu getopt does
[04:39] <Kinnison> bwuahahaha
[04:40] <kiko> Kinnison, that works fine
[04:40] <kiko> Kinnison, do you mean support for single- and double-dash forms of the same option?
[04:40] <kiko> because that indeed works 
[04:40] <Kinnison> yeah; but I cba to play
[04:41] <Kinnison> gina now takes three or more options, namely.. suite, arch, component, component,....
[04:41] <kiko> I cba to play. Hmm. did that make sense?
[04:41] <Kinnison> cba == Can't be arsed
[04:41] <kiko> it's trivial, just supply a third argument to getopt?
[04:42] <kiko> heh
[04:43] <Kinnison> BradB: ugly
[04:43] <BradB> vs. required, positional args? heh.
[04:43] <Kinnison> anyway; like I said; I cba to play so the args are positional and mandatory
[04:43] <Kinnison> python grabber.py warty i386 main restricted
[04:43] <Kinnison> like that
[04:44] <kiko> that's fine by me.
[04:44] <Kinnison> dsilvers@rosetta:~/gina $ PYTHONPATH=/srv/launchpad.ubuntu.com/launchpad-dogfood/lib sudo -u launchpad python grabber.py hoary i386 main
[04:45] <Kinnison> INFO: Chosen DR(1), PROC(1), DAR(1) from SUITE(hoary), ARCH(i386)
[04:45] <BradB> What's PROC mean?
[04:46] <Kinnison> processorfamily
[04:46] <BradB> ah
[04:46] <Kinnison> I need to do a touch more processing there because I actually want a processor not a processorfamily I think
[04:49] <Kinnison> I guess I'll just pick the first processor I can find which belongs to the family
[04:51] <cprov> Kinnison: uhhh, I need to discuss the ProcessorFamily issue somehow :)
[04:51] <Kinnison> cprov: I'm glad you want to too
[04:52] <Kinnison> perhaps we should have a mailing list discussion about them
[04:52] <kiko> Kinnison, they are utterly confusing.
[04:52] <Kinnison> kiko: indeed
[04:53] <cprov> Kinnison: yes, maybe we have jamesh help on it again 
[04:59] <Kinnison> I've fired a mail at the list
[05:01] <kiko> you da man
[05:01] <kiko> n8t1ve
[05:01] <Kinnison> eh?
[05:02] <kiko> be creative
[05:02] <kiko> jesus my phone won't stop ringing
[05:11] <BradB> lulu: ping
[05:11] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: new style person-page (patch-719)
[05:11] <Kinnison> elmo: any idea when you'll be able to do that archive sync I mailed you about?
[05:11] <lulu> BradB: pong
[05:11] <BradB> heh
[05:11] <lulu> :o)
[05:11] <lulu> BradB: wazzzup?
[05:11] <BradB> lulu: is this going to be a *second* ul.org site?
[05:12] <BradB> i.e. i remember you mentioning ul.nl, i think
[05:12] <lulu> BradB: A Dutch guy has been very proactive and has set it up, yes. 
[05:12] <BradB> lulu: so, if i just give him a copy of the site, he'll do what he wants with it, and i don't have to worry about syncing anything back up with ul.org from him later on?
[05:13] <lulu> BradB: My thought is that he and his community will tranlate and make sure that they track UL.org and make changes when it changes.
[05:14] <BradB> hm
[05:14] <debonzi> hi all.. I am wrong or pqm is not running?
[05:14] <BradB> he'll keep up with wiki chanegs, for example?
[05:14] <lulu> I have said not to look at the wiki for now as this is in its infancy
[05:14] <BradB> ah
[05:14] <BradB> ok
[05:15] <lulu> we need to get LinguaPlone set up - then what will the procedure be with synching?
[05:15] <BradB> i'll give you a link in a bit from which he can d/l a copy of the site
[05:15] <lulu> BradB: ok
[05:15] <lulu> I have spoken to Limi about LinguaPlone - we need to set up ATContentTypes first and then migrate the data across.
[05:16] <BradB> lulu: not sure about the syncing thing yet. i'm no i18n expert, but it should be just a matter of him handing us the files that contain his localizations and then there are ways i think to automatically synch them up to what we have.
[05:16] <BradB> woo, that might be a bit painful
[05:17] <lulu> BradB: ok - I think step by step - let's help him get set up.
[05:17] <lulu> BradB: then we'll do what we need to get to Lingua Plone
[05:18] <BradB> yeah
[05:18] <lulu> and synching we will need to look at at the same time
[05:18] <lulu> I don't want to lose his enthusiasm and momentum tho'
[05:18] <BradB> me neither. i'm making the copy of the site now.
[05:19] <lulu> BradB: thank you :o)
[05:20] <kiko> stub, zero-pressuring, can you get me an eta on that view? I want to organize my time optimally
[05:24] <debonzi> debonzi -> lunch
[05:27] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: gina changes for specifying distrorelease/arch and remove some obsolete XXXs (patch-720)
[05:28] <Kinnison> thanks sexy.
[05:34] <BradB> elmo: Where can I put the tarball (i.e. on what machine and/or in what dir, and at what URL will it be available) of the Ubuntu site so that NL-guy can download it over http?
[05:35] <elmo> brabd: are you sure the tar is clean of any private stuff (passwords, authserver details etc.)?
[05:36] <BradB> good point, /me double-checks
[05:45] <mako> stub: hey there
[05:45] <BradB> lulu: hm, i'm thinking it might be easier to give him just a copy of the database, rather than the whole site (i.e. all the product sources and such.)
[05:46] <BradB> i don't know how to verify that there's aren't things hidden in the code that he shouldn't see
[05:46] <lulu> BradB: how about I send you his contact details and you can chat about the best way forward? does that sound sane?
[05:47] <BradB> sure
[05:48] <elmo> Kinnison: mawson's uptodate, I'm investigating while the daily script isn't workin
[05:50] <Kinnison> elmo: you're a star; thanks
[05:51] <cprov> Kinnison: what's going on gina ?  is it working as expected on mawson ?
[05:52] <Kinnison> cprov: I'm about to kick off a hoary import
[05:53] <cprov> Kinnison: cool !!!! let me know when I can run nicole on it :)
[05:56] <Kinnison> yay for gina asserting :-)
[05:57] <kiko> yay
[06:00] <sabdfl> how is mawson doing? are we in full swing, gina, nicole, soyuz, malone?
[06:01] <Kinnison> gina had amusing issues
[06:01] <Kinnison> I've squashed (I hope) the last one just now
[06:01] <Kinnison> just reloading the katie db from the latest dump ready to import
[06:01] <Kinnison> then it'll be all-go with nicole etc
[06:01] <sabdfl> zuuuppa
[06:02] <Kinnison> INFO: Chosen D(2) DR(1), PROC(1), DAR(1) from SUITE(hoary), ARCH(i386)
[06:02] <Kinnison> looking good....
[06:03] <Kinnison> I'd say the import of hoary is well underway
[06:03] <Kinnison> kiko: gina commits every 10 sourcepackagereleases
[06:04] <cprov> Kinnison: you rocks, you'd kicked almost all hardcoded references for warty in gina
[06:04] <Kinnison> kiko: you should instantly be able to look at the data; care to take a look?
[06:05] <kiko> Kinnison, on mawson? 
[06:05] <Kinnison> kiko: yeppers :-)
[06:05] <cprov> Kinnison: lp.ubuntu.com SQLO transaction is broken 
[06:06] <Kinnison> cprov: what does that mean?
[06:06] <kiko> hmmm
[06:06] <cprov> Kinnison: it means nothing is working !
[06:07] <Kinnison> cprov: boo hiss :-(
[06:07] <kiko> elmo, could I have a postgresql user on mawson that can access launchpad_dogfood?
[06:07] <cprov> Kinnison: restart lp (make run) again 
[06:07] <Kinnison> kiko: just sudo -u launchpad -H psql launchpad_dogfood
[06:07] <cprov> kiko: launchpad user 
[06:07] <kiko> Kinnison, I'm not a sudoer.
[06:07] <kiko> elmo, or make me be a sudoer.
[06:08] <Kinnison> cprov: could you sort that out please? I'm monitoring gina
[06:08] <cprov> Kinnison: I'll try
[06:08] <Kinnison> E.g. for the error which just turned up: libpq.OperationalError: ERROR:  new row for relation "person" violates check constraint "valid_name"
[06:09] <BradB> spiv: Did you submit your sqlos patche(s?) upstream?
[06:09] <elmo> kiko: you're now part of 'launchpad'
[06:10] <kiko> thanksyer
[06:10] <cprov> Kinnison: it's in BradB screen .. BradB ??
[06:10] <Kinnison> okay; who decided what a valid name is; and why isn't "florian_ernst" valid?
[06:10] <cprov> Kinnison: do you have a '_' on name, I think, replace with '-', valid_name() avoid '_' use ...
[06:10] <spiv> BradB: Yeah, I have.
[06:11] <Kinnison> cprov: gina will have created the name
[06:11] <cprov> Kinnison: s\do\.
[06:11] <cprov> Kinnison: using nickname.py
[06:11] <Kinnison>         Creating Person Florian Ernst <florian_ernst@gmx.net>
[06:11] <Kinnison> Bad things happened, data was {'familyname': 'Ernst', 'givenname': 'Florian', 'displayname': 'Florian Ernst', 'name': 'florian_ernst'}
[06:12] <cprov> Kinnison: nickname.py line 68, + user = user.replace("_", "-")
[06:13] <Kinnison> cprov: ta
[06:13] <kiko> damned florian.
[06:13] <cprov> BradB: can you restart lp, please ?
[06:14] <Kinnison> cprov: import continues....
[06:16] <cprov> Kinnison: nice
[06:16] <BradB> cprov: yeah, i'll restart
[06:16] <BradB> er, is a new version deployed?
[06:18] <elmo> you guys SO need to get over your screen-as-a-replacement-for-daemon() fetish
[06:19] <BradB> i've already filed the bug for that
[06:22] <kiko> launchpad_dogfood=# select count(*) from sourcepackagerelease;
[06:22] <kiko>  count 
[06:22] <kiko> -------
[06:22] <kiko>    558
[06:22] <kiko> (1 row)
[06:22] <kiko> Kinnison, it moves
[06:22] <Kinnison> kiko: good good
[06:22] <Kinnison> when will I be able to see it through the soyuz UI?
[06:24] <Kinnison> because it is failing to talk to the db?
[06:25] <Kinnison> or at least I think that's what cprov meant
[06:26] <BradB> oh
[06:27] <BradB> OperationalError: no connection to the server wee
[06:27] <Kinnison> wee?
[06:27] <BradB> as in wee hoo
[06:29] <BradB> this can't be right
[06:30] <Kinnison> anything in your screen?
[06:32] <BradB> requests had been getting printed out to the screen, but not anymor
[06:33] <Kinnison> heh
[06:33] <Kinnison> restart it and progress through slowly until you can see which request breaks it
[06:33] <BradB> maybe you're locking the db
[06:34] <BradB> i heard nothing of this before grabber.py was running
[06:34] <Kinnison> I managed to visit /soyuz/distros and /soyuz/distros/ubuntu before it locked up for me
[06:34] <Kinnison> grabber.py is just doing inserts and commits its transaction every 10 sourcepackagereleases
[06:34] <Kinnison> it absolutely shouldn't cause lp to lock up like this
[06:35] <Kinnison> and regardless, the front page doesn't use the db at all right?
[06:35] <BradB> i accessed that one fine a few mins ago
[06:36] <Kinnison> grabber has been running since; oooh over half an hour ago
[06:36] <BradB> hm, seems to work now
[06:36] <BradB> at least malone does
[06:39] <Kinnison> https://launchpad.ubuntu.com/soyuz/distros/ubuntu/releases/hoary is taking forever
[06:40] <BradB> sounds like a soyuz bug
[06:40] <kiko> launchpad_dogfood=# select count(*) from sourcepackagerelease;
[06:40] <kiko>  count 
[06:40] <kiko> -------
[06:40] <kiko>   1060
[06:40] <kiko> (1 row)
[06:42] <Kinnison> Okay; what does that page do which could take so long?
[06:43] <kiko> could be an SQL bug that I fixed with my views, hmmm
[07:00] <Kinnison> any arch gurus hanging around?
[07:03] <kiko> BradB, it's not just a matter of commenting, but a possible redesign requirement.
[07:04] <BradB> sufficient comments would have precluded that email though.
[07:04] <BradB> whether the design and intent of those tables (as described in the comments that don't exist) is *sane* would be another issue :)
[07:08] <kiko> no, we're generally confused by the tables, as in, they don't seem to make much sense
[07:11] <kiko-fud> 2025 sourcepackagereleases and counting.
[07:11] <kiko-fud> Kinnison, will gina run incrementally now?
[07:12] <Kinnison> kiko-fud: she is running reasonably incrementally yes
[07:12] <Kinnison> kiko-fud: I need to write the lucille domination implementation though
[07:14] <cprov> Kinnison: does gina SUPERCEED the old sourcepackagerelease when insert a new one  ?
[07:14] <Kinnison> cprov: No
[07:14] <Kinnison> cprov: that's the job of lucille
[07:14] <kiko-fud> hmmmm
[07:14] <Kinnison> cprov: assuming this import works; I'll be working on that bit of lucille next
[07:15] <cprov> Kinnison: right !
[07:15] <Kinnison> see https://wiki.canonical.com/Lucille_2fDomination
[07:15] <kiko-fud> I see
[07:35] !lilo:*! If you're with swpa.gov, please /msg lilo for information regarding freenode availability.  Thanks.
[07:56] <BradB> tla bash complete rocks my world
[07:58] <Kinnison> heh
[08:00] <Kinnison> fuck; gina stalled again
[08:01] <Kinnison> AttributeError: SourcePackageRelease instance has no attribute 'section'
[08:11] <kiko-fud> heh
[08:11] <kiko-fud> BradB, poliglot extraordinaire
[08:11] <BradB> google user since 1999!
[08:15] <BradB> sabdfl: do we need http://site-edit.ubuntulinux.org/ any longer? Maybe elmo or thom could bury it.
[08:25] <Kinnison> elmo: around?
[08:26] <BradB> hm....they functional tests *can't* be taking this long to run
[08:27] <Kinnison> oh yes they can :-)
[08:28] <BradB> shihiioot
[08:30] <Kinnison> fuck; there exists a sourcepackage for which I can determine no section
[08:33] <elmo> Kinnison: ?
[08:34] <Kinnison> elmo: in the dump you gave me; there's a source package 'preseed' which seems to have no overrides
[08:34] <Kinnison> elmo: is this an expected thing?
[08:34] <elmo> yes
[08:34] <Kinnison> what does it mean?
[08:35] <Kinnison> sorry if these are obvious questions but I'm very tired right now
[08:35] <Kinnison> removed package?
[08:35] <elmo> no, it's an artificat of how we do imports
[08:35] <elmo> you really need to handle not having override for any given package
[08:36] <elmo> 'cos the overrides for our archives are a mess but katie handles it
[08:36] <Kinnison> Currently I'm assuming <component>/misc for anything I've not seen
[08:36] <Kinnison> isthat right?
[08:36] <elmo> yeah, that's fine
[08:36] <Kinnison> cool
[08:36] <Kinnison> thanks dude
[09:00] <Kinnison> kiko: ping?
[09:00] <Kinnison> cprov: ping?
[09:01] <cprov> Kinnison: here
[09:02] <Kinnison> cprov: any chance you can look at why I've got a gina failure?
[09:02] <kiko> yes Kinnison?
[09:02] <Kinnison> - Evaluating libgal2.2-1 (main, 2.2.3-0ubuntu1)
[09:02] <Kinnison>        dpkg-source: error: file gal2.2_2.2.3.orig.tar.gz has size 1557056 instead of expected 1529433
[09:03] <Kinnison>        ** Evil things happened, check out /tmp/tmppyIBSV
[09:03] <Kinnison> any clues?
[09:04] <elmo> that's a known bug
[09:04] <elmo> warty has a gal2.2 orig.tar.gz with a different md5sum's to sid's
[09:04] <elmo> it'll be fixed the next time mawson updates
[09:04] <cprov> Kinnison: looks like obvious, but the deb files are corrupted :(
[09:04] <Kinnison> elmo: coo; okies
[09:05] <daf> Kinnison: coookies?
[09:05] <Kinnison> well; since it's 20:05 and I've been at this all day; I shall rest now
[09:05] <Kinnison> daf: I can order some cookies if you want
[09:05] <Kinnison> daf: white chocolate and macadamia-nut?
[09:05] <daf> ooooh
[09:05] <daf> they sound nice
[09:05] <Kinnison> they are
[09:06] <Kinnison> the cake we had in london when I was down came from her
[09:06] <daf> oh, cool!
[09:06] <Kinnison> daf: if you're nice; I'll buy you some cookies and bring them to the airport in december
[09:07] <daf> it's a deal :)
[09:07] <daf> I still owe you hugs and chocolate
[09:07] <Kinnison> I'm sure we can work out a deal
[09:09] <BradB> Anyone know if it's still possible to run just one page test?
[09:25] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: More gina fixes (patch-721)
[09:28] <Kinnison> thanks babe
[09:59] <Kinnison> elmo: btw; when should the daily sync for mawson happen?
[10:18] <sabdfl> BradB: if www is working fine for logging in and editing then yes, thom can remove site-edit not
[10:19] <sabdfl> now, even
[10:26] <BradB> i'll let thom make the decision then, since he's the one who declared that the caching works properly
[10:27] <BradB> on to other things: page testing with useful data is hard
[10:27] <BradB> in an ideal world, we want our page tests to be testing their output against actual, rendered output (rather than eliding the entire body of the page, and just checking the status header.)
[10:28] <BradB> i was well on my way to making this happen right now with malone, after chopping a few branches off each generated test
[10:29] <BradB> the problem is though: /modifying/ ordered tests to suit new UI or behaviours later on will be hell, because, let's say we're modifying an 80-foo-bar.txt test; we then have to somehow get the data to the state it is with all the tests that run right up to 80 before we can rerecord it.
[10:30] <BradB> do we reduce page tests to things that merely check status headers then?
[10:33] <daf> spiv: I have an SQLBase unit test failing here
[10:33] <daf> BradB: I'd rather not
[10:34] <spiv> daf: Hmm :/
[10:34] <daf> spiv: seemingly because it's trying to connect to a database (launchpad_ftest) which I don't have
[10:34] <daf> spiv: should I have it?
[10:35] <spiv> Yeah, that could use some wikification.
[10:36] <daf> mmm, yes
[10:36] <spiv> Which test is this?
[10:36] <spiv> (And how are you running them?)
[10:37] <daf> python test_on_merge.py -u
[10:39] <daf> just a second, I'll re-run the test
[10:39] <daf> s
[10:41] <daf>  canonical.database.sqlbase.ZopelessTransactionManager
[10:42] <daf> BradB: also, one of the batch tests is failing
[10:47] <BradB> debonzi just changed some of the batching code, i think
[10:48] <BradB> i sure as heck didn't break it though :)
[10:49] <daf> I'll make sure to ask him when I see him
[10:49] <BradB> how that could have gotten checked in though is bad. i /thought/ all the tests were being run.
[10:50] <daf> so did I
[10:50] <daf> seems not
[10:50] <BradB> maybe this problem is local
[10:50] <BradB> because i just got a reject mail the other day when a change i made broke something else
[10:50] <daf> I didn't think so
[10:51] <daf> damn
[10:51] <daf> let me paste the error
[10:53] <BradB> one solution that may end up being the preferred way to go for PT's is to elide all but the page changes that relate to the thing you're testing.
[10:54] <daf> hmm?
[10:55] <BradB> e.g. if you're testing assigning a bug to a package, gen the test, then go in and hack-out (and elide, of course) all but the rendered bits related to package assignment
[10:55] <BradB> that way the data loaded by the other portlets can vary and the test will still pass
[10:56] <daf> hmm
[10:56] <daf> File "/home/daf/src/canonical/dists/launchpad/lib/canonical/lp/tests/batch_navigation.txt", line 42, in batch_navigation.txt
[10:56] <daf> Failed example:
[10:56] <daf>     reindeer_batch_navigator.batchPageURLs()
[10:56] <daf> Expected:
[10:56] <daf>     [{1: 'http://www.example.com/foo?batch_start=0&batch_end=3'}, {2: 'http://www.example.com/foo?batch_start=3&batch_end=6'}, {3: 'http://www.example.com/foo?batch_start=6&batch_end=9'}] 
[10:56] <daf> Got:
[10:56] <daf>     [{'[1] ': 'http://www.example.com/foo?batch_start=0&batch_end=3'}, {2: 'http://www.example.com/foo?batch_start=3&batch_end=6'}, {3: 'http://www.example.com/foo?batch_start=6&batch_end=9'}, {'_last_': 'http://www.example.com/foo?batch_start=6&batch_end=9'}] 
[10:56] <BradB> sounds like something debonzi might know more about
[10:57] <daf> yeah
[10:57] <daf> looks like a deliberate change, though
[10:59] <BradB> that's weird expected output
[11:01] <daf> is it?
[11:01] <daf> makes sense to me
[11:06] <BradB> yeah, that the first key is '[1] ', then second is 2,
[11:07] <daf> that's not the expected
[11:07] <daf> that's the actual
[11:07] <BradB> er, yeah, n/m