[12:03] :-) [12:25] spiv: how do I reopen an IZopeConnection once I've closed it? [12:25] I can't reopen the same object directly, but there must be some way. [12:26] I need to disconnect long enough to drop the db I'm connected to, then reconnect again. === debonzi [~debonzi@200.158.100.251] has joined #launchpad [12:42] BradB: Hmm, I don't know how to do that. The interface certainly doesn't give any way to do it. [12:45] indeed [12:51] carlos: yo [12:52] daf: hi [12:52] daf: spiv found the answer to my question already, thanks :-) [12:55] carlos: ah, good [12:55] carlos: how're you doing? [12:56] well, all bugs I'm working on have dependencies on other people to be finished, out that, fine :-P [12:58] shall we have a quick meeting or is it too late? [12:59] it's 1:00 here and I'm tired, do we need it before tomorrow's meet? [12:59] no, it can wait [12:59] hmmm, in the other side.. will you attend the meeting? [12:59] 12:00 UTC [01:03] yes [01:04] daf: ok, then, could we have the meeting after the launchpad one? [01:04] if it's still necessary, sure [01:05] ok === kiko is now known as kiko-afk [02:19] !Md:*! Hi everybody. Just wanted to let you know that there is discussion and live coverage on this year's US presidential election in #election2004 [02:27] http://paste.husk.org/1910 [02:29] It looks like the exit status is confused. [02:29] Oh, no, hmm. [02:30] test_ok = errlines[-1] == 'OK\n' [02:30] So, apparently, despite the last line of stderr being 'OK\n', there was still a traceback. [02:30] the failure email i got back to me there were 6 failures. from my command line, uh, that just doesn't make any sense at all. === BradB runs the UT's [02:31] s/back to me/back told me/ [02:32] spiv: do the UT's get run by the wya? [02:33] I believe so, yeah. [02:34] i hope not, because otherwise it becomes difficult to explain how a batching failure got checked in [02:35] print 'Running tests.' [02:35] stdin, out, err = os.popen3('cd %s; python test.py %s < /dev/null' % [02:35] (here, ' '.join(sys.argv[1:] ))) [02:35] (from test_on_merge.py) [02:37] Oh, hmm! [02:37] i see stuff like this: [02:37] I think the test_on_merge.py script has a bug :/ [02:37] http://paste.husk.org/1911 [02:38] (when i run the ftests) [02:38] my brain is in the freezer right now, but damn i just wanna land these page tests [02:38] test.py runs several "batches" (for lack of a better word) of tests, but test_on_merge.py only looks for a final "OK". [02:38] That's fine. [02:38] Those are all ok. [02:39] Just a bunch of warnings, but they don't break the tests. [02:39] yeah, it ends in "OK\n", so... [02:39] Right. [02:39] how is "Exception exceptions.AttributeError" "ignored" though? [02:39] It's from a __del__ [02:39] why is that ignored though? :) [02:40] ok, it's outside a test, presumably [02:40] Because it's triggered by the garbage collecter... [02:40] Where would you expect an error in __del__ to get raised to? :) [02:41] i dunno...does it happen in tearDown? [02:41] No idea. Quite likely. [02:42] But __del__ isn't something that's called directly by your code, it's called by python internals. [02:42] that would make sense then. if i just del foo in a test and it raises an error, i'd expect the test to be an error. [02:42] So the exception bubbles up to python's internals, which goes "Oh! Fancy that. I'll make a note of that on sys.stderr and get on with my life." [02:42] but in tearDown, i'd expect it to be ignored. [02:43] heh [02:43] Well, doing "del foo" may or may not cause __del__ to be triggered. [02:43] It's triggered when there are no references left, which can happen for all sorts of reasons. [02:44] I've looked into that particular error, and although the warnings are annoying, I don't think it has an significant sideeffects. [02:46] (so it's not that it's outside a test, it's that it's outside the normal execution path of python code altogether) [02:46] yeah...well that's arse then, my tests end in "OK\n" when I run "make check" locally, but I get 6 failures on the server. [02:47] I think there's possibly a seperate problem, which is that test_on_merge might not notice failures all the time -- I'm not convinced that checking that the end is "OK\n" is sufficient. [02:47] one should be checking $?, not string output [02:47] If that combines with e.g. the server running the tests in a different order to you.... (easy to imagine, you have a different FS, yeah?) [02:47] lifeless: Yeah. [02:47] Actually, I can't figure out if http://paste.husk.org/1910 means everything passed, or means something failed. [02:48] it failed [02:48] BradB: It means something failed. [02:48] there was a traceback. [02:48] BradB: But it means that test_on_merge.py didn't realise it. [02:48] (Due to aforementioned issues :) [02:49] spiv: ...and yet i still got a failure email. [02:50] BradB: Right. But I suspect that if the tests had run in a different order, it would have noticed. [02:50] spiv: What's the exact command pqm runs to check if all the tests pass? [02:51] make check, I believe. [02:51] ouch, pain pain pain === spiv tries checking the return value. [02:55] i'm seeing errors in the PT's though on the server, which is more worrying [02:55] where's the log of the failed test run? the email doesn't give me enough info. [02:55] I don't know; lifeless? [02:56] lifeless: Can we get more detailed failure logs from PQM that what it mails to us? [02:56] define more detailed ? [02:56] lifeless: i wanna see all the failure output [02:57] ok, thats doable. [02:57] rather than "Last 20 lines of log output" :) [02:57] lifeless: for now, where's the file that i can read to see it? [02:57] BradB: there isn't one. [02:57] its mail and toss. [02:57] oh, heh [02:58] my brain's pickled for tonight anyway, but if there's a chance to have that output in the mail for tomorrow, that'd be really good [02:58] I'll see what I can do. [02:58] I plan to add a new command [02:59] so you'll want your command email to have 'debug' on a line on its own. [02:59] that will trigger the output-from-hell mode. [02:59] BradB: I'll see if I can make test_on_merge a little more sensible. [02:59] lifeless: i think we'd probably always want it [02:59] spiv: look at the cscvs make check. [03:00] lifeless: it's only one person that'll get it anyway, so if one person gets an email-from-hell every once in a while, it's no big deal (and they have all they need to figure out what failed on the server.) [03:00] BradB: well, some build processes make a hella lotta output, and kindly do fail at the first error. [03:01] spiv: that'd be nice. :) [03:01] lifeless: In theory, so does this one :) [03:01] I'm not a big fan of no output. "All tests OK." or something would be nice. [03:02] BradB: mmm, for now, you can change your submit-arch-merge to just have debug in there. [03:04] have it where? [03:05] presumably at the end of the body [03:06] echo -e debug\nstar.. [03:06] you'll want it before star merge :) [03:06] oh, ok [03:07] I'll code it up this afternoon, things going well elsewhere. [03:11] Any code that relies on __del__ is broken. There is a Canonical Buzilla bug open on this about SQLObject [03:11] (which is broken) [03:14] (well... probably not broken, since it doesn't rely on it, but damn annoying) [03:31] hi stub, is it possible to update launchpad.ubuntu.com? there are some soyuz stuff missing there [03:34] Sure. I'm not sure now to restart the server though. [03:34] BradB: ping [03:35] yo [03:36] stub, I must go home now.. its realy late.. if you need something else from us please drop me an email.. thanks [03:36] i can restart it if you're ready...or i could just stop it and let you restart it when you want [03:36] How do we restart the dogfood launchpad server atm. Last time you did it, which I suspect means it is running under screen? [03:36] yeah [03:36] see you guys [03:36] see ya [03:37] stub: how 'bout i just stop it now and you do what you want with it? [03:38] Gee... thanks ;) [03:38] heh [03:39] So you just did 'make run' ? If so, kill it and I'll take it over. [03:39] launchpad@rosetta:/srv/launchpad.ubuntu.com/launchpad-dogfood $ make run [03:40] Blergh.... can't run screen as launchpad... :-P [03:40] no, you run it as your normal user :) [03:40] then sudo, etc. [03:40] I was hoping other people could connect until proper start/stop scripts were running :-) [03:42] So the test suite brick walls hurt? [03:42] painful. very painful. [03:43] i was completely boggled by that connection bug [03:43] took me a hell of a long time to find out where the heck the stray connection came from [03:43] Well.. makes me feel better anyway. I wasted two days on it and was wondering if I was just being real stoopid :-) [03:43] which was in the placelessauth service [03:44] i've only wasted about 3/4 of day, and have ready the stage of only being really confused now, instead of completely lost :P [03:44] mmm.... which the rosetta tests were using in conjunction with initZopeless, which seemed rather dodgy... [03:44] s/ready/reached/ # it's affected my typing [03:44] I'll owe you a big sloppy kiss if you can crack it [03:44] heh heh [03:44] if i would have known that today, it'd have taken an hour to fix, no doubt [03:45] stub: you read z3 checkins? [03:46] the "docs" (i.e. functional doctests) for the PAS are just so...discouraging. it's like 95% http session barf and 5% telling the user how to use the PAS. [03:46] I scan them once or twice a week [03:47] If it is http session stuff I should have a look - I've been waiting on people to actually use it to see how it goes :-) [03:48] stub: it's horrid. the concept of functional doctests is brilliant, but i'm starting to think of how better to do it. ideas so far: none. [03:49] "better" i.e. make them actual readable documentation. [03:49] at the end of today i had all the tests passing locally (so i could land the malone forcefield), but somehow 6 fail on the server, and i don't get enough error output back in the email to know what the problem is (so hopefully lifeless have time to fix that by tomorrow.) [03:51] Mmm... my first suspicion is the launchpad databases. Tests may be making assumptions about the databases, but the db's on chinstrap only get updated if 'make check' bothers to do so. [03:52] stub: the ftests should get init'd properly no? [03:52] Are you back for the meeting in 9 hours time? [03:52] (i have no idea how or where, but i thought that just somehow worked) [03:52] 9 hours? :) [03:52] er, crap, yeah, it's only 9 hours from now [03:53] BradB: In theory, yes. However, until recently tests were doing dodgy things like connecting to launchpad_dev (which the test suite doesn't touch, because it shouldn't be using it). [03:53] they still do [03:53] BradB: I think I've got a handle on what you have been chasing, so if you need to skip the meeting go for it. [03:53] i did much watch -n 2 'psql launchpad_dev -c "select * from pg_stat_activity"' today [03:54] Mmm... fragile tests. Once this damn harness is debugged it should be fairly simple to fix the remaining tests (my approach was more brute force - I just dropped the launchpad_dev database and looked at what broke ;) ) [03:55] i got to: http://paste.husk.org/1912 [03:56] in pgsql.py, line 70, setUp [03:56] i just couldn't figure out how to reopen the conn after closing, so everything after that dies [03:58] that's after having first explored the possiblity that it was a problem with our custom publisher, or with the base class that bootstraps individual tests, or with the placeless auth, etc. heh [03:59] Mmm... I had monkey-patched psycopg.connect to give me connections with a 'reconnect' method, allowing me to close them all, drop and recreate the db, and reconnect them. I didn't finish chasing it hrough though. [04:00] why knowing how to say "hey, connect back to the db" didn't come obvious to me (and still doesn't), i'm not sure [04:01] Hmm... looking at that paste, I suspect we are going to have to get the adaptor and poke into its internals Urgh :-( [04:02] Or close it and delete the utiliity, drop the db, and recreate it... [04:03] yeah, that's what i was thinking [04:03] Anyway... I have db patches for kiko and dogfood rollout stuff to do. I won't touch the test stuff today since it would just conflict with your work. [04:03] indeed. i'll take a look again after the meeting tomorrow. [04:04] steve might have some ideas. [04:04] if he'll be there? maybe it's you admining it then. [04:04] I suspect I am, which will be amusing ;) [04:04] heh [04:05] Hmm. That's not a good sign. [04:06] Trying to merge a change to test_on_merge to make it check exit values as well as stderr fails. [04:06] hur hur hur [04:06] And the last line of stderr is indeed "OK" [04:06] dounds like its not quite right :) [04:06] Although FAILED (failures=1, errors=1) [04:07] occurs higher up. [04:07] so, who ever looked at stdout ? [04:07] actuall, I don't want to know === BradB is now known as BradB|away [04:09] BradB|away: And from what I can see in the limited output from PQM, batching does indeed fail. [04:10] spiv: have you looked at the cscvs make check ? [04:10] I've patched unittest to stop on the first error. [04:10] rather than blindly careening off into never never land. [04:10] lifeless: did you follow the dogfood rollout thread? I was going to create a configs directory in launnchpad--devel--0 for build-config files so we can just to 'tla get launchpad--whatevver--0 whatever; cd whatever; tla build-config configs/whatever'. Sane or stoopid? [04:10] stub: we have 'dists' for that. [04:11] what would be different ? [04:11] lifeless: The difference would be that the rollout build-config files would be version controlled with the codebase. [04:12] I'm confused, I don't see what you mean. [04:12] (well... at least all the stuff in the launchpad package - pyarch and a few others are seperate). [04:13] pyarch, cscvs, zope, sqlobject, sqlos, pyscopgda [04:13] buildbot [04:13] twisted [04:13] I could just do 'tla get launchpad--dogfood--0.6' and I would have the build-config file that listed all the revisions of the 3rd party tools that were rolled out with it. [04:13] python [04:13] stub: so, what is different to 'tla get dists--devel--0', 'tla buildconfig configs/canonical/launchpad/dogfood--0.6' ? [04:14] have you looked at the production-* configs in 'dists' ? [04:15] lifeless: That would work, although doesn't lend itself to automatition. If instead of using versions we just used 'launchpad--dogfood--0', we could do an automatic update of the dogfood server (cron job just does 'tla get launchpad--dogfood--0; tla build-config' and it all magically works...) [04:15] right, so you just do that with configs/canonical/launchpad/dogfood [04:15] New bug 2155 for Launchpad/Launchpad: test_on_merge.py doesn't check exit status, and thus ignores failures. [04:15] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2155 [04:16] its as automatible. [04:17] I have several production configs, so that I can roll back trivially, but if you just have one, that will work just as well. [04:17] ok - I see that now. We just have to list the explicit revision of launchpad--dogfood to allow us to easily retrieve historical revisions. [04:17] in fact, its more automatable. [04:17] lifeless: The problem isn't unittest. The problem is the script that runs the test script fails to interpret the results of that script correctly (i.e. it ignores the exit status) [04:17] spiv: I was meaning for reducing the output to sane lengths :) [04:18] lifeless: Oh, right. I'm not particularly concerned by long output :) [04:18] stub: its more automatable because a dogfood config can hold you at a specific level in the dogfood branch, if something is wrong with newer revisions. [04:19] so your release process would be: get the code ready, then generate the config to a dists tree that you merge with rocketfuel. [04:19] done. [04:19] tla logs -rf | head -n 1 gives you a tree revision. [04:22] how does that sound to you ? [04:22] tla inventory --nested -t gets you the trees [04:23] lifeless: we don't want it to stop on the first failure [04:23] Sounds like a winner. I think the '--dir' option to build-config solves controlling where the checkout goes which is also good. [04:23] tla inventory --nested -t | xargs bash -c "tla logs -d $0 -rf | head -n1" or similar gives you the config [04:23] stub: erm, no. [04:23] the -d says where to go to get the configs [04:23] the config says how its checked out under there. [04:23] stub: failing UT's are allowed to sneak by the checker, it seems [04:23] so you just build the config to match your checkout desires. [04:24] BradB|away: Sod [04:24] BradB|away: K. [04:24] stub: just a guess, but it's because a failing UT doesn't affect the fact the last line can still be "OK\n" [04:24] since the FT's run last [04:25] AFAIK [04:25] BradB|away: its simpler: checking stdout is not a reliable process for interrogating the test routines. [04:26] indeed [04:26] I guess so. Problem is we can't really fix it until the tests all pass ;-) [04:26] hehehe [04:26] I think Steve designed makeoncheck to just work with page-tests [04:27] I could just force the merge in. [04:27] of course, you couldn't commit anything else until the tests pass. [04:27] Bad lifeless - bad! [04:27] :) [04:27] technically, I'd be fixing a bug. === BradB|away goes on a late night grocery run [04:28] I'll change my 'enforce explicit FROM clauses' warning to an error at the same time :-) [04:32] BradB|away, stub: see bug 2155 :) === doko [doko@dsl-082-082-065-116.arcor-ip.net] has joined #launchpad === mdz [~mdz@69-167-148-207.vnnyca.adelphia.net] has joined #launchpad [05:31] stub: did steve say you're officially "chairing" the meeting tomorrow then? [05:32] if so, and i don't need to be there, maybe i'll wake up at a more reasonable time, like 8:30, instead of 6:30, heh === sabdfl [~mark@196.38.108.242] has joined #launchpad [05:35] hi all [05:35] what's news at the launchpad? [05:39] meeting tonight, dogfood rollout today, people working on the more fragile aspects of the test suites [05:40] production schema update was run yesterday, as lifeless did a production code rollout. [05:41] gina seems to need some lovin' to get it to import the Hoary archive [05:42] stub: thanks [05:43] i'm in back to back meetings all day through to post-dinner, so will try get an update from you again in your morning [05:43] no worries :-) [05:44] sabdfl: gnu arch issue resolved, in flying colours. [05:45] lifeless: good job [05:45] I've emailed you the outcome, can you please ok that for elmo to act on ? [05:58] lifeless: i'm way behind on email, just get a couple of minutes each day this week, please fwd this irc comment to elmo [05:58] if he needs the nudge [05:59] sabdfl: Now that you have delved into the Z3 form machinery stuff, do you think we need to do work to improve Z3 in this area? The December conference could be an opportunity to hold a Z3 sprint if Garrett Smith is interested in coming (we would need to fund him). [05:59] sabdfl: ok. [05:59] elmo: please get the arch community servers up for jblack asap, we discussed it in october and i never heard anything to suggest they would not be ready for the termination of jblack's bandwidth, we need to get them up and running at once [06:00] stub: yes, some small tweaks [06:00] but i may not have unlocked the full power of z3 [06:01] for example, i noticed you created an IMaloneBugAddForm schema [06:01] so you could do more than just create a bug [06:02] that seemed unnecessary to me but i couldn't easily find a way around it [06:03] Mmm.... that one doesn't particularly worry me. The form machinery simply generates forms based on a specification. In most cases, that specification already exists in the form of an existing interface so we get used to it being magic ;) [06:05] I'm more concerned with the dead-chicken functions I had to add to the containers to get the addforms working - that seemed to be simply because they were designed to add persistent objects as children of ZODB folders. It works the way we have done it, but seems to be a hack. [06:08] Should I approach Garrett (who didn't write the form machinery, but has been the person most actively involved in championing and refactoring the implementation over the last 12 months) to see if he is interested in coming to Barcelona? [08:28] Merge to rocketfuel@canonical.com/launchpad--devel--0: soyuz views (patch-725) [10:00] lifeless: ping [10:31] !Md:*! rehubbing in progress === netjoined: irc.freenode.net -> sendak.freenode.net === ChanServ [ChanServ@services.] has joined #launchpad === doko [doko@dsl-082-082-065-116.arcor-ip.net] has joined #launchpad === ddaa [~ddaa@nemesis.xlii.org] has joined #launchpad === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad === spiv [~andrew@fuchsia.puzzling.org] has joined #launchpad === daf [daf@muse.19inch.net] has joined #launchpad === dilys [daf@muse.19inch.net] has joined #launchpad === lifeless [~robertc@dsl-78.1.240.220.rns01-kent-syd.dsl.comindico.com.au] has joined #launchpad === netjoined: irc.freenode.net -> sendak.freenode.net === ChanServ [ChanServ@services.] has joined #launchpad === doko [doko@dsl-082-082-065-116.arcor-ip.net] has joined #launchpad === ddaa [~ddaa@nemesis.xlii.org] has joined #launchpad === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad === spiv [~andrew@fuchsia.puzzling.org] has joined #launchpad === daf [daf@muse.19inch.net] has joined #launchpad === dilys [daf@muse.19inch.net] has joined #launchpad === lifeless [~robertc@dsl-78.1.240.220.rns01-kent-syd.dsl.comindico.com.au] has joined #launchpad === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad === debonzi [~debonzi@200.158.100.251] has joined #launchpad === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad === elmo is now known as elmo_away === cprov [~cprov@200.158.100.251] has joined #launchpad === Kinnison [~dsilvers@haddenham.pepperfish.net] has joined #launchpad [11:31] Morning [11:32] Meeting in 1h30m yes? [11:33] Kinnison, yep [11:33] morning debonzi [11:34] debonzi: how does the db on mawson look? gina finished an import yesterday [11:34] Kinnison, morning [11:34] there were some failures so I'm investigating those [11:34] Kinnison, it seems to be very nice, but the soyuz code still need to be update.. [11:35] stub, did the soyuz update failed? [11:35] stub, better, the launchpad.ubuntu.com update [11:39] debonzi: I see. Well; I'm glad the data looks okay [11:40] Kinnison, me too :-) [11:43] Kinnison: may I run Nicole over it ? [11:43] cprov: as far as I'm concerned; yes. I certainly have no intention to start deleting data :-) [11:52] Kinnison: ok in some minutes [11:59] You can see the output of the latest top-up run of gina in /tmp [11:59] I'm going through trying to work out why some packages fail to import properly [12:00] Kinnison: should I backup the the lp_dogfood DB before start ? [12:00] cprov: probably worth it; in case nicole breaks horribly === carlos_ [~carlos@69.Red-80-33-181.pooles.rima-tde.net] has joined #launchpad === carlos_ is now known as carlos [12:10] Merge to rocketfuel@canonical.com/launchpad--devel--0: general templates fix; related with bug #2089. Authorization required for +edit soyuz pages (patch-726) === Kinnison does another gina run; don't worry guys; this won't break anything; I need more debugging output :-) [12:14] debonzi: the launchpad.ubuntu code drop hasn't been done yet. [12:14] stub, right.. [12:14] Kinnison: do you know why restoring a dump from lp_dogfood fails (psql soyuz_tmp -f lp_df-20041103.sql) ? [12:14] Kinnison: Do you need launchpad_dogfood for this run? Or can up upgrade now? [12:14] stub: I'm running gina out of ~ I only need the db [12:15] cprov: Nup; sorry [12:15] stub: I can cancel the run if you want; I'll have enough data by now to carry on fidding [12:15] keep it going for the time being [12:16] Kinnison: does it works for you ? how did you copy the DB ? [12:16] cprov: copy the db? [12:18] Kinnison: I want to run Nicole in a copy of launchpad_dogfood [12:18] I see [12:20] Kinnison: so, any suggestion ? [12:21] I'd probably do something like: createdb -E UNICODE -t template0 ; lp_dump launchpad_dogfood | psql [12:30] Kinnison: yes :) "createdb -E UNICODE -T launchpad_dogfood soyuz_df" should work for me, but the DB is being accessed by other users [12:31] cprov: which is why I suggested my way [12:35] urgh.... the hourly dump is trying to create the functions used as constraints *after* the tables :-P [12:35] Kinnison: psql -f always fails [12:36] cprov: Hmm [12:37] cprov: Not sure what to suggest. stub is our database stud :-) [12:42] ok - disabling triggers works. I'll update the latest hourly dump. [12:42] how is going the bugzilla -> malone move? === morgs [~morganc@wblv-249-229.telkomadsl.co.za] has joined #launchpad === Kinnison goes to do a few bits before the meeting === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad [12:53] stub: I can't use the hourly dump to generate my own (tmp) lp_dogfood, I got "invalid command \N", does it means something to you ? [12:54] Yes - I'm looking at that now. Creation of the tables is failing, as the dump has decided to create functions the tables need *after* the tables. [12:55] If you create a freshdb and run database/schema/trusted.sql in it, the restore should work [01:00] stub: psql:trusted.sql:13: ERROR: language "plpythonu" does not exist [01:01] createlang plpythonu mydbname [01:02] I hope it isn't a postgresql upgrade problem - the dumps are in the correct order on my local box ;-/ [01:02] Anyway.... [01:02] who is here! === spiv waves [01:03] stub, yes [01:03] I believe I am acting Steve for this meeting unless anyone else feels like volunteering ;) [01:04] I'm also acting BradB who won't be joining us === carlos is here [01:04] daf: ping [01:05] stub: do the USA people change the hour like we did this weekend? [01:05] stub: the restore seems to be working === Kinnison is here === morgs is here [01:07] carlos: IIRC USA goes forward one week later; comes back the same time [01:07] Mmm... I'm now at UTC+11 now btw. [01:07] so it's 11pm for you? yowch [01:08] better than UTC-11 I guess :-) [01:09] carlos: Are you able to give a short state-of-rosetta? [01:09] stub: I could try, but I only know the status of my work [01:10] daf: told me that he is going to attend the meeting [01:11] ok. We can wait to see if daf comes online in a tick. [01:11] but I think that perhaps he will be late [01:11] ok [01:11] As for Malone, work has been progressing on dogfood-for-launchpad, in particular email notifications. Brad has also been beating his head against test harnesses so he can land a full suite of page tests. [01:11] I'm sure people who have been playing with it have noticed usability issues - please submit them as bugs in the dogfood malone, or in Bugzilla if that fails. [01:12] BradB wants to get the Ubuntu people on board with it as soon as possible, but I feel a little more conservative and want to concentrate on the launchpad group. Maybe we can do both. [01:13] can we make the default https://launchpad.ubuntu.com/ use the port which gives tracebacks to the browser? [01:13] stub: are we able to use malone for launchpad bugs then? [01:13] Kinnison: That would be a great idea [01:13] carlos: I filed 3 bugs against malone in malone yesterday :) [01:13] Kinnison, I agree with you [01:14] Does the dogfood malone do emails yet? [01:14] Kinnison: I'll try and do that when I drop a fresh snapshot in, which I'll do after this meeting if enough Gina data has been collected or people don't want to wait another 9 hours [01:15] stub: feh; anyone would think you thought gina was slow :-P === kiko [~kiko@200-206-134-238.async.com.br] has joined #launchpad === Kinnison notes that the collection run I started earlier has actually finished! [01:16] spiv: but we don't have (yet) the old bugs imported, so i cannot use it yet [01:16] spiv: The code is all there for notifications, but no incoming email. It is currently switched off though - I will want to clear it with Brad before switching it on, as a screwup could spam Mark (default owner of a lot of things) or elmo (as the postmaster) [01:17] Kinnison: I was talking about when I wake up tomorrow. Hopefully gina will be finished by then ;) [01:17] stub: oh righty. I'm happy for you to upgrade the software; no question [01:17] stub: Fair enough. The reason why I ask is that if launchpad devs are going to have to deal with two seperate bug systems at once, I fear the dogfood one will be forgotten unless it sends emails. [01:18] stub: if you have to reset the db; gina will have to run again; which might suck [01:18] spiv: Good point. [01:18] stub: But importing bugzilla bugs into malone would fix that as well, I guess. [01:19] At the moment, I don't think we have any import code. I need to talk to elmo about switching off basicauth on the Canonical bugzilla (from Mawson's IP) so we can watch bugs though. [01:19] If it is a problem, we can talk to kiko or justdave about a quick'n'dirty import script. [01:20] talk to me [01:20] what's up? === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad === carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net] has joined #launchpad === Kinnison [~dsilvers@haddenham.pepperfish.net] has joined #launchpad === cprov [~cprov@200.158.100.251] has joined #launchpad === debonzi [~debonzi@200.158.100.251] has joined #launchpad === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad === doko [doko@dsl-082-082-065-116.arcor-ip.net] has joined #launchpad === spiv [~andrew@fuchsia.puzzling.org] has joined #launchpad === ChanServ [ChanServ@services.] has joined #launchpad === kiko [~kiko@200-206-134-238.async.com.br] has joined #launchpad === ddaa [~ddaa@nemesis.xlii.org] has joined #launchpad === daf [daf@muse.19inch.net] has joined #launchpad === dilys [daf@muse.19inch.net] has joined #launchpad === lifeless [~robertc@dsl-78.1.240.220.rns01-kent-syd.dsl.comindico.com.au] has joined #launchpad === daf [daf@muse.19inch.net] has joined #launchpad === lifeless [~robertc@dsl-78.1.240.220.rns01-kent-syd.dsl.comindico.com.au] has joined #launchpad [01:28] And then kiko just walked out of the room! === Kinnison grins [01:28] !Md:*! this was the scheduled outage... === kiko_ [~kiko@200.206.134.238] has joined #launchpad === sabdfl [~mark@196.38.108.242] has joined #launchpad [01:28] ok... I think we have everyone back. [01:29] sabdfl: Greetings. Just intime for the next netsplit [01:29] :-) [01:29] launch here in a few minutes, so wont likely be able to enjoy the fun [01:29] sabdfl: good luck [01:30] anyone need mark luvin' while he is here or shall we move onto soyuz? [01:31] sorry, something happened :) === kiko_ has no idea what [01:33] kiko_: Just remember that IRC was designed by a pack of drug induced hippies over a decade ago. [01:33] what wasn't? [01:33] and has been perpetuated by weenies ever since [01:33] you could say the same of tcp/ip I suspect [01:33] and BSD [01:33] ban it all I say [01:34] let's all use appletalk [01:34] ! [01:34] stub: I just can see the CSV style import from bugzila and it just import a query not a bug [01:34] Kinnison: So what is the status of Gina - is it now importing hoary on mawson, or is that what is currently being worked on? [01:34] stub: gina has imported a nearly complete hoary archive [01:35] stub: I'm working on the few corner packages left making sure that gina is doing the right thing [01:35] So is the end in sight, and are there any blockages? [01:35] stub: then I'll get the last twiddles done for the corner-case of package versions moving between distroreleases which I've spotted [01:36] Once that corner-case has been solved; we should be able to repopulate the sourcepackagerelease tables on demand via gina [01:36] No major blockages that I can see [01:36] Just gotta keep slogging [01:36] excellent. [01:37] the dogfood db contains a workable-with set of data and I believe cprov is going to get nicole going on it today [01:38] Nicole works perfectly on soyuz_df at 50/1033 packages of Hoary/Main should I stop and run it on lp_dogfood ? [01:38] cprov: And is nicole ready to chew on the data? [01:39] stub: yes, I think [01:40] ok. So the soyuz dogfood environment will have lots and lots of stuff to play with [01:41] kiko_, debonzi, cprov: Anything you need to tell us about soyuz? [01:41]