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