[00:00] <lifeless> poolie_: whats the link you added to creatingnewprojects for ?
[00:00] <poolie_> lifeless: i think people will google 'create launchpad project' end up there and be confused
[00:01] <lifeless> ok, I think it needs refinement though
[00:01] <poolie_> sure
[00:01] <poolie_> just wanted to give people a chance to understand it is not rules about launchpad as a whole
[00:01] <poolie_> typical quoting problem
[00:35] <wgrant> Where did the 15 new bugs come from? :/
[02:12] <wgrant> Erm
[02:13] <wgrant> http://blog.launchpad.net/cool-new-stuff/better-bug-subscriptions was published yesterday, but it shows the UI from when the feature was released, which is completely different from the current one :/
[02:14] <wgrant> Should we unpublish until it's fixed?
[02:14] <wgrant> Oh, it's at least not frontpaged.
[02:18] <lifeless> eyeballs requested: https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess
[02:21] <wgrant> lifeless: Have we analysed recent patches to see how many of them are doable without simultaenous changes?
[02:22] <lifeless> wgrant: not rigorously, but we haven't been trying to do it either, so what we've done isn't a baseline
[02:22] <lifeless> wgrant: we know that all the ha services out there manage
[02:24] <wgrant> lifeless: I think we should before we go much further, so we don't get ourselves into trouble.
[02:24] <wgrant> Since we're throwing away read-only (which I still find fairly unwise)
[02:25] <wallyworld_> lifeless: about your document ^^^: in the Deploying Patches section, "After successful QA on a patch, ...". I take it that is for hot patches. Cold patches are deployed once a month during out downtime deployment. Shoudl that text say "After QA on a hot patch, ..."?
[02:25] <lifeless> wallyworld_: not any more
[02:25] <lifeless> wallyworld_: you might want to read yesterdays performance tuesday mail ;)
[02:26] <StevenK> wgrant: Do you think the removal of the bazaar-experts celebrity is QA-able?
[02:26] <wallyworld_> lifeless: i read it but it clearly has gone in one ear and straight out the other :-(
[02:26] <wgrant> StevenK: Check that you have branch access, possibly check that LOSAs do.
[02:27] <StevenK> wgrant: I can change the details of an owned branch, good enough?
[02:28] <wgrant> StevenK: Indeed.
[02:29] <lifeless> wallyworld_: there are now no scheduled monthly patch windows
[02:29] <lifeless> wallyworld_: over the next 4 weeks we'll be bringing up the process for doing short downtime multiple times a week
[02:29] <lifeless> wallyworld_: (short => less than 300 seconds)
[02:29] <lifeless> wallyworld_: and all patches landing from here on in need to be compatible with that process
[02:30] <wallyworld_> lifeless: ah, right. thanks. for that 300 seconds, lp will be in ro mode?
[02:30] <wallyworld_> this will be a fantasic change
[02:31] <lifeless> no, just db connections refused
[02:31] <lifeless> going into readonly mode and out again takes an hour
[02:31] <wgrant> lifeless: In the current implementation.
[02:31] <wgrant> There is nothing that requires that.l
[02:31] <lifeless> wgrant: sure, and if someone wants to work on that they can
[02:32] <wgrant> Even in the current model, where we have to rebuild the slave because slony is crap.
[02:32] <wgrant> Touch file, detach slave, upgrade, remove file, rebuild slave.
[02:32] <wgrant> No slower than blocking connections.
[02:32] <lifeless> so no
[02:32] <lifeless> we're not detaching slaves or rebuilding them.
[02:32] <wgrant> Why not?
[02:32] <lifeless> thats a cause of about 90% of our downtime delays.
[02:32] <wgrant> We can easily do this without downtime...
[02:33] <lifeless> I don't object to a great implementation of readonly mode. But readonly mode must not make the downtime longer or riskier.
[02:33] <lifeless> Currently it does.
[02:33] <wallyworld_> if db connections are refused for 5 minutes, the users will see page timeouts?
[02:33] <lifeless> And its not at all clear to me that that can be fixed on slony.
[02:33] <wgrant> Can we tell SSO to GTFO of our DB and move to a sensible replication strategy?
[02:34] <lifeless> wgrant: not in the same timeframe as this project ;)
[02:34] <lifeless> wallyworld_: they will see a horrible mess in the very first cut, but we'll iterate.
[02:34] <wallyworld_> cool, just checking :-)
[02:34] <wgrant> lifeless: "a horrible mess" meaning a maintenance page?
[02:34] <lifeless> like, the appservers can show a fail-UFO page when they can't connect to the DB eventually
[02:34]  * wallyworld_ was also wondering that
[02:35] <wgrant> Unlike slony, reloading apache isn't risky.
[02:35] <lifeless> wgrant: according to losas it is.
[02:35] <wgrant> They are wrong :)
[02:35] <lifeless> wgrant: they are the ones dealing with our apaches not restarting cleanly today.
[02:35] <lifeless> wgrant: so, I beg to differ.
[02:35] <wgrant> We have had a lot of rollout problems, and that is not one of them that I've ever heard of.
[02:35] <wgrant> So we have rollout problems that are hidden from us? Yay.
[02:35] <lifeless> wgrant: we don't restart apache during our rollouts.
[02:36] <spm> minor correction. we graceful apache on crowberry.
[02:36] <lifeless> ah, one.
[02:36] <wgrant> We can't just leave the appservers silently broken for 5 minutes.
[02:36] <spm> branch rewriter thingybobby
[02:37] <lifeless> wgrant: 5 minutes is not the target; its the absolute outer limit
[02:37] <wgrant> Perfect is the enemy of good, but terrible is the enemy of not looking like we are useless.
[02:37] <lifeless> wgrant: the target is 10-20 seconds
[02:38] <lifeless> wgrant: look, if you want to jump in and make the error condition look nice, that would be awesome.
[02:38] <lifeless> wgrant: I was clear about what I was proposing on -stakeholders
[02:38] <elmo> wait
[02:38] <elmo> what?
[02:38] <elmo> what's the problem with reloading apache?
[02:38] <wgrant> That's what I said.
[02:38] <StevenK> How do I get (and reset) the OOPS count in a test? self.getOopsCount() or so?
[02:38] <elmo> re*starting* apache can be problematic
[02:38] <elmo> but reloading is just fine
[02:38] <elmo> we do it *all the time*
[02:38] <wgrant> If we can't reload Apache, we have pretty serious problems.
[02:39] <lifeless> elmo: spm was telling me a month or so back that our ones don't go cleanly occasionally
[02:39] <lifeless> elmo: I didn't get details
[02:39] <elmo> lifeless: restart yes - reload no
[02:39] <elmo> and we wouldn't need a restart to put a maintenance page in place
[02:39] <lifeless> ok, good to know. Can a script running on wildcherry drive such a change ?
[02:39] <wgrant> So I may not be insane. This is good.
[02:40] <elmo> lifeless: it could, sure
[02:40] <lifeless> ok, cool.
[02:41] <spm> lifeless: I suspect you're mixing problems there. we have a known issue where a reload won't clear a certain problem; necessitating a restart. but that's a different beastie.
[02:44] <lifeless> spm: it wasn't, but its beside the point - I'm entirely happy for us to do something you guys consider low-risk-of-fail
[02:45] <lifeless> spm: my criteria are: the core script must not block on niceties (because once downtime starts, users are indisposed regardless); and the script must not be able to be made unreliable due to non-core-tasks.
[02:47] <spm> nod
[03:55] <StevenK> wgrant: O hai, can haz review?
[04:05] <wgrant> StevenK: Which?
[04:09] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/daily-build-oops/+merge/67915
[04:20] <StevenK> wgrant: Danke
[05:08] <poolie> spiv, your patch failed again the same way
[05:09] <poolie> has anyone else seen "ImportError: No module named html5browser" inside importfascist?
[05:09] <poolie> ah i see the mail
[05:10] <poolie> nm
[05:10] <poolie> spiv i think i can fix it
[05:10] <spiv> Ah good :)
[05:22] <StevenK> lifeless: O hai, Mr OCR. Can haz review?
[05:42] <lifeless> of whut
[06:17] <wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/bug-419534/+merge/67918
[06:35] <StevenK> lifeless: Sorry. https://code.launchpad.net/~stevenk/launchpad/uploaded-packages-wrong-link/+merge/67916
[06:37] <StevenK> wgrant: r=me
[07:50] <lifeless> stub: hiya
[07:50] <lifeless> stub: after this cutover, can we do our weekly catchup ?
[07:50] <bigjools> morning
[07:51] <lifeless> o/~
[07:52] <adeuring> good morning
[07:54] <stub> lifeless: sure
[07:57] <mrevell> Hallo
[08:56] <jtv> Anyone mind if I update dogfood?  allenap, bigjools, StevenK, wgrant?
[08:56] <bigjools> jfdi
[08:56]  * jtv jfdis
[09:19] <StevenK> Any one up for reviewing https://code.launchpad.net/~stevenk/launchpad/queue-no-changes ?
[09:19] <StevenK> Bah, branch URL.
[09:21] <StevenK> https://code.launchpad.net/~stevenk/launchpad/queue-no-changes/+merge/67913
[09:25] <bigjools> StevenK: where's the bug for that?
[09:48] <StevenK> bigjools: I don't think there is one.
[09:48] <bigjools> StevenK: then what are you fixing?
[09:48] <StevenK> bigjools: Happy to file a High bug for it.
[09:48] <bigjools> just want to know more about it, 'tis all
[09:49] <StevenK> bigjools: Right. When I was working with the LOSAs to reject an ACCEPTED binary upload on germanium, the queue tool didn't work. That branch should sort it.
[09:50] <bigjools> ah ok
[09:51] <bigjools> file bug :)
[10:43] <bigjools> release the hounds - /me just made a branch that allows people to use the API to request uploads to ubuntu by copying packages from PPAs.
[10:48] <LPCIBot> Project devel build #888: FAILURE in 2 hr 5 min: https://lpci.wedontsleep.org/job/devel/888/
[10:51] <bigjools> allenap: incoming branch from me if you don't mind?
[10:53] <allenap> bigjools: Cool.
[10:57] <bigjools> tar
[10:58] <StevenK> bigjools: Can you have another look at my MP?
[10:58] <StevenK> 2 hours?!
[10:58] <bigjools> yarp
[10:58]  * StevenK peers at Jenkins
[10:58] <henninge-lunch> allenap: Hi! If you could have a look at my branch while I am away, that would be great.
[10:58] <henninge-lunch> https://code.launchpad.net/~henninge/launchpad/bug-740208-ws-regression/+merge/67937
[10:59] <StevenK> Sigh, the slave died
[10:59] <bigjools> StevenK: that's an odd test
[10:59] <StevenK> bigjools: It tests that exact code path
[10:59] <StevenK> Which is what you wanted
[10:59] <bigjools> StevenK: by inspecting the logger?
[10:59] <bigjools> shouldn't it check no email is sent?
[11:00] <StevenK> How else do I determine it did *nothing*? :-)
[11:00] <StevenK> It doesn't even get that far, it bails out extremly early
[11:00] <bigjools> so checking that no email is sent will be fine, right?
[11:00] <wgrant> StevenK: So it's going to reject it silently?
[11:00] <wgrant> That's bad.
[11:01] <StevenK> wgrant: There's no changes file and no blamer
[11:01] <bigjools> if there's no changes file what else can be done?
[11:01] <wgrant> Ah, true.
[11:01] <wgrant> Delayed copies must die.
[11:01] <bigjools> nearly there!
[11:01] <bigjools> my branch today does some of the PCJ attachment to API copies
[11:06]  * StevenK prods bigjools :-P
[11:07] <bigjools> StevenK: fix the test to check for no email, examining the debug log is gross
[11:08] <bigjools> that is the intention of the change, right?  To not blow up by attempting to send email with corrupt data (no PU)
[11:13] <StevenK> bigjools: Done.
[11:13] <bigjools> StevenK: I approved you already
[11:13] <StevenK> bigjools: Danke
[11:13] <bigjools> bitte
[11:14] <StevenK> Bring on longpoll
[11:17] <jml> StevenK: how long do we have to wait
[11:18] <jml> it's been two weeks since I saw a working demo
[11:18] <bigjools> blame lifeless, he wants all this deployment gubbins done :)
[11:18] <StevenK> I'm so tempted to reply with 'Oh noes'
[11:19] <jml> bigjools: what sort of deployment gubbins?
[11:20] <bigjools> it will be the first time we've done something with the new SOA, so the longpoll server needs its own deployment story.  We also need better metrics on it and Rabbit
[11:20] <bigjools> we'll probably look at it agan when DDs are done.
[11:20] <bigjools> and when I say "better", I mean "some" :)
[11:21] <jml> bigjools: quite a lot of stuff then
[11:21] <jml> bigjools: it'd be nice to be able to see how an external contributor could help.
[11:22] <bigjools> jml: the best place would be to help us get metrics since the rest of it's internal
[11:23] <jml> bigjools: got a list of the things you need & the format you need them in?
[11:23] <bigjools> that's a better question for lifeless
[11:23] <bigjools> let me dig up some bugs though
[11:24] <bigjools> hmm no bugs
[11:24] <lifeless> jml: the bugs are all linked from the LEP
[11:25] <bigjools> there we go
[11:25] <jml> lifeless: ok, thanks.
[11:40] <LPCIBot> Project db-devel build #720: FAILURE in 5 hr 13 min: https://lpci.wedontsleep.org/job/db-devel/720/
[11:43] <cjwatson> is https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess active as of now?  should I be refactoring my multiarch-translations branch to separate out the schema patch?
[11:49] <lifeless> cjwatson: yes
[11:49] <wgrant> lifeless says yes, but I doubt it.
[11:49] <wgrant> But for yours it can't hurt.
[11:49] <lifeless> wgrant: you also doubted making LP faster ;)
[11:49] <wgrant> lifeless: Yeah, but that didn't go from 0 to implemented in three weeks :)
[11:49] <lifeless> wgrant: indeed, it was faster :P
[11:50] <lifeless> wgrant: I want a consult with you wearing your tz-friendly soyuz-internals-specialist about the buildmaster + db resets tomorrow, if you have time
[11:51] <wgrant> lifeless: Ewww, but maybe.
[11:51] <cjwatson> wgrant: seeing as I don't really want to wait for Aug 12 :-)
[11:52] <lifeless> cjwatson: oh, for clarity
[11:52] <lifeless> cjwatson: we need *patches* to abide by that now.
[11:52] <lifeless> cjwatson: we're not live on the *deployment* side of it yet, but we're aiming to be doing that rather than a 90 minute downtime in august
[11:52] <bigjools> lifeless: FWIW I don't think the buildmaster has any issues, when I was writing it I often killed it mid-cycle and there's lots of code to recover from Bad Stuff.
[11:53] <lifeless> bigjools: thats a great comfort
[11:53] <lifeless> bigjools: did you try taking the db out from under it ?
[11:53] <wgrant> bigjools: There are a couple of consistency issues that are just about impossible to track down.
[11:53] <wgrant> But they are rare.
[11:53] <lifeless> bigjools: I figure we'll need some reconnection glue
[11:53] <bigjools> lifeless: I didn't test that.
[11:53] <cjwatson> OK; if, for the sake of argument, I posted the db part of that patch separately, might I expect it to be deployed before Aug 12?
[11:53] <bigjools> all our daemons will need reconnection glue I expect
[11:53] <lifeless> cjwatson: expect no. Pleasantly surprised, I hope so.
[11:53] <cjwatson> (and how are you tracking dependencies between the separated-out db-devel and devel targeted branches?)
[11:54] <lifeless> bigjools: https://bugs.launchpad.net/launchpad/+bugs?field.tag=fastdowntime
[11:54] <bigjools> yes :)
[11:54] <lifeless> cjwatson: for your branch, you'll need to land both components on db-devel (because we're not live on the incremental deploy steps yet)
[11:54] <lifeless> cjwatson: but you need to land them in separate landings so we know the schema change doesn't break existing code.
[11:55] <cjwatson> ok, makes sense
[11:56] <bigjools> I think I am in love with bzr switch
[11:56] <bigjools> how can I break this to my wife
[11:56] <lifeless> bigjools: offer her preferred-courtesan status
[11:56] <lifeless> bigjools: 'same job, better perks'
[11:57] <bigjools> "cour·te·san (kôr t -z n, k r -). n. A woman prostitute"
[11:57] <bigjools> she'll love that
[11:58] <nigelb> We desperately need an Ubuntu quotes db.
[11:58] <nigelb> :)
[11:59] <bigjools> perhaps some bzr-backed wiki?  *cough*
[12:13] <StevenK> nigelb: No, we *don't*.
[12:19] <nigelb> StevenK: heh
[12:19] <nigelb> StevenK: Why not? :-)
[12:19] <StevenK> Because quotes pages are dangerous.
[12:20] <StevenK> And productivity sinks. Ubuntu has enough of those. :-)
[12:20] <nigelb> Hah
[12:26] <benji> StevenK: that should go on the quotes page
[13:44] <jcsackett> henninge: ping.
[13:54] <henninge> jcsackett: Hi! ;)
[13:54] <jcsackett> henninge: hi, i'm looking at https://code.launchpad.net/~henninge/launchpad/bug-740208-ws-regression/+merge/67937, and had one question.
[13:54] <henninge> jcsackett: ask away
[13:54] <jcsackett> is this just you addressing a wart in the code you found, or was this Text/Diff thing responsible for an issue found in qa?
[13:55] <henninge> It was causing an oops
[13:55] <jcsackett> henninge: ok, then is it possible to create a test showing the oops doesn't happen anymore as part of this branch, to prove it's the fix?
[13:55] <henninge> jcsackett: Sorry, I just realized I forgot to mention more context.
[13:56] <jcsackett> henninge: no worries. just leads to me bugging you on IRC. :-)
[13:56] <henninge> jcsackett: I could try but it is a test for a corner case.
[13:57] <jcsackett> henninge: how "corner" are we talking? major pain to set up the testcase?
[13:58] <henninge> jcsackett: I am not sure. There are tests that don't trigger the error so I think something is still missing to create the same situation as in production.
[13:58] <henninge> jcsackett: But I am happy to give it a try.
[14:00] <henninge> jcsackett: did you claim the review? deryck had offered to review it. Just to avoid double work.
[14:01] <jcsackett> henninge: i was just looking it over. i claimed it, but can abstain in a comment and assign it to deryck, if he has more context to look at it with. :-)
[14:01]  * deryck doesn't mind jcsackett taking it, but is happy to do it, too
[14:01] <jcsackett> deryck, henninge: I'm OCR today, so i may as well finish it up. :-)
[14:01] <deryck> jcsackett, henninge -- works for me. :)
[14:02] <henninge> jcsackett: go ahead ;)
[14:02] <deryck> Fresh eyes are nice as well.
[14:02] <henninge> yup
[14:04] <flacoste> bigjools: i need to QA https://bugs.launchpad.net/bugs/805634
[14:04] <flacoste> bigjools: what do you suggest? I ask a losa to run populate-archive on qastaging and check the builds priority?
[14:05] <bigjools> flacoste: yes, that should work
[14:05] <bigjools> flacoste: or staging
[14:08] <flacoste> bigjools: any easy way to look at an archives builds from the UI? or should I use API, or poke the DB?
[14:08] <bigjools> flacoste: yes it'll appear in the UI
[14:08] <bigjools> flacoste: <distro>/+archives
[14:09] <bigjools> and you can examine the builds
[14:11] <abentley> deryck: chat?
[14:13] <jcsackett> henninge: given the corner-case issue, i think this looks fine. esp as the actual diff is fairly trivial. r=me.
[14:13] <henninge> jcsackett: thank you! ;)
[14:14] <deryck> abentley, sure.  let me fire up mumble.
[15:09] <flacoste> danilos: can you update the description of bug 775691 to clearly describe the low-priority corner case that it is? please
[15:10] <flacoste> gmb: i think i have the solution to your problem, and it's netierh #1, #2, or #3
[15:10] <flacoste> gmb: i'm confirming my hunch and writing a reply
[15:13] <gmb> flacoste: Cool, thanks.
[15:19] <abentley> deryck: is there a way of testing whether an object is an lp.client.Entry?
[15:20] <abentley> deryck: I would have thought you could do prototype [15:21] <deryck> abentley, instanceof will work.
[15:21] <deryck> abentley, x instanceof y
[15:21] <deryck> I don't know if yui 3 has some wrapper around this to make it nicer.
[15:23] <deryck> abentley, so a docs search shows me Assert.isInstanceOf and Y.instanceOf
[15:23] <abentley> deryck: cool.
[15:31] <flacoste> gmb: hunch failed... writing reply :-(
[15:34] <gmb> flacoste: Boo. Oh well.
[15:47] <jkakar> I'm regularly getting logged out of Launchpad... is that a temporary issue or was some change made to make this happen?
[15:48] <gary_poster> jkakar, temporary.  dbs were flipped around.
[15:49] <gary_poster> danilos, jtv, neither of you are here, but if you had a better idea on triaging https://bugs.launchpad.net/launchpad/+bug/810309 that would be great
[15:49] <_mup_> Bug #810309: Translator credits appear duplicated <Launchpad itself:Triaged> < https://launchpad.net/bugs/810309 >
[15:49] <jtv> gary_poster: I am here.
[15:50] <gary_poster> jtv, why for goodness sake? :-)
[15:50] <jtv> gary_poster: I'm in Europe, where it's still more or less working-day hours.
[15:50] <gary_poster> oh, ok, didn't know jtv
[15:51] <jtv> This bug looks like some kind of nasty loop behaviour between imports and exports.
[15:52] <jkakar> gary_poster: Cool, thanks.
[15:52] <jtv> oh, hi jkakar!
[15:53] <jkakar> jtv: Hi! :)
[16:34]  * deryck goes offline for lunch, back online in an hour
[16:44]  * bigjools waves at jcsackett
[16:48] <jcsackett> heya, bigjools.
[16:48] <bigjools> howdy jcsackett.  May I push a review in your direction please?
[16:48] <jcsackett> certainly.
[16:48] <bigjools> https://code.launchpad.net/~julian-edwards/launchpad/async-copying-part-2/+merge/67989
[16:49] <bigjools> thanks
[17:00] <jcsackett> bigjools: r=me.
[17:01] <bigjools> jcsackett: thanking you sir
[17:11] <LPCIBot> Yippie, build fixed!
[17:11] <LPCIBot> Project devel build #889: FIXED in 5 hr 59 min: https://lpci.wedontsleep.org/job/devel/889/
[17:19] <LPCIBot> Yippie, build fixed!
[17:19] <LPCIBot> Project db-devel build #721: FIXED in 5 hr 39 min: https://lpci.wedontsleep.org/job/db-devel/721/
[18:04] <flacoste> deryck, gary_poster: a new escalated bug by ISD: https://bugs.launchpad.net/launchpad/+bug/810626
[18:04] <_mup_> Bug #810626: launchpad should mark required sreg attributes  as required <escalated> <Canonical SSO provider:New> <Launchpad itself:Triaged> < https://launchpad.net/bugs/810626 >
[18:04] <flacoste> should be fairly shallow
[18:04] <deryck> flacoste, cool, thanks.
[18:04] <gary_poster> flacoste, cool, yeah, we were asking you about that one on ops
[18:04] <flacoste> but it blocks them deploying their new version as it's a potential source of problems for us
[18:05] <gary_poster> cool
[18:05] <deryck> gary_poster, what will it be?  orange or yellow?  rock, paper, scissors, lizard, Spock for it?
[18:05] <flacoste> i've only marked the one about making the fields required Critical
[18:06] <flacoste> since the other one, is only relevant when we handle multiple OPs
[18:06] <flacoste> so I marked it Low
[18:06] <gary_poster> deryck, whoever gets to first :-) we've got a couple of escalated in progress already
[18:06]  * flacoste thinks Orange should contribute to the escalated effort ;-)
[18:06] <deryck> indeed we can :)
[18:07] <flacoste> Yellow has 3 potential fixes for the week
[18:07]  * deryck didn't realize yellow had escalated bugs already
[18:07] <gary_poster> yellow hears "escalated" and comes running!  It might be...fun, or something?!
[18:08] <deryck> :-)
[18:08] <deryck> flacoste, gary_poster -- we've got a card on orange next lane now for it.
[18:09] <gary_poster> cool
[18:34] <abentley> bac: because your getnewcache is based on my json-serialisation, merging from devel creates criss-cross merges and screws up the diffs between my branch and yours.  Could you please refrain from that in the future?
[18:35] <abentley> bac: And could you please pull my ~abentley/launchpad/getnewcache, where I've fixed the criss-cross?
[18:39] <abentley> deryck: a closer look at the update_cache code shows it's correctly updating the plain json objects, rather than replacing them with Entry objects.
[18:41] <deryck> abentley, ok, thanks for the update.
[18:55] <SpamapS> Is there an API call I can do to get this list: https://code.launchpad.net/principia/oneiric
[19:34] <abentley> SpamapS: Yes: getBranches
[19:35] <abentley> SpamapS: Actually, that's on DistroSourcePackage, not DistroSeries.
[19:37] <SpamapS> abentley: you got me all excited.. ;-)
[19:37] <abentley> SpamapS: It probably exists as a method, just not exported yet.
[19:43] <gary_poster> sinzui, I'm about to file a bug about the send-person-notifications script not logging errors to the filesystem.  Am I right, or did I simply miss it?  AFAIK, one can only get the error reports from the launchpad-error-reports list, which I think is bad.
[19:43] <sinzui> gary_poster, I did not find the log. report the bug
[19:43] <gary_poster> thanks sinzui
[19:51] <lifeless> gary_poster: well it should be oopsing
[19:51] <lifeless> gary_poster: have you looked for an OOPS yet ?
[19:51] <lifeless> gary_poster: changing from stderr to a log file is an RT generally, if its a Launchpad*Script
[19:52] <gary_poster> lifeless, looked for OOPS: how and where would I do so?  I am only aware of a "if you know the OOPS id then you are in luck" interface
[19:52] <lifeless> they all get rsynced to carob
[21:23] <lifeless> flacoste: on bug 810623
[21:23] <_mup_> Bug #810623: launchpad oopses when no sreg attributes are returned by SSO <Launchpad itself:Triaged> < https://launchpad.net/bugs/810623 >
[21:24] <lifeless> flacoste: I think we should keep to the oops->critical, but do a real simple fix - make it a UFD or BadRequest
[21:24] <lifeless> flacoste: or
[21:24] <lifeless> flacoste: close it invalid
[21:52] <poolie_> hi all
[21:59] <flacoste> lifeless: might want to leave a comment
[21:59] <flacoste> deryck's squad can sort it out when they work on the main one
[22:00] <lifeless> flacoste: I will, wanted to discuss with you first ;)
[22:00] <lifeless> flacoste: so we didn't get in a bidding war
[22:00] <lifeless> flacoste: I favour the first case
[22:01] <flacoste> lifeless: i'm easy today, so whatever :-)
[22:01] <lifeless> heh, ok
[22:01] <poolie_> re https://bugs.launchpad.net/launchpad/+bug/807383 in theory it ought to be possible to work out which oops a particular user hit, shouldn't it?
[22:01] <poolie_> s//oughtn't it?
[22:02] <poolie_> or is it just a case of, if they don't work hard enough to report it we don't have a special bug for it?
[22:04] <lifeless> its not easy to find the right one (we log oops *files* for things we don't count as OOPS. [thats a bug]).
[22:04] <lifeless> also, we're still swamped, so its not like we're at the point [yet] of picking up the 3 or 4 unique oopses from the daily report and driving them to zero.
[22:18] <lifeless> poolie_: actually, another way to put it is: we track all oopses and well get them all eventually; if soneone wants to jump queue - manually filing a bug for us, thats fine, but then the onus is on them to help us out
[22:26] <poolie_> right
[22:26] <poolie_> that's pretty much what i though
[22:26] <poolie_> t
[22:35] <lifeless> oh wow
[22:35] <lifeless> sinzui: why ?
[22:35] <lifeless> New member:
[22:35] <lifeless>  (Choose…)
[22:35] <lifeless> You can't add a team that doesn't have any active members.
[22:35] <lifeless> sinzui: adding ~canonical-launchpad-emeritus to https://launchpad.net/~launchpad-emeritus/+addmember
  The most recent 90 minute downtime was the last ever.
[22:36] <poolie_> would be nice
[22:47] <LPCIBot> Project devel build #890: FAILURE in 5 hr 36 min: https://lpci.wedontsleep.org/job/devel/890/
[23:00] <sinzui> lifeless, I have never seen that issue show up. I do not know why Lp wont let you
[23:00] <sinzui> m
[23:01] <LPCIBot> Project db-devel build #722: FAILURE in 5 hr 41 min: https://lpci.wedontsleep.org/job/db-devel/722/
[23:04] <sinzui> StevenK, mumble?
[23:13] <lifeless> sinzui: I think its a mistake, because a team can be emptied after including in another team
[23:13] <lifeless> sinzui: any objection to a jfdi fix ?
[23:15] <sinzui> please jfdi
[23:22] <StevenK> win 24
[23:23] <nigelb> fail? :)
[23:23]  * StevenK kicks nigelb :-P
[23:24]  * nigelb has had a sleepless night :/
[23:25] <wgrant> lifeless: When do you want to talk?
[23:25] <lifeless> when I get off the phone with allison :)
[23:26] <lifeless> 15?
[23:29] <wgrant> Sure
[23:29] <wgrant> Attack of the TAs?
[23:29] <lifeless> :P
[23:29] <nigelb> lol
[23:30] <nigelb> wallyworld_: What time do you EOD?
[23:30] <wallyworld_> nigelb: i've only just started my day
[23:30] <nigelb> wallyworld_: I'm about to head to bed on a /very/ late night thanks to work.
[23:31] <wallyworld_> nigelb: do you want to ping me later?
[23:31] <nigelb> wallyworld_: Yeah, that's why I was trying to figure out what's your usual EOD to plan that.
[23:32] <wallyworld_> nigelb: ah, right. i'll be here for another 8-9 hours, plus i can be online tonight. there'll be a few hours in the even when i have soccer
[23:33] <wallyworld_> s/even/evening
[23:33] <nigelb> wallyworld_: In that case, I think I can figure out something today. I'll keep my devel up-to-date
[23:34] <wallyworld_> nigelb: ok. i'll wait to hear from you
[23:35] <wallyworld_> aaarrghhh. did qastaging just die?
[23:39] <wgrant> wallyworld_: Looks fine to me. Maybe it just updated.
[23:40] <wgrant> Shouldn't have, though.
[23:40] <wallyworld_> wgrant: it just came back now
[23:41] <wallyworld_> wgrant: could you do me a favour to help me qa? could you subscribe someone (not you or me) to a branch you own and then change the owner to launchpad and let me know which branch?
[23:41] <wgrant> lifeless: Do you still only do Skype?
[23:43] <wgrant> wallyworld_: https://code.qastaging.launchpad.net/~launchpad/launchpad/db-devel-merge-fix
[23:43] <wallyworld_> wgrant: awesome thanks
[23:44]  * wallyworld_ marks his bug as qa-ok
[23:44] <wgrant> Thanks!
[23:44] <wallyworld_> s/bug/branch
[23:45]  * wgrant goes to use canonicaladmin for a while, to acclimatise himself to crap software before using Skype.
[23:45] <wallyworld_> lol
[23:46] <wallyworld_> skype isn't that bad. it has pretty good echo cancellation
[23:46] <wallyworld_> seems to work better than mumble often times
[23:46] <wgrant> The echo cancellation is the only thing that is not crap.
[23:46] <wgrant> Well, and the NAT traversal.
[23:46] <wallyworld_> they're pretty important features, no?
[23:47] <wgrant> Yes, but the software itself is crap.
[23:47] <wgrant> Crashy, slow, ugly.
[23:48] <lifeless> wgrant: its easiest in a bunch of ways, if you don't mind significant feedback I can do voip
[23:48] <wgrant> I have Skype not crashing now.
[23:48] <wgrant> So we can use it.
[23:48] <lifeless> \o/
[23:59] <michaelh1> Hi there.  I'd like to import the GDB 7.3 release branch into Launchpad.  They use CVS and have a GIT mirror.  Who should I ask? (mwhudson is away)