[12:21] elmo: pong? [12:25] spiv! [12:25] kiko: Good morning. [12:26] how are you? [12:27] Pretty good. Summer has arrived, but I'm managing not to wilt. [12:28] heh, summary of our summer seems to be RAIN [12:28] spiv, how's the SM work going? how are you feeling? [12:31] It's started a bit slower than I'd like, but more tests are passing every day. The new spec requires a lot more dynamicness (like being able to go off and query launchpad in response to a mkdir request), so that's requiring a fair bit of effort. [12:31] yeah, the coupling is a lot higher [12:31] is the API sufficient or are you finding it to be swiss-cheese [12:32] and how is the XML-RPC working? [12:33] The immediate issue is that the "vfs" code in Twisted is still fairly immature, and hasn't needed to be properly async -- i.e. it assumes that mkdir works immediately. I'm fixing that up as I go along, so far no major surgery has been required. [12:34] you are making me want to cry [12:34] Well, the previous sftp code did this all ad hoc. [12:34] this sounds like a quagmire [12:34] Now at least it has some infrastructure in Twisted to lean on, even if that infrastructure is still rather young. [12:34] Hmm. [12:35] spiv, why don't you stay more in touch about this sort of thing? I really appreciate hearing it but I only get to know about it if I stay up till my eyeballs are bloody [12:35] Well, I can probably cut some corners here. It'll scale horribly, but it'll get us started. [12:35] I've written some soyuz reports this week [12:35] kiko: Because I'm a slacker :( [12:35] yeah, be practical -- this can be fixed later [12:35] nah [12:35] your strine [12:35] these people have communication trouble I tell you [12:36] you're strine === kiko can't type post 10h workshift [12:36] maybe send in a report every once in a while [12:36] (The authentication phase is properly async, so if I were to retrieve all the information I may possibly need in advance (i.e. complete dump of product name <--> id mapping, etc), I could keep mkd immediate) [12:36] gustavo and I are dying to see the work [12:36] and know how it's going [12:37] spiv, hmmm. doesn't sound too exciting [12:38] Hmm, that still wouldn't help creation of new branches, though. [12:38] Which has the same fundamental issue. [12:38] But that's alright, I've already got this particular problem mostly patched up, and it's the worst one. [12:39] so far :) [12:39] Right :) [12:39] But we really only need to be this dynamic on mkdir. [12:39] Merge to devel/launchpad: update format of /supermirror-pull-list.txt [r=BjornT] (r2902: David Allouche) [12:40] Existing directories I can already grab the info I need at auth time, which is convenient for a variety of reasons. [12:41] well twisted is probably not optimized to give you hook points in every step the user takes down the filesystem [12:41] Well, the plan for Twisted is that is will. [12:42] But it's a very new API that doesn't have many users yet. I did some work on it at the last Twisted sprint in Sydney. [12:42] immature APIs are the suk [12:42] anyway I need to go and have dinner with niemeyer, last day here [12:42] To be properly Twisted, it should be async at every step. There's a bug about it in the tracker somewhere. [12:42] we don't need 100% -- just the 80% to make it practical [12:43] The way to get there is to fix one operation at time. In this case, I'm fixing createDirectory, because that's all I need :) [12:43] please make a point of telling launchpad@lists about how this is going [12:43] Ok. [12:43] because I feel like crying when I find out you had trouble and I didn't know [12:43] it's okay to have trouble [12:44] but we need to accomodate for it [12:44] and there's a million people that will move in lockstep with the code that's being worked on by you ddaa jblack and the bzr cabal [12:44] anyway [12:44] 10-4 === kiko waves to the other side of the world [12:46] good night guys === Keybuk [n=scott@descent.netsplit.com] has joined #launchpad === jinty [n=jinty@205.134.224.215] has left #launchpad ["Leaving"] [01:38] There's a related one, #3708 === OgMaciel [n=omaciel@ubuntu/member/gnukemist] has joined #launchpad [02:24] hi... I need to set my default email at Launchpad to be a new @ubuntu.com email but I don't have it yet... so the system won't let me do it until I can confirm it [02:24] can someone help me out? [02:25] ogra told me to come here for help [02:27] OgMaciel: Hmm, you don't really want to set your Launchpad address to be @ubuntu.com. [02:28] OgMaciel: Because you'll make a mail loop. [02:28] There's a bug about this... [02:28] spiv, I see [02:28] spiv, what I really want is to have my current email changed [02:28] right now is og-maciel@ubuntu.com [02:28] I want to remove the dash [02:30] Ah, bug 5292 [02:30] Malone bug #5292: People setting preferred contact address to @ubuntu.com In: launchpad (upstream), Severity: Normal, Assigned to: Guilherme Salgado, Status: New https://launchpad.net/bugs/5292 [02:30] he [02:30] Ubugtu, do you happen to have the date for that bug? [02:31] OgMaciel: You'll need to talk to an admin to get your @ubuntu.com email alias changed -- at the moment, the automatic sync with Launchpad isn't running. [02:32] OgMaciel: You probably need stub and/or elmo. [02:32] spiv, cool... thanx [02:33] elmo doesn't reply and stub isn't around... oh well... ;) === bob2_ [i=rob@crumbs.ertius.org] has joined #launchpad [02:34] OgMaciel: Failing all else, you could file a bug against Launchpad. But if can you wait a few hours, stub should be online. [02:35] spiv, will do that... I've been advocating a lot these days and would be nice to give people my corrected email address [02:35] OgMaciel: :) [02:36] spiv: Heya. Any updates from a couple days ago? [02:36] ;) === Nafallo_away is now known as Nafallo [02:37] jblack: Nothing particularly visible from your perspective -- see also my conversation with kiko a few hours ago. [02:38] Heh. You've got a lot of people asking you about this, eh? [02:39] So it seems :) [02:40] I'll back off a bit === marcolu [n=marcolu@61.151.243.154] has joined #launchpad [02:41] Nah, it's fine. You're always welcome to ask. === Nafallo is now known as Nafallo_away === stub [i=stub@sweep.bur.st] has joined #launchpad === SloMoSnail [n=slomo@p5487FA5C.dip.t-dialin.net] has joined #launchpad [03:05] stub, excuse me... do you have a minute? [03:05] Whats up? [03:06] I need to change my current ubuntu email [03:06] launchad won't let me [03:06] ogra suggested I asked for help here [03:07] think you can lend me a hand? [03:07] stub: I think it may be related to bug 5292 [03:07] Malone bug #5292: People setting preferred contact address to @ubuntu.com In: launchpad (upstream), Severity: Normal, Assigned to: Guilherme Salgado, Status: New https://launchpad.net/bugs/5292 [03:08] You need to change your 'name' field to what you want (name -> name@ubuntu.com). However, I believe the script that syncs names to email addreses is currently broken so elmo might need to fix it manually for you. [03:08] stub, already changed my name but have not been able to reach elmo [03:09] spiv, actually my email has to be update... and launchpad requires an email verification... so I have a catch 22 [03:09] OgMaciel: try waiting til UK business hours [03:09] jamesh, that wouldn't work for me... need to get my beauty sleep so I can be ready for work [03:09] OgMaciel: What's your name in launchpad? [03:09] ogmaciel [03:09] ;) [03:09] https://launchpad.net/people/ogmaciel [03:10] OgMaciel: I'm just telling you when you are most likely to catch elmo. [03:10] Hmm... the email syncing bug has disappeared :-( [03:10] Ah, your preferred isn't set to @ubuntu.com, that's good. [03:10] spiv: hola [03:11] spiv: nice work on the id mapping [03:11] lifeless: Good afternoon. [03:11] spiv, I actually changed after you told me about the bug [03:11] ;) [03:11] OgMaciel: Ah :) [03:11] spiv: I realise we did not talk about the priority of the other 5 use cases. [03:11] spiv: the other apache script is also a dependency for both pull and push [03:11] spiv: will it disrupt you to make it #1 ? [03:12] lifeless: Only a little. [03:12] Ok, if its ok with you, please do that. [03:12] that will help unblock jblack & ddaa [03:12] lifeless: so, to double-check, the thing to generate a file for RewriteMap? [03:13] yes [03:13] i.e. the thing to make the public http work. Ok. [03:13] yes [03:13] (I'd hate to be working on the wrong thing!) [03:13] stub, so, should I wait for elmo? [03:13] ;) [03:14] OgMaciel: Nobody else can help you I'm afraid, so yes. [03:14] stub, no prob... =) [03:15] England is 6 hours ahead of the US, right? [03:15] england is GMT at the moment [03:15] the US is more than one TZ, so your question is impossible to answer [03:15] lifeless, NYC [03:15] UTC-5 [03:16] then england is 5 hours ahead ofyou ;) [03:16] right-o [03:16] thought it would 6 but close enough [03:16] would be [03:17] 0-5 = -5 ;) [03:18] anyway that does not help you much [03:18] ;) [03:18] james is operating at about -10 [03:19] spiv, will launchpad be ever translated to other languages? [03:20] OgMaciel: Eventually, yes. [03:20] cool [03:20] We have lots of other things to work on first :) === OgMaciel works with the Brazilian translating team [03:21] some people stumble a bit on the CoC signing and stuff [03:21] obviously people who work as translators shouldn't have a problem... ;) [03:22] Heh :) [03:27] spiv, stub thanks for your time... will try again some time earlier tomorrow === OgMaciel [n=omaciel@ubuntu/member/gnukemist] has left #launchpad ["zzzZZZ"] [03:30] Ahh - Bug 5278 [03:30] Malone bug #5278: Launchpad name -> @ubuntu.com email address broken In: launchpad (upstream), Severity: Normal, Assigned to: James Troup, Status: New https://launchpad.net/bugs/5278 [03:30] Heh, there's a bug in Ubugtu there :) [03:30] ">" === BjornT [n=bjorn@84.32.140.183] has joined #launchpad === lifeless takes away stubs refresh button [04:48] <_keturn> ...the python-openid library has been announced... it becons to you... it says "please integrate me with launchpad! please!" [04:50] Excellent - might save us having to implement chunks of it ourselves. [04:52] Bug 1169 [04:52] Malone bug #1169: Launchpad should support OpenID In: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: New https://launchpad.net/bugs/1169 [04:54] <_keturn> stub: let me know if it'll work for you [04:59] _keturn: We won't be looking at that until maybe February [05:00] stub: would staging be in a state where I could do another test run of the bugzilla-importer some time? [05:06] jamesh: Now would be fine. [05:13] _keturn: Thanks! [05:30] Can I consider the Referrer: header 'reliable enough' for refactoring the notifications machinery? [05:30] lifeless, spiv, jamesh: ^^^ [05:32] ie. given that it won't be an attack point (worst you could do is screw up your own session), can I rely on our target browsers setting it consistently? [05:34] uhm [05:34] there are privacy plugins that disable it [05:34] whats the refactoring you want to do ? [05:34] oh - bum. There is still the same flaw anyway. I can't see a way to refactor the notifications to reliably display them without passing a token in the URL. [05:34] Getting rid of ?lpnotification=xxxxxx I'm guessing? [05:34] set cookie [05:35] ? [05:35] what are the constraints [05:35] are we allowed to put the notification in session state ? [05:35] Page A sets notifications and redirects to page B. Client loads page B, finding notifications displayed. [05:35] Yes - the messages are in the session. The token is used to identify which messages to display. [05:35] right [05:36] and its a one time thing [05:36] the right way for that is a url parameter or post parameter [05:36] Indeed. But complicated because when the client views page B, they load page B and all its resources. [05:36] ... [05:36] The current implementation is correct and reliable. But people dislike it for aesthetic reasons. [05:36] oh [05:36] what aestehtic reasons ? [05:37] http://launchpad.net/+niceurl?lpnotification=HKJDHADFSSDFSDFSF [05:37] so [05:37] use a post [05:37] not a get [05:37] lifeless: I file a bug, and then want to paste the URL, but the URL immediately after filing the bug has lpnotification=blergh [05:37] I think the best I can do is shrink the token and the key [05:37] I think that's the specific example that came up. [05:37] lifeless: I can redirect using a post? [05:38] or dont redirect, just display the correct content on the page and set the location: header so that the browser shows the url they would have redirected to [05:39] If I set the location header, the browser will redirect won't it? Or is that contingent on a 3xx status being sent too? [05:39] contingent [05:39] Cool - that behavior could be useful. Didn't know that. [05:39] test it first ;) [05:39] I'm going of deep-foo memory here [05:40] one thing [05:40] If a resource has been created on the origin server, the response [05:40] SHOULD be 201 (Created) and contain an entity which describes the [05:40] status of the request and refers to the new resource, and a Location [05:40] header (see section 14.30). [05:40] right] [05:40] so, I think the magic combo is: [05:41] POST-> 201 + locationheader of the bug; shows bug pages content [05:41] I don't think there is a one size fits all for this - we have at least two discrete use cases [05:42] I wonder if that actually works ... [05:42] one is editing, one is creating. We *might* be able to showhorn both into the 201 mechanism [05:42] jamesh: thus the 'test it' phrase ;) [05:42] Could be tricky, as I have a URL. I would need to reverse engineer the URL to determine what page to display. [05:43] stub: is it possible to just queue up the notifications, and have the act of rendering the next page pop off all the pending notifications? [05:43] is ie a target browser ? [05:43] jamesh: no [05:43] jamesh: RACE CONDITION [05:43] ah. [05:43] Unless I use HTTP to retrieve the URL,insert the notifications, then return it.... yech... [05:44] stub: huh, surely the lp machinery is more flexible than that [05:45] stub: i.e. let the current request complete, and chain into the new request, use its content, set the response code to 201 and stash the url in location [05:47] Something like that. /+shownotification?url=http://launchpad.net/dfs would need to ask the publisher to render http://launchpad.net/dfs for me, and return that after setting the relevant headers. Tricky bit would be virtual hosting, as some of that is done using Apache rules outside of Z3. I also need to canonicalize relative URLs in the redirect. It is non-trivial :-/ [05:48] ah [05:48] I'm wondering if I can just render the page as normal, but set the Location: header and possibly change the status to make the browser display the same URL but without the parameters [05:48] well, I would suggest we: [05:48] test various permutations to get a working mock up [05:49] then worry about feasability in lp today/refactorings to do it long term [05:49] we dont want an incorrect solution after all ;) [05:50] one thing to note is that a 201 page is one less roundtrip for the browser -> faster [05:50] Oh - it appears to have become a high priority which is why I'm looking at aesthetic changes now rather than infrastructure we need :-( [05:50] I'll try setting the Location header and changing the status - should be a simple modification to what we already have. [05:51] blargh [05:51] See what happens. Thanks ;) [05:51] np [05:54] I can't help thinking there is a big security hole in here - if this works, in theory I could serve up a web page with a 201 giving a Location: of www.microsoft.com or something [05:56] this really sounds like the sort of thing that might work in lynx (which uses w3c libwww) but nothing else [06:03] Hmm... this might work and be more mainstream. Simply stuff all the notifications into the session. When a page renders the messages, it makes a call that erases the notifications. This will fail in edge cases (multiple windows open into launchpad being used at the same time), but should be good enough that the edge cases will never happen. [06:04] At the moment, we don't have the 'erase the notifications' call so this mechanism would display the notifications on every page subsequently rendered. [06:14] Merge to devel/launchpad: [trivial] Update staging's Gina config (r2903: Stuart Bishop) [06:21] stub: it will be something.. [06:21] stub: not sure it qualifies as more mainstream. 201 is used, and users hate the sort of bug you are creating [06:22] is the bug that the url is 'bad' or that the notifications show to anyone given that url ? [06:26] The bug is the URL is bad. The notifications will only be shown to the original client (the actual message is stored in the Session, and silently ignored if the session has no notifications matching that token) [06:26] ok [06:26] Just setting the Location: header and the 201 status didn't work btw. [06:27] after a post ? [06:28] the spec says that only works in the reply-to-a-post [06:28] No - just the redirect. [06:29] The main use is for self posting forms - the form finds itself valid, makes changes, and redirects with a notification. [06:30] Unfortunately by the time the redirect is invoked, the page has likely already been rendered [06:31] but the use case does not need a redirect. [06:31] the use case needs: [06:31] a specific url displayed [06:31] content changed in the system [06:31] notification on the displayed page [06:32] It needs to work with a redirect or we need to rewrite the form machinery [06:33] details :) [06:33] seriously though, using redirects there is only one correct way: a token in the url [06:33] anything else will have race conditions on either the client or server end [06:33] POE might have some hints, but thats still draft [06:34] Pieces Of Eight? [06:35] post once exactly [06:36] I think I have to go with race conditions, hopefully minimized, to keep people happy. We can revert to the existing correct implementation if people bitch easily enough. [06:36] lifeless: what if you don't know the destination URL you want the user to arrive at after posting the form til the form has been posted? [06:37] Thankfully the race conditions will only be UI glitches - no data loss or OOPS pages will happen. Just messages appearing in the wrong window if you are driving multiple launchpad windows simultaneously. [06:37] jamesh: exsqueeze me ? [06:38] jamesh: this is logically the same as emitting the form that the current redirect points at, at the end of the post transaction. [06:38] lifeless: say you have a post form for creating something, and you want the user on the page for that thing when they post? [06:38] lifeless: where that second URL depends on the contents of the form? [06:40] jamesh: I don't understand you. There is no change from todays situation, so are you asking about something we cant do today, or about something you think is changing in my proposal ? [06:42] lifeless: I was wondering how you'd handle that case without a redirect? [06:43] jamesh: ?!!! [06:43] define 'after posting the form' [06:43] at the moment the logic is roughly: [06:43] accept a post [06:43] perform a transaction [06:43] issue a redirect to a url [06:43] render that url when the client asks for it [06:44] the logic I am proposing is roughly: [06:44] accept a post [06:44] perform a transaction [06:44] render the same url the prior logic used and put it in the location header [06:44] -- === GoRoDeK [n=gorodek@p5083F228.dip.t-dialin.net] has joined #launchpad === robitaille [n=robitail@ubuntu/member/robitaille] has joined #launchpad [08:38] Bah. priming the remote branch using 'cp -a rocketfuel/launchpad/devel foo/launchpad/whatever' no longer seems to speed pushes of new branches :-/ [08:39] stub: in BjornT's review of my bugzilla stuff, he mentioned creating a database patch to add the extra user on production. I don't see any of the existing db patches that just add data to the tables [08:39] (and it sounds like it would cause problems when loading the sample data) [08:39] what is the preferred way to do this? [08:40] Yup - patches shouldn't insert data. A seperate script needs to be written to do the data insertions that I need to run on production manually. [08:40] Generally stuck in database/schema/pending [08:41] okay. [08:44] I guess I could run the SQL myself before doing the import === sivang-zzz is now known as sivang [08:44] it's just the addition of a single user, and my script needs to be able to create users anyway [08:44] morning all === jinty [n=jinty@205.134.224.215] has joined #launchpad [08:59] jamesh: That would be best. Saves me forgetting ;) [09:24] jamesh: would you have time to review my DefaultAffectsTarget branch today? [09:25] BjornT: okay. [09:25] thanks jamesh [09:27] I fixed the last round of problems you mentioned in the bugzilla-import branch [09:28] yeah, i've already approved the branch [09:30] okay. I'll merge it after doing a test run on staging [09:51] importing stuart.bishop@canonical.com/launchpad--staging--3 into /home/warthogs/archives/stub/stuart.bishop@canonical.com/launchpad/3/staging [09:51] Cleaning up [09:51] bzr: ERROR: exceptions.OSError: [Errno 2] No such file or directory: '/home/warthogs/archives/stub/stuart.bishop@canonical.com/launchpad/3/staging/./configs/staging3/mail-configure-normal.zcml' [09:51] at /home/warthogs/source/bzr.integration/bzrlib/changeset.py line 376 [09:51] in apply [09:51] lifeless: More conversion breakage ^^^ === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad [09:52] garh [09:52] yummy [09:52] stub: I love you man. bug magnet [09:53] garh is a worm... not a bug [09:56] ddaa: ECONTEXT [09:56] 19:51 < stub> importing stuart.bishop@canonical.com/launchpad--staging--3 into /home/warthogs/archives/stub/stuart.bishop@canonical.com/launchpad/3/staging [09:56] 19:51 < stub> Cleaning up [09:56] 19:51 < stub> bzr: ERROR: exceptions.OSError: [Errno 2] No such file or directory: [09:56] '/home/warthogs/archives/stub/stuart.bishop@canonical.com/launchpad/3/staging/./configs/staging3/mail-configure-normal.zcml' [09:56] 19:51 < stub> at /home/warthogs/source/bzr.integration/bzrlib/changeset.py line 376 [09:56] 19:51 < stub> in apply [09:56] 19:51 < stub> lifeless: More conversion breakage ^^^ [09:56] 19:52 -!- ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad [09:56] 19:52 < lifeless> garh [10:06] you know, garh, this klingon delicacy :) [10:09] Sheesh... and I thought I had to be careful in Cambodia [10:26] Gagh [10:26] Klingon serpent worms. Gagh is best served while as fresh as possible, i.e. while still alive, and it dies only when entering the digestive tract. Klingons say that they don't care for the taste of gagh, but like it for the fight it puts up when eaten. There are actually at least 51 distinct "flavor" varieties of gagh. [10:26] [10:27] http://en.wikipedia.org/wiki/Klingon#Klingon_cuisine === elmo_ [n=james@83-216-156-21.jamest747.adsl.metronet.co.uk] has joined #launchpad [10:37] ddaa: garh is not gagh [10:37] mh... you spell klingon bether tan I. [10:39] lifeless: so what sort of Klingon delicacy is garh? [10:40] its not, I dont spell Klingon ;) [10:52] SteveA: what do you mean by "make the notional dependency-replacement-API explicit in the code, rather than saying ``well, the tests can replace anything they want''"? [10:56] ddaa: when i read the code, apart from that test, i cannot see that there is some attribute that some test will replace with a stub. [10:56] i think it is worth making that obvious in the code. [10:57] so, you mean adding a class attribute ImportToBzr._branch_type attribute initially set to ImportdBranch, and using that in ImportdToBzr.make_branch, as I suggested? [10:58] something like that, yes [10:59] NameError: name 'login' is not defined [11:00] so much for implicit imports === mpt [n=mpt@200-158-80-35.dsl.telesp.net.br] has joined #launchpad [11:00] Since I have to send another merge request anyway, I'll do this other change. === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad === WaterSevenUb [n=WaterSev@195-23-220-103.net.novis.pt] has joined #launchpad === SloMoSnail is now known as slomo === thisfred [n=thisfred@a80-127-80-154.adsl.xs4all.nl] has joined #launchpad === cprov [n=cprov@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [12:19] good morning! [12:20] hi matsubara [12:20] how's it going? [12:21] morning people [12:21] hi cprov [12:22] SteveA: hey ho === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [12:28] SteveA: fine, what about you? === Kinnison arghs === Kinnison must have gone completely and utterly mad === Kinnison is sure he sent a mail to kiko, stevea, etc about derivative distro stuff, in which he talked about resourcing the tasks, but he can't find the sodding mail === Kinnison is teh_suck === mpt [n=mpt@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [12:31] Hey everyone, meeting in 28 minutes [12:31] matsubara: most excellent [12:32] Hmm, I should get gone to the meeting place then [12:32] daf: shall we? [12:33] Goooooooooooooooooooooooood morning Launchpadders! [12:37] ddaa: ping [12:37] SteveA: poing [12:37] last meeting, you had two "Change" items [12:37] one was sysadmin request latency [12:37] the other was review team latency [12:38] i'd like to address the review team latency point by pointing at lifeless, who is organising a review team meeting [12:38] sysadmin request: was discussed monday, "fuzzy requests" [12:38] do you have any other sysadmin requests waiting? [12:38] No, only the two we discussed monday. [12:39] okay [12:39] Well, Znarl has telling me he'll be doing a neumayer upgrade "tomorrow" since the beginning of week, as well... [12:39] lifeless: are we having a reviews get-together in 5 mins? [12:39] ddaa: there's a machine called "neumayer" ? [12:39] which kind of suggest there's something wrong with sysadmin scheduling [12:40] SteveA: yes, second hoover slave [12:40] could we call it niemayer, to make it even more confusing? [12:40] and also have a machine called ddae while we're at it [12:40] heh [12:40] it was there _before_ niemeyer [12:40] so it's niemeyer's fault :P [12:40] ddaa, not really. [12:40] niemeyer is pushing 30 [12:41] kiko: at least, in the company... [12:41] i don't think the machine is that antique ;-) [12:41] he's 26 [12:41] over 25 is pushing 30 [12:41] i'm pushing from the other direction [12:41] lol [12:41] I'm pushing HARD [12:41] so where's Kinnison [12:41] so, you're pulling 30? [12:41] and my soyuz output [12:42] Kinnison and daf are en-route to the meeting place [12:42] which i think is a pub in cambridge with internet access where these launchpad meetings traditionally take place [12:42] salgado: how's it going this morning? [12:42] SteveA: yes [12:43] in 3 minutes [12:43] SteveA: anything you want to talk about before meeting, or can I get a quick snack pre-meeting? [12:43] SteveA, I'm a lot better. [12:43] reviewer get together #c-m in 2 minutes [12:43] kiko: good news about DF: NEW -> 9509 REJECTED -> 0 ... slowish (3s) but is working ;) [12:43] salgado: great. i commented on your signup workflow spec. i'd like to talk about it a little, after the meeting. [12:43] ddaa: nothing more [12:43] cprov, ZERO rejected? woohoo === LanCome [i=casryum@125.176.67.146] has joined #launchpad [12:43] you guys DELIVER === LanCome [i=casryum@125.176.67.146] has left #launchpad [] [12:44] other than reviewers, everyone else consider taking a workrave before the meeting. [12:44] kiko: that's the aim [12:44] also, check out the https://wiki.launchpad.canonical.com/MeetingAgenda page === kiko chuckles wtf 0 dropped [12:47] kiko, I think the proper term for that is "lolwtfbbq" [12:49] kiko: another good news, full ubuntu archive is able to daily sync propely now, it spent 5914s yesterday, starting at 10 PM. [12:50] cool === cprov wonders why debian web site is down :( [12:51] ddaa: would you come onto #c-m please? [12:52] ddaa: ping [12:52] ddaa: can you come into #c-m and tell us your review-team issues ? === bradb [n=bradb@modemcable033.209-70-69.mc.videotron.ca] has joined #launchpad === mpool [n=mbp@ozlabs.org] has joined #launchpad [12:59] It is almost Festivus [12:59] But it is actually Launchpad Development Meeting time! [12:59]