[12:03] heh, then I guess someone needs to write delayfs [12:03] sounds like a good idea actually [12:04] delay underlying fs operations untill timeout ;-) [12:04] baz is fook-fast in a ramdisc [12:04] that was an intelligent joke I guess... [12:04] "benchmark how your code behaves with incrementally worse filesystem performance". [12:05] huzzah, gina run on dogfood almost finished. only 13 failed binarypackage imports [12:05] and some of those are due to sources which couldn't be imported rather than couldn't be found === rbelem-afk [n=rodrigo@200.246.97.164] has joined #launchpad [12:05] Kinnison: I guess the failures include the kernel, OOo, Mozilla, and gcc? [12:06] like the bits that nobody uses anyway... [12:06] heh [12:06] fixing those packages is left as an exercise for the reader ; [12:07] Enough talk, I need to get more fixes in for the samba import. [12:07] ddaa: zope3 (for zope3-lib) [12:07] SVN BUGS ARE FUTILE, YOU WILL BE IMPORTED! [12:08] (actually, I'm unfair, these are cscvs and pysvn bugs, not svn's fault) [12:08] ddaa: gcc-2.95 (oddly) [12:09] ddaa: some ruby crud, and a d-i manual [12:09] pretty good [12:09] and a few whose SPs won't import due to version number h0rkage === Kinnison needs to fix launchpad to accept the versions first [12:12] Kinnison: I propose the upstream theorem === Kinnison looks blankly at ddaa [12:12] For any value of upstream, upstream does stupid things. [12:12] Heh [12:14] 20:49:08 WARNING Sourcepackage openoffice.org2 (1.9.125-1ubuntu2) (1.9.125+2.0beta2-1ubuntu2) not found for openoffice.org2 (1.9.125+2.0beta2-1ubuntu2) [12:14] that's the annoying one [12:14] I can see no reason why that failed [12:14] I knew it :) [12:14] especially since earlier in that run it imported 1.9.125-1ubuntu2 === camilotelles [n=Camilo@20132139198.user.veloxzone.com.br] has joined #launchpad === Kinnison thinks he's spotted a way to fix another six or so of these failures [12:34] Merge to rocketfuel@canonical.com/launchpad--devel--0: [r=Keybuk] fix #2361. make bugmail From: be the address of the person who made the change, Reply-To: be the bug address, and Sender: be the LP-wide bounce address. (patch-2460: brad.bollenbach@canonical.com) === Kinnison realises he hasn't taken a workrave break all week [12:48] bloody thing is suspended === Kinnison rants === bradb [n=bradb@modemcable033.209-70-69.mc.videotron.ca] has left #launchpad [] === ddaa kicks another local samba import after fixing two new bugs today, and heads for bed === sivang hits bed [01:13] good night all [01:24] 1000 27048 24.1 27.3 1216676 1080420 ? Ssl Sep21 165:39 \_ python /srv/launchpad.net/production/launchpad/cronscripts/rosetta-poimport.py -q [01:24] you guys know about that, right? :P [01:31] elmo: That's exciting. [01:32] Good thing hardware is so cheap ;) [01:35] Woohoo, another six SPs imported okay [01:35] only 7 left unimportable [01:35] at least one of which truly is missing [01:37] two... [01:38] dunno wtf to do about one of 'em [01:38] so two are missing [01:38] one is bizarre [01:38] and the other four are because of version numbers === Kinnison bounces [01:38] much better [01:39] elmo: zope3 and qdvdauthor (both universe) both lack source [01:40] qdvdauthor | 0.0.10-0.1 | breezy/multiverse | source [01:40] qdvdauthor | 0.0.10-0.1 | breezy/universe | amd64, i386, powerpc [01:40] zope3 | 3.0.93-1 | breezy | source, amd64, i386, ia64, powerpc, sparc [01:40] no they don't? [01:41] Why is the source in multiverse but the binaries in universe? (for qdvdauthor)? [01:41] they shouldn't be; I've fixed that [01:41] but source in one component, binaries in another is generally valid [01:41] it's very common for source to be in main and binaries to be in universe, f.e. [01:41] aye, but we weren't importing multiverse at all [01:42] which was the snag there I guess [01:42] launchpad@mawson:/srv/launchpad.ubuntu.com/dogfood/launchpad$ ls /srv/archive.ubuntu.com/ubuntu/pool/universe/z/zope3/* [01:42] /srv/archive.ubuntu.com/ubuntu/pool/universe/z/zope3/zope3-doc_3.0.93-1_all.deb [01:42] /srv/archive.ubuntu.com/ubuntu/pool/universe/z/zope3/zope3-lib_3.0.91-1ubuntu1_amd64.deb [01:42] /srv/archive.ubuntu.com/ubuntu/pool/universe/z/zope3/zope3-lib_3.0.91-1ubuntu1_i386.deb [01:42] /srv/archive.ubuntu.com/ubuntu/pool/universe/z/zope3/zope3-lib_3.0.91-1ubuntu1_powerpc.deb [01:42] Kinnison: pool/universe/ [01:42] Kinnison: try pool/main/ [01:42] aye, they're different versions [01:42] that which was in main has been imported fine [01:42] so 3.0.93-1 is fine [01:43] 3.0.91-1ubuntu1 however (zope3-lib) is failing to import [01:43] I'm guessing it's a dangling binary [01:43] /srv/ftp.no-name-yet.com/ftp/pool/main/z/zope3/zope3_3.0.91-1ubuntu1.diff.gz [01:43] /srv/ftp.no-name-yet.com/ftp/pool/main/z/zope3/zope3_3.0.91-1ubuntu1.dsc [01:43] looks fine to me? [01:43] bizarre === Kinnison looks [01:43] seriously - i know there are flaky parts of the katie, but the source reference counting is NOT one of them [01:43] I believe you === Kinnison glares at this [01:43] oh one last one which is confusing me: [01:44] 23:23:56 WARNING Sourcepackage debian-installer (20050317ubuntu15.0.200509200) not found for debian-installer-manual (20050317ubuntu15.0.200509200) [01:44] heh [01:44] blame lamont [01:44] is that a bizarro bin-nmu or something? [01:44] they're exploiting the lax bin-only NMU checks to do daily d-i builds [01:44] yes, basically [01:45] why is the Source: line wrong then? [01:45] is it? currently we don't have a bin-only NMU version but a real one in the archive [01:46] dunno because this is an archive from 4am [01:46] Package: debian-installer-manual [01:46] Source: debian-installer [01:46] Version: 20050317ubuntu15.0.200509200 [01:46] yeah, ok the source is wrong [01:46] I guess it's an artifiact of how lamont's script works [01:46] okay [01:47] you may be able to get him and/or infinity to fix it [01:47] right === kiko [n=kiko@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === salgado [n=salgado@201-1-132-73.dsl.telesp.net.br] has joined #launchpad === stub [n=stub@203-214-4-72.dyn.iinet.net.au] has joined #launchpad [02:36] stub! [02:36] yo [02:36] what patch number should I use for my basic-voting branch? [02:39] I havn't seen the patch yet, have I? [02:40] stub: that patch to drop the unique constraint in Vote.token [02:40] If that is the only change, I'll pre-approve it and give you patch number 25-29-0 [02:41] stub: this is the patch: https://chinstrap.ubuntu.com/~dsilvers/paste/fileSwV5Uo.html [02:45] salgado: That looks fine. Approved - 25-29-0 [02:45] cool. thank you [02:58] can somebody kick launchpad. It's still b0rken and hanging on page load [03:36] Merge to rocketfuel@canonical.com/launchpad--devel--0: Simple and Condorcet polls (although the latter is disabled for now) for teams. r=BjornT (patch-2461: guilherme.salgado@canonical.com) === hub__ [n=hub@toronto-hs-216-138-231-194.s-ip.magma.ca] has joined #launchpad === zakame [n=user@210.213.79.103] has joined #launchpad [04:55] hello all! [04:55] is there a prob? I'm getting a 502 when posting translations at rosetta === iandexter [n=iandexte@203.131.67.205] has joined #launchpad [05:41] spiv: Librarian connections appear to be working differently than they used to. It used to keep about 10 connections open, and now it only opens connections when it needs them. [05:42] Is this fallout from the transaction debugging, and does it mean the Librarian should no longer need bouncing after a database outage? [05:44] stub: Yes and maybe. :) === Denjira [n=iJeff@modemcable250.77-81-70.mc.videotron.ca] has joined #launchpad [06:36] Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] Ensure specialized log handlers work for the root logger too and merge in production db patch (patch-2462: stuart.bishop@canonical.com) === GoRoDeK [n=gorodek@p5083D33A.dip.t-dialin.net] has joined #launchpad === blog- [n=fy@202.158.74.179] has joined #launchpad === blog- [n=fy@202.158.74.179] has left #launchpad [] === buntuX [n=fy@202.158.74.179] has joined #launchpad === robitaille [n=robitail@d154-5-117-228.bchsia.telus.net] has joined #launchpad === jamesh [n=james@203-59-207-160.dyn.iinet.net.au] has joined #launchpad [08:40] should I be getting forbidden on this page? https://launchpad.net/malone [08:41] nope [08:42] it is because that page is trying to display a bug that is private to you [08:42] it's a bug [08:42] BjornT: around? [08:43] I get when I click on the bug tab on one of my bugs [08:44] we'll get it fixed shortly [08:48] cheers [08:55] Burgundavia: We already have a fix. It will be rolled out next Tuesday. [08:55] i don't think that's good enough. i'm cooking up an instant fix. [09:03] stub: i have a minimal patch to production to fix the malone front page [09:04] SteveA: Branch, commit and email me and lifeless the branch [09:04] it's two lines in one .pt file. can't i just log in and surgically change the file? ;-p [09:05] SteveA: Only if you want the fix nuked the next cherry pick [09:05] BORING [09:07] https://chinstrap.ubuntu.com/~dsilvers/paste/fileoOQjDF.html [09:07] there's the fix. i'm making a branch... [09:08] You can do both if you want [09:10] Burgundavia: try malone now please. [09:10] works now [09:11] thanks for the quick fix [09:11] cool, thanks for reporting it. [09:14] stub: my archive is still mirroring, but i've mailed you and lifeless [09:14] ok. [09:18] stub: do you know why when i run the launchpad tests, i get various lines of stuff on stderr? [09:18] is this the root logger sending these things out? [09:19] this happens when i run a subset of tests, like python test.py canonical [09:19] I would need to see an example [09:19] 18:44:10 WARNING The plural form header has an unknown error. Using the default value... [09:20] 18:43:01 CRITICAL ***** Missed Dependency build needs manual intervention due MANUALDEPWAIT ***** [09:20] Not necessarily the root logger - could be any logger [09:20] 18:40:49 ERROR http://localhost:9000/cchangelog.html [09:20] -> http://localhost:58000/36/36/tHq2ia1dvmO00LvrJ3M4seoSBnh.txt [09:20] it kinda hoses my dream of having a test suite with clean output ;-) [09:21] it would be quite possible to install a handler I think to catch tests that emit log messages and raise an exception. [09:21] okay, i'll ask for culprits in the meeting [09:22] That last one is interesting, as it indicates a subprocess is being run without redirecting stdout/stderr (and monitering it to ensure the output is what is expected) [09:22] i don't think the last one is for a subprocess [09:23] that's a just a page not found, a page test of a page that doesn't exist [09:24] i want to write some kind of test for the "shut down the socket if there are too many pending tasks" stuff [09:24] i found that in the example i sent you, for some reason, it isn't really running with multiple task threads [09:24] It is from a subprocess, as the only thing that installs the 'log exceptions to the librarian' is canonical.launchpad.scripts.logger [09:25] Unless there is something really screwy going on [09:26] i want to check we're running launchpad with the proper number of concurrent tasks, and also shutting down the socket and re-opening it as appropriate [09:26] a pagetest won't do, because this needs to be running outside of launchpad [09:27] so i thought of the following: have two pages on the debug layer; one that when rendered hangs until some global changes value, another that changes the value. have these pages log progress to some file. [09:29] then, have the tester clear the file, run launchpad, get several of the "first page" pages with a second delay between gets, until the connection is refused. check the connection is refused a few times. then, get the second page. [09:29] aha.. here's where my logic fails [09:29] because of course the second page isn't accessible [09:29] so instead, have the first pages look at a file on the filesystem [09:30] have the file absent, and when it appears, have them continue [09:30] Can we just have a page that interrogates the Zope internals and reports? That might be good enough (although it doesn't prove that Z3 is working as it says it is, that should really be fixed by adding tests upstream) [09:30] well... [09:31] the problem is that we're testing the case when we want zope to not respond to queries [09:31] we could query the page on the production port, and test it on the debug port, i guess [09:32] i don't want to put a "wait indefinitely" page up on production, for obvious reasons [09:32] the ++etc++process stuff does something like this, i think [09:32] I don't see a problem if it is protected. Anyway, your test could install it by adding a view. [09:33] Unless you need to run a real Z3 instance [09:33] i need to run a real z3 instance [09:33] i could install these pages as overrides [09:33] so they'd exist only for the purposes of this test [09:33] Indeed, or even pages that are only loaded in the test environment [09:34] it wouldn't run in the test environment [09:34] The config machinery supports that right now [09:34] it would be a special "test the behaviour of the whole server" test environment [09:34] so, not a regular test environment === stub is confusing himself [09:38] You should be able to test the 'don't accept more than n simultanous connections' code without running an entire Z3 instance, by just configuring and starting up a minimal HTTP server. I'm not sure why you need to worry about multiple threads when the only thing that needs its behavior tested is the HTTP server. [09:39] I'm worried that a test fixture that fires up an entire Z3 instance for poking at will make for flakey tests (the page tests are bad enough at that already) [09:39] not intending to run this test in the test suite [09:39] more for special diagnosis [09:40] as no application code will affect it [09:40] i'm concerned that we aren't really running multiple threads in production [09:40] i guess i could give it a one off manual test [09:44] I'm pretty certain we are running multiple threads because a bad rosetta page can lock up all four of them (and I can see what they are trying to do on emperor) [09:45] okay [09:45] does (FALSE OR TRUE) make any sense in sql ? [09:49] SteveA: most definately running multiple threads, we've seen them when debugging hangs === hub__ is now known as hubZzz [09:51] ok [09:52] SteveA: No - that only makes sense in Python [09:52] ok [09:54] is the "abort lengthy requests" code running on staging? [09:57] SteveA: The code might be there, but it isn't turned on. [09:57] can we turn it on for staging soon please [09:57] I'll refresh it [09:58] what timeout do you recommend? [09:59] hmm... got a major 500 from https://launchpad.net/malone/bugs/2491 just now [09:59] looks like an apache page [09:59] so maybe pound is down === the_bughunter [n=ivoks@backup.grad.hr] has joined #launchpad [10:03] SteveA: No - launchpad is accepting connections and not doing anything with them again. So pound is passing the requests through and never returning, so Apache gives up eventually [10:03] arse === carlos [n=carlos@243.Red-83-47-24.staticIP.rima-tde.net] has joined #launchpad [10:03] can you cherrypick the "max requst length" stuff? [10:03] I think I should cherry pick that code into staging? [10:03] heh [10:04] morning [10:04] let's bang on it in staging now, and get it to production asap [10:04] i was about to start work on getting the "socket shutdown" stuff into lp [10:04] i can aim it at production, if that'll help things [10:04] probably very little in this code, though === dand [n=dand@gw.datagroup.ro] has joined #launchpad === mvo [n=egon@ip181.135.1511I-CUD12K-01.ish.de] has joined #launchpad === the_bughunter is now known as ivoks [10:26] hm, malone gives me a 502 proxy error when I try to update some bug info in malone. is that a known issue? [10:28] nice note guys :) [10:28] Launchpad is offline at the moment for maintenance. It should be back, better than ever, soon. [10:40] is it only me or lp runs on speed of light now? [10:44] ivoks: Enjoy it while it lasts - it is having issues :-/ [10:44] SteveA: Latest code is running on staging [10:45] stub: what's the timeout? [10:45] 2 seconds === ddaa [n=ddaa@ordo.xlii.org] has joined #launchpad [10:49] ok [10:49] can you run a linkchecker over it and see which pages fail? [10:52] Hey SteveA, read the message I left for you in the backlog yesterday about FewerBazConflicts and today's agenda? [10:56] it can be on the agenda [10:56] Thanks. [10:58] SteveA: I've had linkchecker off for a while. It just can't cope with the number of URLs on launchpad at the moment and leaks RAM so it never completes [11:09] how about just running wget on it in mirror mode? [11:17] Morning === zyga [n=zyga@chello084010027057.chello.pl] has joined #launchpad === lamont [n=lamont@dhcp-sn38-07.hrz.uni-oldenburg.de] has joined #launchpad [11:29] SteveA: I could do that. No idea if it will ever finish. === lamont [n=lamont@dhcp-sn38-07.hrz.uni-oldenburg.de] has joined #launchpad [11:29] doesn't matter, provided we get a log with pages that time out in it === mdke [n=matt@unaffiliated/mdke] has joined #launchpad === mdke_ [n=matt@81-178-213-166.dsl.pipex.com] has joined #launchpad [11:41] Bah - I can't drive wget [11:41] SteveA: hi. i'm back now [11:42] BjornT: hi. i was going to ask about the malone front page. but i fixed it anyway. [11:42] https://chinstrap.ubuntu.com/~dsilvers/paste/filebhDT1c.html === WaterSevenUb [n=WaterSev@azevedo.astro.up.pt] has joined #launchpad [11:43] WaterSevenUb: morning [11:43] SteveA: ok, thanks [11:43] zyga, 'morning ;-) though..still sleeping [11:44] stub: that is lame. try pointing it at +index [11:44] That gives me a 404 :-( [11:46] 127.0.0.1 - Anonymous [22/Sep/2005:10:44:30 +0100] "HEAD /++vh++https:staging.ubuntu.com:443/++/+index HTTP/1.1" 404 214 "" "Wget/1.9.1" === carlos leaves to the University [11:48] will be back in about one or two hours [11:48] Oh - I think the issue is wget trying to create local files. [11:48] Despite me not wanting it too :-/ [11:57] stub: i have a diff i want you to review. it is small. [11:58] it is adding a facility for a "launchpad will be going down for maintenance in X minutes" message [11:58] wget -o spider.out -S -O /dev/null -r https://staging.ubuntu.com/ seems to do the trick, although the output isn't particularly parsable it should do [12:09] salgado can do a version of the template on the shipit layer to say "shipit" rather than launchpad [12:10] stub: mailed you a small diff [12:17] SteveA: You say 'root', but all the code looks for the file in the current working directory. What provides the guarantees that this will always be the launchpad root? [12:18] launchpad doesn't run if you don't run it from the root [12:18] it would be better to make this control file a config option, though [12:18] that way, you can have different control files for different processes on the same codebase [12:18] There is already config.root if you want to use it [12:19] having the filename explcicitly in the config would make it more discoverable [12:20] what do you want me to do? [12:20] is it resultset.count() to get the COUNT(*) ? [12:23] SteveA: That all looks fine, although you should attempt to remove os.system from your brain and embrase subprocess.call instead. [12:23] SteveA: So merge it. [12:23] So do we have someone maintaining the production systems who actually keeps to a schedule now? [12:24] okay. i'll set up the shipit version, and then merge it. [12:24] dunno, but even given 10 mins notice will be a great improvement [12:24] it will stop people from entering stuff into forms, and then have it fail [12:25] Kinnison: Yes. [12:25] spiv: cool [12:25] spiv: I've put a gina branch on your list for review [12:25] Ok, I'll take a look. [12:25] spiv: and I'll have a small dominator fix for you to look at soon too [12:25] Sure. === terrex [n=terrex@84-122-83-29.onocable.ono.com] has joined #launchpad [12:35] I've found a +translations page that locks staging solid :-/ [12:35] wahey [12:35] so, it doesn't trigger the abort DB stuff? [12:36] Nope - I'll debug it a bit more to determine if it is a single query or lots of little ones [12:36] kinda rude that the abort db stuff isn't working [12:38] lifeless: yay! while working on the samba problems, I isolate the quake3 problem :) [12:38] ddaa: lol. nice [12:38] Here's the quake3 problem: PatchedFile.apply does noop when trying to apply a diff between binary files. [12:39] -> need to detect "binary files differ" kind of diffs and fallback to overwriting in those cases. [12:39] eeeew... the new slashdot CSS removes the underlining on links you hover over [12:40] bizarre [12:40] lifeless: BTW, I have been bothering some #svn folks yesterday, and they say that the python subversion bindings in the next release will be MUCH improved. === lifeless holds is breath. [12:41] I'm not sure how relevent that is to us, but I think that in the long term we should be moving the svn_oo stuff to something vaguely sane... [12:42] a big part of my work recently is working around bugs and limitations of pysvn [12:48] ddaa: indeed, thats why svn_oo exists, I tried to just use pysvn.. HAH [12:48] lifeless: you know that pysvn is _not_ the official bindings [12:49] ddaa: one of the two we use is [12:49] ddaa: I started with the official one, which didn't have a 'commit' that worked. [12:49] well, yes, but in the code I saw pysvn is very much predominant... [12:49] ha, no commit... that sounds annoying. [12:49] theres a reason for that. [12:50] Anyone know why: [12:50] ProgrammingError: ERROR: deadlock detected [12:50] DETAIL: Process 29282 waits for ShareLock on transaction 12797011; blocked by process 2222. [12:50] Process 2222 waits for ShareLock on transaction 12794766; blocked by process 29282. [12:50] would happen in a single-threaded app? [12:51] Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] Update database documentation and diagrams (patch-2463: stuart.bishop@canonical.com) === ajmitch [n=ajmitch@2001:388:c004:1:0:0:0:12] has joined #launchpad [12:52] Kinnison: single threaded != single connection [12:52] Kinnison: i.e. librarian [12:54] lifeless: right [01:06] Yay - not only does this page execute an SQL command that takes 164 seconds to execute, it does it (at least) twice. [01:07] woo [01:07] missing indexes? obvious brokenness? or just plain knackering SQL? [01:07] stub: and the system doesn't abort it? [01:07] Kinnison: the system should be aborting such queries [01:07] Nope. I'm not seeing it issue the 'stop long running queries' to the postgresql backend (although I have seen it when running locally). [01:08] I'll need to step through it with a debugger to see wtf the option isn't being triggered or executed. [01:08] no way to connect to LP today? [01:08] But I'm looking into the dud query at the moment [01:09] SteveA: I see. I hope that's only something the webapp turns on? [01:09] yes [01:09] only the webapp [01:10] we'll turn it on for xmlrpc too [01:10] right [01:10] but not yet [01:10] 'cos the publisher sometimes runs queries which can take up to 2 minutes to return [01:10] although that may be assisted with judicious indexing === Kinnison does a dogfood update, noone using it right now? [01:30] Kinnison: I thought you were the only person left using dogfood? [01:30] I may be [01:30] but it's always worth checking [01:30] If I get a changeset with 'baz undo' [01:31] sorry, with 'baz diff -o ,,blah' [01:31] can I apply it (in reverse) to another tree with baz apply-changeset --reverse ,,blah ? === cprov [n=cprov@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [01:33] launchpad developers meeting in about half an hour. /msg me agenda items [01:40] cprov: what [01:40] cprov: what's PBR? === niemeyer [n=niemeyer@200.103.241.182] has joined #launchpad [01:41] SteveA: PVR, sorry (Personal Video Recorder) [01:41] i see [01:42] Good morning! === camilotelles [n=Camilo@20132139198.user.veloxzone.com.br] has joined #launchpad [01:48] Merge to rocketfuel@canonical.com/launchpad--devel--0: r=stub add 'launchpad (or shipit) is going down for maintenance' facility. (patch-2464: steve.alexander@canonical.com) === niemeyer [n=niemeyer@200.103.241.182] has joined #launchpad [01:53] bombs away [01:54] pardon? === jamesh [n=james@203-59-207-160.dyn.iinet.net.au] has joined #launchpad [01:55] sent off my 81K patch for bzr-twisted for thoughts and feedback [01:56] lifeless: Whee! [01:56] lifeless: is that a shiny twisted xmlrpc server for bzr? [01:56] Kinnison: hell no [01:56] what is then? [01:56] Kinnison: its twistified bzr, which is 15 minutes to pull, not 93. [01:57] meeting in 3.5 or so [01:57] lifeless: cool [01:57] lifeless: is there a bzr development mailing list? [01:57] bazaar-ng@l.c.c [01:57] righty [01:58] how much traffic? === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === mpt_ [n=mpt@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [01:59] This much traffic: http://gmane.org/details.php?group=gmane.comp.version-control.bazaar-ng.general ;) [01:59] (look! pretty graphs! ooh!) [01:59] mpt, salgado: i just landed a "shipit (or launchpad) is going down for maintenance" page [01:59] could do with UI love [01:59] SteveA: Such a page already exists === bradb [n=bradb@modemcable033.209-70-69.mc.videotron.ca] has joined #launchpad [01:59] s/page/message on main template/ [01:59] SteveA: launchpad/offline.html [02:00] this is a message about goin down soon [02:00] meeting time [02:00] oh, goING [02:00] ok [02:00] MEETING TIME [02:00] who is here? [02:00] me [02:00] me === Kinnison is here [02:00] me [02:00] I'm here, but I won't be for much longer [02:00] kiko-zzz: ? [02:00] I appear to be [02:00] I'll probably need to leave early [02:01] me [02:01] me [02:01] me [02:01] mpt_: /msg me 3 sentences, activity report status, any points to raise [02:01] yep [02:01] carlos: ? [02:01] jordi: ? [02:01] mpool? (lifeless...) [02:02] SteveA: I've pung [02:02] ta [02:02] cprov: ? === niemeyer [n=niemeyer@200.138.33.203] has joined #launchpad [02:02] hi gustavo [02:02] salgado: what about gnueman and diogo? === cprov [n=cprov@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [02:03] hi kiko [02:03] SteveA, they're still not aware of the 9am meeting I believe [02:03] but should be around shortly [02:03] Hello [02:03] sorry, found another wireless network [02:03] we'll set them up for next week [02:03] hello hello [02:03] I have some network issues here.. [02:03] stub: ? === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [02:03] gneuman's just arrived [02:03] and there's diogo [02:03] and so have diogo [02:03] hi matsubara [02:03] yo [02:03] heya stub [02:03] hi steve === mpool [n=mbp@ozlabs.org] has joined #launchpad [02:04] okay, let's go. /msg me other items for the agenda, which so far is... [02:04] oh [02:04] not -meeting [02:04] == Agenda == [02:04] - roll call [02:04] - agenda [02:04] - activity reports [02:04] - production and staging (stub) [02:04] - ddaa's item (ddaa) [02:04] - launchpad breezy archive (kinnison) [02:04] - test suite spew (stevea) [02:04] - three sentences [02:04] [02:04] activity reports: who's in with the in crowd? [02:04]