[02:48] <lifeless> I'm off to pick up tickets
[02:48] <lifeless> if lp crashes, sms me and I'll get to a starbucks etc asap.
[05:30] <mpt_> Goooooooooooooooooooooooooood afternoon Launchpadders!
[06:27] <lifeless> jamesh: your review is aging
[06:27] <lifeless> spiv: your reviews need love
[07:13] <stub> Do I recall something about other people getting spurious failures with pagetests/soyuz/26-queue-pages.txt when submitting to PQM?
[07:14] <spiv> stub: matsubara had that.
[07:14] <spiv> stub: It made no obvious sense I could see late on a Friday night.
[07:15] <spiv> He posted to the list asking for ideas after I ran out of suggestions for him, no replies yet.
[07:16] <spiv> There's some funny business with SQLObject going on in database/queue.py, but I can't see how it would cause the problem.
[07:19] <stub> I'm getting it consistantly - 5 submit requests, five faillures. Only changes on that branch are the session machinery, which might affect page tests.
[07:20] <spiv> matsubara's changes were in CoC stuff, and were also totally consistent.
[07:20] <spiv> (i.e. repeated failures).
[07:20] <spiv> I wonder if a totally trivial change can merge atm?
[07:21] <stub> pagetests passing locally...
[07:21] <stub> Got a trivial change lying around?
[07:22] <stub> Heh.... *mine* is trivial
[07:24] <spiv> Heh.
[08:27] <mantas_> hi all
[08:48] <SteveA> morning
[08:49] <lifeless> morning
[09:04] <carlos> morning
[09:19] <lifeless> SteveA: ping
[09:19] <SteveA> hi
[09:21] <lifeless> you suggested a second bzr talk
[09:21] <lifeless> and offered to propose it at europython.
[09:21] <lifeless> have you done that? If not, we can put one forward in an hour or so
[09:21] <lifeless> With me and you as presenters
[09:21] <SteveA> u have not done so
[09:22] <SteveA> please do
[09:22] <lifeless> ok, consider it done
[09:22] <lifeless> should I make you primary author? [will the system let me do that ?] 
[09:24] <SteveA> sure, if the system will allow
[09:24] <lifeless> ok
[09:27] <janimo> carlos: hello. There is a new translation .po file for the xfce file manager, is it too late to get it in dapper?
[09:28] <janimo> I got it mailed privately by an upstream translator
[09:29] <carlos> hmm, I think it's too late if we use language packs done today
[09:29] <carlos> janimo: you would need to check it with pitti
[09:29] <carlos> janimo: anyway, it will appear next month
[09:29] <ddaa> Hello, I'm back.
[09:29] <carlos> with the language pack update
[09:30] <janimo> carlos: oh so it can be imported just not make dapper?
[09:30] <janimo> that's ok as well
[09:30] <carlos> janimo: yeah, it can be imported
[09:30] <janimo> carlos: ok thanks. Can I do it via LP? Package thunar language ro
[09:31] <janimo> this is a new po
[09:31] <carlos> hmm, no, an Ubuntu translator should do it for you (I will fix that soon)
[09:31] <carlos> I mean a Romanian Ubuntu translator
[09:31] <janimo> carlos: Ok I'll ask them
[09:31] <carlos> janimo: if it comes from upstream, send me the file and I will do it for you
[09:32] <janimo> carlos: what email address?
[09:32] <carlos> janimo: if it doesn't come from upstream, you should not upload anything yourself, the translation team should do it to prevent any translation problem
[09:32] <carlos> janimo: carlos.perello@canonical.com
[09:32] <janimo> carlos: it comes from the official xfce romanian translator guy
[09:34] <carlos> I will do the upload then
[09:34] <carlos> as coming from upstream
[09:35] <janimo> carlos: sent
[09:35] <carlos> janimo: ok, thanks
[10:01] <carlos> stub: hi, could you execute on production the SQL command I sent on Saturday to remove OO.org imports ?
[10:33] <ddaa> SteveA: jamesh: spiv: mpool: lifeless: meeting in 26 mins
[11:02] <ddaa> SteveA: jamesh: spiv: mpool: lifeless: well, actually, it was "meeting in 1 hour and 26 mins". Now 57 minutes, confused by change in meeting time.
[11:42] <ddaa> SteveA: jamesh: spiv: mpool: lifeless: meeting in 7 minutes
[11:42] <ddaa> he
[11:42] <ddaa> meeting in 17 minutes
[12:05] <spiv> lifeless: just one outstanding, I'll do it v. soon...
[12:10] <mpt> :)
[12:21] <lifeless> spiv: thanks. Your peak was 5 days, which given the weekend is 3, and still a bit many. Remember, a review a day, keeps the nagger away.
[12:37] <stub> buildd-slave-scanner.py is spamming me. Should I disable it or is someone working on it atm? ddaa?
[12:38] <stub> Erm... sorry. That isn't ddaa's toy
[12:39] <SteveA> stub: bank hols in the UK, so no soyuz folk around
[12:58] <lifeless> review meeting in 1 minute
[01:00] <lifeless> ok, role call
[01:00] <SteveA> i'll be the butler
[01:00] <jamesh> I'm here
[01:01] <lifeless> SteveA: in the library
[01:01] <SteveA> with the washboard
[01:01] <spiv> SteveA: Is this "Cluedo: The 'Who played that tune?'" edition? ;)
[01:02] <lifeless> ok
[01:02] <lifeless>     *
[01:02] <lifeless>       Next meeting
[01:02] <lifeless>     *
[01:02] <lifeless>       Queue status.
[01:03] <lifeless> same time and place ?
[01:03] <SteveA> if you copy from the "raw text" wiki page, you get better irc output
[01:03] <lifeless> the 5th june
[01:03] <SteveA> +1
[01:03] <lifeless> ok
[01:03] <lifeless> lets look at the queue
[01:04] <lifeless> accounting for the weekend, needs-review has one on 2 days, and 2 on 1 day
[01:04] <lifeless> this is healthy. *but*...
[01:05] <lifeless> this morning there were three on 5 days IIRC.
[01:06] <lifeless> which is 3 on 3 days. Our goal is a 48 hour turnaround - one day to allocate, one day to review.
[01:06] <jamesh> I'm part way through doing carlos' review
[01:06] <lifeless> jamesh: cool. that will keep it under 48 hours :)
[01:06] <lifeless> spiv: what went wrong with your queue last week ? too many reviews? too much other stuff ? were you getting one a day done ?
[01:08] <spiv> I forgot to check my review queue on Friday.
[01:08] <lifeless> ok
[01:08] <spiv> Which is probably a symptom of being busy with other things.
[01:08] <lifeless> do you have a daily 'todo list'
[01:08] <lifeless> I have one, written down.
[01:09] <lifeless> 'check email', 'assign reviews', 'do reviews'.
[01:09] <spiv> I have a tomboy todo list, but it's not daily as such.
[01:09] <lifeless> so, I have my tomboy list in parts:
[01:09] <lifeless> daily
[01:09] <lifeless> ----
[01:09] <lifeless> urgent
[01:09] <lifeless> ------
[01:10] <lifeless> other
[01:10] <lifeless> ----
[01:10] <spiv> That looks like a good categorisation.  I'll try that.
[01:10] <lifeless> I find it stops me forgetting about daily stuff
[01:10] <lifeless> ok, cool
[01:11] <lifeless> any other business ?
[01:12] <jamesh> the pending-reviews runs seem to have fairly consistant runtimes, so I can probably increase the frequency a bit more if that would be useful
[01:12] <lifeless> jamesh: can you make it print the *next* run date on the page ?
[01:12] <spiv> lifeless: One quick thing; just letting know Steve's asked me to do the review in his queue, as it's supposed to be a public holiday for him.
[01:12] <lifeless> jamesh: that is probably very useful.
[01:13] <lifeless> spiv: thanks
[01:13] <lifeless> I have one bit of new business
[01:13] <jamesh> lifeless: I could probably include the date when it'll *start* the next run, but that isn't quite the same as when the next set of results will be ready
[01:13] <lifeless> please be sure to note in the review how long it took.
[01:14] <lifeless> this is for understanding the workload reviews place on you
[01:14] <lifeless> has anyone done a pre-code design phone call yet ?
[01:14] <spiv> I haven't yet.
[01:14] <lifeless> jamesh: add the time this run took - should be close :)
[01:15] <jamesh> lifeless: sounds fair enough.
[01:16] <lifeless> ok, countdown to meeting over
[01:16] <lifeless> 5
[01:16] <lifeless> 4
[01:16] <lifeless> 2
[01:16] <lifeless> -1
[01:17] <lifeless> -meeting ends-
[01:17] <lifeless> thanks for coming
[01:26] <cprov> good morning
[01:26] <SteveA> hi cprov 
 buildd-slave-scanner.py is spamming me. Should I disable it or is someone working on it atm? 
[01:27] <stub> I was going to bounce the systems on drescher once the current publishing run had finished, but I'll leave it up to cprov now ;)
[01:28] <cprov> stub: uhm .. why is it spamming you ?
[01:28] <stub> Because I'm subscribed to too many error reports topics, and it is dying because it can't create a lock file. Every thirty seconds or so.
[01:31] <cprov> stub: I'll stop and fix it
[01:48] <cprov> stub: fixed
[01:49] <stub> Anything that might repeat and I need to be aware of?
[01:51] <cprov> stub: not really, during my debugging adam has restarted it and it worked, the lockfile wasn't there anyway.
[01:52] <cprov> SteveA: have you seen malcolm today ?
[01:56] <cprov> stub: SteveA, about the soyuz/26-.., It fails in different pages, each time you report it, does it makes sense to you ? Anyway, I'm updating it to testbrowser, so you can help me to debug the problem. 
[02:02] <stub> cprov: My failures were consistently on line 112
[02:03] <stub> I don't know about matsubara's or anyone elses
[02:04] <stub> always expecting the alsa-utils entry to fail but getting success instead
[02:07] <cprov> stub: yes, matsubara had other, IIRC
[02:07] <stub> Hmm...
[02:07] <cprov> stub: I've experienced that before, need to accept alsa twice before it
[02:08] <cprov> stub: even if I've added a check in the queue state machine to raise an error if you try to same status again.
[02:12] <cprov> stub: the queue state machine is __idempotent__, but if you duplicate the alsa-utils accept action, it won't fail and the rest will pass, could you check it locally for me ?
[02:13] <stub> Tests pass fine for me here - or did you want me to check for some other reason?
[02:13] <stub> PQM box had the trouble
[02:14] <cprov> stub: uhm, right, nevermind, the same here at this point, but I've really experienced what I described before in my local machine. Any clue ?
[02:16] <stub> Not really. I think we should rework the tests with the newer test infrastructure so they are easier to follow and less noisy and try to land. If it gets through PQM we can just wait until it dies again.
[02:17] <cprov> stub: it looked like one request simply wasn't commited (but I know it's a very simplistic approach to the problem ...)
[02:17] <stub> (and maybe it won't, indicating something odd going on with the old test machinery?)
[02:18] <cprov> stub: indeed, malcolm has it in place, I'm just waiting he shows up. 
[02:36] <SteveA> cprov: malcolm won't be around today i expect
[02:36] <SteveA> cprov: it is a public holiday in the UK
[02:37] <stub> I doubt the test fix is a top priority (?)
[02:37] <cprov> SteveA: ohh, right, forgot it. I'll call him them. Thank you 
[03:16] <kiko> bom giorno
[03:17] <kiko> cprov!
[03:17] <lifeless> bom bom
[03:17] <lifeless> night all
[03:17] <kiko> night lifeless 
[03:18] <ddaa> crap!
[03:18] <ddaa> graaaaaah!
[03:18] <ddaa> baz-import test suite blocking cscvs merge AGAIN !!!!!11111111ONEoneONEoneONEoneONEoneONEone
[03:19] <cprov> kiko: hey
[03:21] <kiko> cprov, back already!
[03:21] <cprov> kiko: yup, plenty of TODO tasks, as expected
[04:01] <carlos> SteveA: hi
[04:01] <carlos> around?
[04:14] <SteveA> carlos: i'm around a little bit.
[04:15] <kiko> hey SteveA 
[04:15] <kiko> thanks for handling the production firefighting over the weekend
[04:15] <carlos> SteveA: A user told me that he sees some translations getting the fuzzy flag from time to time
[04:16] <carlos> he fixes it and then, the fuzzy flag is restored (fuzzy = Needs review in our UI)
[04:16] <carlos> we don't track who changes it
[04:17] <carlos> but I guess we should do it, to track this kind of problems
[04:17] <carlos> until that's done, is there any way to debug it from apache's logs or any other kind of logs we have?
[04:18] <SteveA> in what ways can the fuzzy flag be changed?
[04:18] <SteveA> i mean, on what pages can it be changed?
[04:18] <SteveA> is it changed by other processing?
[04:18] <kiko> on the translation page itself
[04:19] <SteveA> as the translation page will be submitted with a POST, we do not keep the data that was posted
[04:19] <kiko> you mean the previous state?
[04:20] <SteveA> it may be possible to find something in the database logs
[04:20] <kiko> or, well, what?
[04:20] <kiko> ah.
[04:20] <kiko> I think carlos is asking about a Rosetta feature
[04:20] <kiko> more than debugging this specific instance
[04:20] <kiko> (right?)
[04:21] <carlos> SteveA: it's changed using the form
[04:21] <carlos> kiko: well, I'm going to implement at some point a feature to track those changes
[04:22] <kiko> right
[04:22] <carlos> kiko: I would want to debug it, if possible, to know if it's caused by an user changing it or a Rosetta bug
[04:22] <kiko> oh I see
[04:23] <carlos> I think it's a user, but sounds weird that someone is setting it and another is removing it...
[04:23] <carlos> more than once in the last month
[04:23] <kiko> stub, ping?
[04:24] <stub> kiko: pong
[04:24] <kiko> stub, given the production issues we're having, what is the forecast for production updates?
[04:24] <kiko> (in particular the shipit update, but other updates are also welcome)
[04:24] <SteveA> carlos: start just by adding simple log statements
[04:25] <SteveA> carlos: we can find those in the log files
[04:25] <stub> I was thinking tomorrow. Production issues don't change anything.
[04:25] <kiko> stub, well, they only change that ideally you have a steady state to be able to track down what is causing issues (if it goes away magically)
[04:25] <kiko> stub, but if you think it's not something to consider, then great. do you have a proposed revision, or are you taking suggestions?
[04:25] <carlos> SteveA: ok
[04:26] <stub> There is nothing to track down really - until it happens again we don't have leads
[04:26] <carlos> stub: didn't it happen again today?
[04:26] <stub> Which reminds me - stevea's patch needs to get put into rocketfuel
[04:26] <stub> carlos: Not that I'm aware.
[04:26] <kiko> stub, your modified version, hopefully :)
[04:26] <kiko> stub, happened this morning at 6:45 UTC I believe via launchpad mail
[04:27] <SteveA> i've asked jamesh to improve the patch as part of his signal-to-dump-state work
[04:27] <SteveA> so that we will be using OOPS-system-id and thread-index rather than thread-object-id
[04:27] <stub> I don't seem to have it. Did anyone get the request dumps?
[04:28] <kiko> SteveA?
[04:28] <SteveA> what is your question kiko?
[04:29] <SteveA> i did not restart production servers since early yesterday or so
[04:29] <SteveA> and i have mailed the launchpad list for each restart
[04:29] <kiko> oh was the yeah yeah mail a sunday mail?
[04:29] <SteveA> a saturday one i think
[04:30] <SteveA> and that prompted me to write the (flawed) patch to capture request data at the start of request processing
[04:30] <Kagou> hi
[04:30] <kiko> SteveA, sorry bout that. thanks for clarifying.
[04:30] <kiko> stub, so, do you have a proposed RF revision?
[04:30] <stub> kiko: Nope ;)
[04:30] <kiko> stub, okay, I'll give you some suggestions.
[04:31] <Kagou> is there anyone who have time to change or to explain me how to change the name of my specification (i made a mistake).
[04:31] <kiko> Kagou, certainly. what's the spec URL?
[04:32] <Kagou> kiko, https://launchpad.net/distros/ubuntu/+spec/vetselpatrice
[04:33] <Kagou> kiko, i made mistake on his name "vetselpatrice" ... "share informations" is better or what you want
[04:34] <kiko> Kagou, I'll change it for you. one moment.
[04:34] <Kagou> np
[04:35] <kiko> https://launchpad.net/distros/ubuntu/+spec/network-information-sharing
[04:35] <kiko> you should update the link at 
[04:35] <kiko> https://wiki.ubuntu.com/SharingInformations
[04:37] <Kagou> kiko, done. Thanks
[04:38] <stub> kiko: r3611 might be scary. I'm thinking r3610 with r3614 cherry picked (the session change that is already live in production)
[04:42] <kiko> stub, what about your suggestion, r3613?
[04:42] <kiko> other than that I think I agree
[04:42] <kiko> I think it's worth testing the shipit patch
[04:44] <stub> kiko: Do  we know how often duplicate requests are a problem?
[04:44] <stub> kiko: I'm happy to put r3613 out too, 
[04:45] <kiko> stub, they occur at least once a day, so I think it's worth it.
[04:45] <stub> ok. Didn't realize it was that often.
[04:45] <kiko> great, we have a deal then. 
[04:45] <kiko> yeah, that's why I was trying to get it done earlier rather than later
[04:46] <stub> bradb: Is anyone going to cry if implicit bug contact subscriptions doesn't go out until next week?
[04:46] <bradb> stub: doubt it. they've already been without for a while.
[04:46] <kiko> crct
[04:47] <kiko> I just choked on a shred of beetroot!
[04:49] <ddaa> stub: is there any trick for rolling out launchpad ATM
[04:49] <ddaa> stub: or can I just build a 1.63-based config and roll that out to branch-scanner?
[04:50] <stub> ddaa: No tricks. production/1.63 is all up to date
[04:50] <ddaa> okay, thought there might have been a skew between rocketfuel and production zope or something
[04:50] <stub> ddaa: There was for a bit but I brought it back in sync on sunday
[04:51] <stub> oh - zope. Nope - not difference.
[04:53] <Kagou> cya
[05:04] <skippy_> how can I de-activate my Launchpad account so that i can re-create it using  a better name?
[05:04] <kiko> skippy_, you can just rename it. no need to deactivate.
[05:05] <skippy_> I didn't see how to rename it. 
[05:05] <kiko> what's your url?
[05:06] <stub> kiko: Can we put off the rollout until post Gold release? mdz wants to avoid any variables delivering Ubuntu on schedule.
[05:06] <stub> Gold is Thursday.
[05:06] <kiko> stub, okay if you roll out the shipit patch by itself, yes.
[05:06] <kiko> stub, patch/patches
[05:06] <stub> Got a list of the important ones handy?
[05:06] <kiko> yes
[05:07] <stub> 3605...
[05:07] <stub> 3606
[05:08] <kiko> r3589, r3590, r3595, r3597, r3608, r3613, r3605
[05:09] <stub> Not 3606, 3608 & 3610?
[05:09] <kiko> those too
[05:11] <kiko> that's it
[05:12] <kiko> mdz just called me to make sure I understood that THIS ROLLOUT CAN NOT FAIL :)
[05:12] <stub> Ok. I'll build the production branch and roll out tomorrow at around 05:00 UTC
[05:12] <kiko> thanks stub 
[05:12] <fabbione> kiko: consigliere... 
[05:13] <stub> Should be no hassles unless someone snuck in a database patch in that set
[05:13] <fabbione> kiko: i can see you understood perfectly the message... :)
[05:13] <fabbione> kiko: this rollout will not fail
[05:13] <kiko> fabbione, or else the horse gets the axe!
[05:13] <fabbione> kiko: and 
[05:13] <fabbione> kiko: and you the head
[05:24] <ddaa> stub: what do you use to build launchpad configs?
[05:24] <ddaa> I have a scrip based on "bzr branch", but it gets confused by launchpad being some sort of weird shared-repo-with-a-branch thing
[05:25] <stub> ddaa: rsync
[05:25] <ddaa> stub: to _build_ the launchpad config to rsync
[05:25] <stub> ddaa: I just rsync rocketfuel-built from chinstrap and then bzr pull --overwrite the branch I want
[05:26] <stub> ddaa: 'cause trying to run config manager on balleny gives me the shits
[05:26] <ddaa> okay
[05:26] <ddaa> will do as you do, then
[05:28] <ddaa> stub: I had a script that did the equivalent of cm build, but replaced the sftp:// url by local urls
[05:29] <ddaa> so it took only a long time, but not forever
[05:32] <stub> ddaa: Its more that stuff is installed all over the place, I'm never sure of what versions of Python libraries to put in my PYTHONPATH and can't be arsed updating my PYTHONPATH anyway.
[05:36] <Yannig> Hello everybody
[05:36] <Yannig> Could someone please tell me how I could have create a mailing list for the Occitan translation team?
[05:38] <kiko> Yannig, launchpad doesn't provide mailing lists -- you need to do it yourself!
[05:39] <Yannig> kiko> I asked at https://lists.ubuntu.com/mailman/listinfo/ (as everybody I think) but they don't even dare to answer :(
[05:40] <kiko> Yannig, AFAIK we don't host mailing lists for translation teams, but.. I'm not sure. carlos, do you know?
[05:41] <carlos> kiko: we do it for ubuntu-l10n-XX teams
[05:41] <carlos> at lists.ubuntu.com
[05:42] <carlos> outside launchpad
[05:42] <carlos> Yannig: did you talk with jdub?
[05:42] <Yannig> carlos> I tried, but he never answered
[05:42] <carlos> Yannig: I guess he's sleeping atm
[05:42] <carlos> Yannig: he lives in Australia
[05:42] <carlos> Yannig: so you should try it before you go to sleep or early in the morning
[05:43] <carlos> Yannig: I guess you tried sending an email, right?
[05:43] <Yannig> Thanks :)
[05:44] <Yannig> I sent a may at mailman@lists.ubuntu.com (as asked I can't remember where) 11 days ago
[05:45] <carlos> Yannig: try mailing him directly
[05:45] <carlos> jdub@ubuntu.com should work
[05:45] <carlos> hmm no, sorry, the right one is:
[05:45] <carlos> Jeff Waugh <jeff.waugh@ubuntu.com>
[05:45] <Yannig> Great, thanks :)
[11:29] <lifeless> morning
[11:51] <SteveA> lifeless: morning.  strange that as soon as we add better diagnostics to launchpad, the darn thing works properly...
[11:53] <lifeless> SteveA: grah!
[11:53] <lifeless> hiesenbug