[02:59] <jtv> How do I push a branch to staging again?  It trips me up every time.  "Read-only transport," it says, whether I use lp: or bzr+ssh:
[02:59] <lifeless> lp-staging://
[02:59] <lifeless> or is it lp://staging/...
[02:59] <lifeless> one of them
[02:59] <lifeless> if its connecting and then saying read-only, you're not in the team :>
[03:04] <rick_h_> jtv: qastaing? or staging? I used bzr push lp://qastaging/~rharding/... for qastaging with success
[03:04] <jtv> lifeless: what team?
[03:04] <jtv> rick_h_: I suppose I could try qastaging, thanks.
[03:05] <lifeless> the one you are pushing to a branch of
[03:05] <jtv> lifeless: I tried lp://staging/, which is what the UI tells me to do, but same error.
[03:05] <lifeless> jtv: what was the full url
[03:05] <jtv> lifeless: so "read-only transport" from bzr can actually mean that I don't have privileges?
[03:06] <lifeless> it means it tried to write and failed
[03:06] <jtv> lp://staging/~stellarium/stellarium/auto-po
[03:06] <lifeless> either because its using http or can't write
[03:06] <lifeless> jtv: and are you a member of ~stellarium on staging?
[03:06] <jtv> No.
[03:07] <lifeless> ok, so thats working as expected
[03:07] <jtv> Except for the misleading error message.
[03:07] <lifeless> bzr doesn't know the cause for being unable to write
[03:09] <jtv> That's not very comforting to me, is it?  It tells me "read-only transport" when there's nothing wrong with the transport, only with where I'm trying to transport to.
[03:12] <lifeless> indeed
[03:12] <lifeless> its also exactly what will happen if you push locally to a directory you only have rx bits on
[03:12] <lifeless> for instance
[03:13] <lifeless> feel free to file a bug on bzr/bzr+lp
[03:21] <lifeless> hah
[03:22] <lifeless> dead code in LP's DB migration system
[03:22] <lifeless> win
[03:22] <wgrant> lifeless: Where?
[03:22] <wgrant> jtv: Bug #894177
[03:22] <_mup_> Bug #894177: run_jobs.py pofile_stats oopses: permission denied for relation productseries <oops> <translations-handoff> <Launchpad itself:Triaged by benji> < https://launchpad.net/bugs/894177 >
[03:22] <jtv> wgrant: oh, so what I filed was a dupe.  :(
[03:23] <jtv> Looks like the script was converted to a job, and then not tested under realistic access rights.
[03:23] <wgrant> Yeah. You might want to throw your info into that one.
[03:23] <wgrant> Yes.
[03:23] <jtv> Thanks.
[03:23] <wgrant> Well.
[03:23] <wgrant> It works fine for distro templates.
[03:23] <wgrant> Just not product ones.
[03:23] <wgrant> I've tested locally and product+productseries is sufficient.
[03:24] <lifeless> wgrant: upgradelog
[03:25] <lifeless> wgrant: implemented on non-slony environments only
[03:25] <wgrant> I see no upgradelog
[03:26] <lifeless> ah, its new, not dead
[03:26] <lifeless> stub is capturing the sql executed
[03:26]  * lifeless ports
[03:26] <wgrant> Is that the thing I reverted over the weekend?
[03:26] <lifeless> yes
[03:26] <lifeless> because it was broken, yes.
[03:27] <lifeless> did it break on qastaging or staging ?
[03:28] <lifeless> if it broke on staging, its because the autodetect stuff for it was only on the non-slony case
[03:29] <wgrant> buildbot
[03:29] <lifeless> ah, interesting
[03:30] <wgrant> https://lpbuildbot.canonical.com/builders/lucid_lp/builds/1617/steps/compile_1/logs/stdio
[03:30] <wgrant>   File "upgrade.py", line 645, in get_bzr_details
[03:30] <wgrant> ValueError: need more than 1 value to unpack
[03:30] <wgrant>     branch_nick, revno, revision_id = out.split(' ', 3)
[03:33] <lifeless> hmmm, I think I want to chat to sub. And I started early today; so going to EODish. (As in , will be back later)
[03:33] <wgrant> kk
[07:09] <micahg> it
[07:09] <micahg> oops, was going to say that it's weird that I get E-Mails that I've assigned myself a bug faster than a page refresh
[07:17] <lifeless> stub: can we have a call in ~ 1 hour about trusted.sql etc and lazr_postgresql ?
[07:26] <stub> lifeless: sure
[07:48] <stub> lifeless:  https://code.launchpad.net/~stub/launchpad/db-deploy/+merge/84231  will affect this work btw
[08:10] <bkerensa> flacoste: You around?
[08:14] <wgrant> bkerensa: Probably not for a few hours yet.
[08:15] <wgrant> But there are lots of LP devs around.
[08:15] <bkerensa> wgrant: K just looking for someone on the Launchpad team to interview for Dev News about the new Beta Bug Listing Features and other things being worked on
[08:16] <wgrant> bkerensa: Most people who have been working on that (and flacoste) are in the Americas, so won't be around for a while.
[08:17] <bkerensa> wgrant: k ;) I'm in the Americas but I'm also a night owl :P so perhaps I'll catch them tomorrow (I will just idle)
[08:18] <wgrant> Heh
[08:46] <adeuring> good morning
[09:00] <frankban> good morning
[09:01] <mrevell> Hello
[09:07] <bigjools> has anyone else seen spurious errors in lp.buildmaster.tests.test_builder.TestSlave in ec2?
[09:08] <lifeless> bigjools: new bug for you - https://bugs.launchpad.net/txlongpoll/+bug/900579 - I believe its pretty shallow.
[09:08] <_mup_> Bug #900579: txlong poll reads any queue <txlongpoll:Triaged> < https://launchpad.net/bugs/900579 >
[09:08] <lifeless> bigjools: (it may just be a deployment thing in fact)
[09:08] <lifeless> bigjools: https://code.launchpad.net/+longpoll/?uuid=oopses&sequence=1 is a good url to make the impact clear ;)
[09:08] <bigjools> lifeless: yeah, I tend to err on the side of permissions
[09:08]  * lifeless really really goes now
[09:26] <allenap> lifeless: Interesting (re. https://code.launchpad.net/~lifeless/storm/bug-618019/+merge/34715). I may borrow that for an experiment. Ta.
[09:44] <wgrant> bigjools: huwshimi had one of those yesterday. First I'd seen of it.
[10:47]  * cjwatson bangs his head against bug 713764
[10:47] <_mup_> Bug #713764: fake librarian columns cannot be looked up by storm <Launchpad itself:Triaged> < https://launchpad.net/bugs/713764 >
[10:47] <stub> How do I revert a reversion on my branch?
[10:49] <jelmer> stub: merge a reversion of the reversion :)
[10:49] <jelmer> stub: e.g. "bzr merge -r-5..-4 ."
[10:49] <stub> I mean the magic commit message tags - list it as a reversion there?
[10:49] <jelmer> ah
[10:50] <jelmer> stub: I'd add the same tags as in the original commit that landed it [bug=YYYYYY][r=...] etc, and a comment saying it's relanding something that was rolled back
[10:50] <cjwatson> There must surely be other examples in LP of mock objects wrapping Storm objects that can still manage to be looked up by Storm, but I can't find a pattern that works
[10:51] <cjwatson> Maybe I'll just have to use the full librarian the way everyone else who's run into this seems to have done :-/
[10:53] <StevenK> stub: [rollback=<rev>]
[10:53] <StevenK> stub: And tag the bug as bad-commit-<rev>
[10:53] <stub> There is no bug
[10:53] <stub> So that step is easy I guess ;)
[10:54] <jelmer> StevenK: wouldn't that just be for the rollback itself, rather than the rollback of the rollback?
[10:55] <StevenK> I'm guessing stub is rollbacking the commit, so [rollback= is fine
[10:56] <wgrant> He's rollbacking my rollback.
[10:56] <stub> The commit has already been rolled back. I'm rolling back that rollback (reapplying with what hopefully will fix the issue)
[10:56] <wgrant> No [rollback= required.
[10:56] <stub> k
[10:56] <stub> My next trick would have been self referential rollback= statements to mess with qa-tagger
[10:57] <wgrant> You're a bad person.
[10:57] <stub> qa-tagger is broken. Early Christmas break everyone!
[10:59] <bigjools> \o/
[11:17]  * cjwatson tries to understand http://paste.ubuntu.com/761501/
[11:17] <cjwatson> What, in general, do I need to do to let my tests get hold of an archive's PublisherConfig?
[11:23] <bigjools> cjwatson: you are running in the wrong layer
[11:23] <bigjools> you need zopeless
[11:24] <cjwatson> I thought zopeless didn't give me a librarian
[11:25] <cjwatson> however now that I work my way through the class hierarchy I see that's wrong
[11:27] <cjwatson> Thanks.  Onto the next failure :-)
[11:31] <rick_h_> morning party people
[11:32] <wgrant> I really should delete ZopelessLayer at some point.
[11:32] <wgrant> Since it doesn't actually do
[11:32] <wgrant> much different any more.
[11:35] <allenap> wgrant: Can you remove all layers please?
[11:35] <wgrant> Turning the class hierarchy into a stick is a good way to start :)
[11:36] <allenap> wgrant: Me no comprendo.
[11:36] <wgrant> If the layer hierachy is closer to a stick than the complex tree it is now, it becomes easier to deal with .
[11:38] <allenap> wgrant: You're being pragmatic again.
[11:38] <wgrant> :(
[11:39] <allenap> wgrant: One layer less would be a very healthy step.
[11:39] <wgrant> Well, crucially, killing of ZopelessLayer also kills off ZopelessDatabaseLayer, LaunchpadZopelessLayer, and ZopelessAppServerLayer.
[11:40] <bigjools> layers were a hack to have slow-starting fixtures available across tests
[11:40] <bigjools> I think TestTools is gaining this ability RSN
[11:41] <allenap> wgrant, bigjools: I'm sure we could come up with a layer-like wrapper around testresources. I experimented with something similar once before.
[12:44] <jml> yay death to zopeless layer!
[12:50] <rick_h_> gmb: you still around for a review?
[12:50] <gmb> rick_h_: Sure
[12:50] <rick_h_> gmb: https://code.launchpad.net/~rharding/launchpad/inline_editor/+merge/84528
[12:50] <rick_h_> gmb: thanks
[12:50] <gmb> Woah
[12:50] <gmb> rick_h_: That's 1899 lines of diff
[12:51] <rick_h_> well mostly -
[12:51] <rick_h_> gmb: yea sorry, ripped out a lot
[12:51] <gmb> rick_h_: Our usual per-branch limit is 800. I won't be able to review that in the time I have left online today.
[12:52] <gmb> rick_h_: You'd be better off talking to someone on your squad to see if they have the time to take a look at that.
[12:52] <rick_h_> gmb: cool, thanks
[12:52] <gmb> Np
[13:58] <Daviey> In regards to package set ACL access, is it viable to add a 3rd type, to help with package to team bug triaging?
[13:58]  * Daviey asks to see if it is worth raising a bug.
[14:32] <deryck> abentley, ping for standup.
[14:35] <abentley> adeuring: bug 894836
[14:35] <_mup_> Bug #894836: Wrong order-by widget is highlighted when the page has loaded a previously select preference <bug-columns> <Launchpad itself:Triaged> < https://launchpad.net/bugs/894836 >
[15:03] <cjwatson> Anyone fancy reviewing https://code.launchpad.net/~cjwatson/launchpad/refactor-cron-germinate/+merge/84624 ?
[15:08] <jtv> cjwatson: it's too late for me right now, but please tell me that's your massive speedup branch!
[15:10] <cjwatson> It is
[15:10] <cjwatson> Not that I've actually run it in situ yet to demonstrate speedup, merely a stripped-down version on my laptop
[15:11] <jtv> Agonizing.  Human intuition is notoriously unreliable for these things.  Looking forward to seeing the real-world difference!
[15:12] <cjwatson> Indeed.  I can't really tell for absolute sure without a full Soyuz instance, which is likely to be a bit much for anything I have locally :-)
[15:12] <cjwatson> But I'm reasonably confident.
[15:13] <cjwatson> There's a factor of three in the right direction between the old version on cocoplum and the stripped-down version on my laptop.  I don't think all of that can be overhead, and if my laptop is that much faster than cocoplum we're all in trouble. :-)
[15:15] <jtv> We should all have laptops as fast as cocoplum!
[15:16] <cjwatson> I might try syncing over Packages and Sources to mawson and running the stripped-down version there, or something
[15:16] <cjwatson> Or even as an unprivileged user on cocoplum at a quiet time in the hour
[15:17] <jtv> Not a job for dogfood?
[15:17] <cjwatson> Yeah, mawson's probably better for it
[15:17] <cjwatson> As long as I do a control run with current Packages/Sources first
[15:18] <cjwatson> The control run I did yesterday took six minutes and produced output considerably smaller than current production, so I don't think it's a good comparator
[15:18] <cjwatson> (comparand?)
[15:18] <jtv> The latter, I suspect.
[15:18] <jtv> But it's not my language.  :)
[15:28] <bigjools> jtv: you don't get off that easily, you speak it better than the average teenager
[15:33] <jelmer> ... and somehow manage to speak it without the annoying Dutch accent
[17:12] <cjwatson> bigjools: perhaps this is premature, but at some point when you have a chance, I'd like to chat about the next stage in improving how germination is done: I'd like to move it before apt-ftparchive, so that we get rid of hysteresis and avoid the occasional need for manual action when seeds change
[17:12] <bigjools> cjwatson: sounds good
[17:12] <cjwatson> and I'd like to make sure I understand how to slot that into the publisher properly
[17:12] <bigjools> is there a publisher hook for that stage?  I can't remember
[17:12] <cjwatson> I think it would go in between B and C - there's no hook there at this point
[17:13] <bigjools> ok, easy to add
[17:13] <cjwatson> you think it ought to be a hook?  It'll need to talk to the DB
[17:13] <cjwatson> so presumably can't just be the out-of-process kind of thing that distro-parts is
[17:13] <bigjools> well germination is an Ubuntu thing - at least nothing else needs it but perhaps it might in the future
[17:14] <cjwatson> agreed
[17:14] <cjwatson> some kind of in-process hook then
[17:14] <bigjools> there's no reason why it can't be a run-parts that access the DB
[17:14] <cjwatson> oh - yeah, of course, duh, my generate-extra-overrides is exactly such a thing
[17:15]  * cjwatson <- idiot
[17:15] <bigjools> it's the soyuz effect, roll with it :)
[17:15] <cjwatson> I'd like to have it mark pockets dirty when seed output changes, too; I guess there's no reason a hook couldn't do that as wewll
[17:15] <cjwatson> *well
[17:15] <bigjools> hmmm yes, that could be quite useful
[17:16] <cjwatson> then no more having to keep the odd universe package in a queue around release time just in case we need to change seeds in a hurry, whee
[17:18] <cjwatson> pre-index.d sound OK as a name?  (strawman)
[17:18] <bigjools> yup
[17:19] <cjwatson> then I get to find out whether I got the germinate API for this right ...
[17:20] <cjwatson> there's a method that's supposed to yield a sequence of (enum, {header: value, ...})
[17:22] <cjwatson> so I think I do dict(.buildIndexStanzaFields) on every PUBLISHED [SB]PPH and feed that in
[17:25] <cjwatson> what I don't know is whether doing that extra [SB]PPH query (basically the same as those in _writeComponentIndexes) will be significantly slower than having germinate read and parse Packages/Sources; do we have numbers on how long the _writeComponentIndexes queries take on something Ubuntu-sized?  I know we aren't using that mode in Ubuntu at the moment
[17:35] <bigjools> cjwatson: I suspect that reading from the DB is always going to be quicker than parsing a file
[17:37] <cjwatson> bigjools: oh good
[17:39] <bigjools> cjwatson: we used _writeComponentIndexes stuff on Ubuntu on dogfood once just to see what it did and it was comparable to running a-f in fact.  I'm sure we can optimise it some more.
[17:39] <bigjools> the slow part of using a-f is writing its input files...
[17:40] <cjwatson> it would get a bit slower if it were made fully-compatible - for instance it'd have to read extra override files
[17:40] <cjwatson> (or we'd have to stuff them into the db)
[17:40] <bigjools> yeah
[17:40] <bigjools> well I want those in the DB
[17:40] <bigjools> I want everything in the DB
[17:40] <bigjools> then other parts of LP can benefit
[17:41] <cjwatson> *cough* https://launchpad.canonical.com/ExtraPackageOverrides
[17:42] <bigjools> yeah :)
[17:44] <cjwatson> comparable to running a-f> germinate parsing those files takes seconds, so it needs to be in that ballpark
[17:45] <bigjools> well I am talking overall publisher speed
[17:48] <bigjools> right, EOD for me, good night all
[17:49] <bigjools> hmm the update manager could do with a "shutdown after installing" option
[18:13] <abentley> deryck: There's no OCR.  Could you review https://code.launchpad.net/~abentley/launchpad/fix-spinner-bugs/+merge/84633 please?
[18:14] <deryck> abentley, sure
[18:15] <abentley> deryck: thanks.
[18:21] <deryck> abentley, I don't know if I understand fetch_only.
[18:21] <deryck> abentley, does that mean, "we're doing XHR only" or "we're only changing out lists" or something else?
[18:22] <abentley> deryck: it means fetch the data, but don't render it.
[18:22] <deryck> abentley, ah ok. so we're still showing the spinner regardless of if the list is loaded from cache or XHR?
[18:24] <abentley> deryck: technically yes, but when the list is loaded from the cache, the spinner is hidden again so quickly that you don't see it.
[18:24] <deryck> abentley, right, that's fine.
[18:24] <rick_h_> abentley: the main reason we added it so that the re-scroll to top would take effect if the data came from cache/not
[18:24] <rick_h_> does that still take place?
[18:25] <abentley> rick_h_: I expect it does.
[18:25] <rick_h_> abentley: ok cool
[18:26] <rick_h_> ic, the .success is always called, but the spinner might not have been visible. So we basically reassert it's hidden and run scroll to top
[18:27] <abentley> rick_h_: success is only called if the event succeeded, and only if we were loading the batch in order to display it.
[18:27] <deryck> abentley, r=me.
[18:28] <abentley> deryck: thanks.
[18:56] <rick_h_> benji: howdy, api question for you if you've got a sec
[18:56] <benji> rick_h_: shoot
[18:57] <rick_h_> so I'm looking at bug: https://bugs.launchpad.net/launchpad/+bug/808952
[18:57] <_mup_> Bug #808952: NoCanonicalUrl using api to fetch bug comments <api> <oops> <Launchpad itself:Triaged by rharding> < https://launchpad.net/bugs/808952 >
[18:57] <rick_h_> and went checking out how the canonical url data stuff works
[18:57] <rick_h_> and it seems the url generated in this oops was /1.0/ubuntu/+source/b...
[18:57] <rick_h_> which fails, but if you /version/1.0 it works
[18:57] <rick_h_> or take out the 1.0 completely
[18:58] <rick_h_> so it seems to be something more in launchpadlib generating the urls?
[19:17] <rick_h_> benji: oh sorry, I messed up. The "response" is a 404 when you take off the 1.0. I didn't realize that.
[19:19] <benji> rick_h_: I'm glad you figured it out -- because I had gone to other things while you wrote and then forgot you had asked :(
[19:19] <rick_h_> well, nothing figured out as far as the original issue, but at least I misunderstood it and got past that
[19:19]  * benji wonders if he's the only one that needs people to mention his name to remember that they're talking to him.
[19:20] <rick_h_> benji: no, I'm supposed to be working on that
[19:20] <rick_h_> benji: updating irc habits along with other things
[19:20] <benji> rick_h_: in that case let me check your question and see if I can suggest anything
[19:21] <rick_h_> benji: basically something is up with the api talking to/about comment #11 on that bug
[19:21] <rick_h_> benji: if I loop through all comments using the api it works, but if you try to link directly through the api to comment 11 it fails.
[19:21] <rick_h_> benji: https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/805938/comments/11 works though
[19:21] <_mup_> Bug #805938: Totem set as default music player after install instead of Banshee <apport-bug> <i386> <iso-testing> <oneiric> <patch> <running-unity> <unity-2d> <unity:Fix Released> <banshee (Ubuntu):Invalid> <desktop-file-utils (Ubuntu):Fix Released> <unity (Ubuntu):Fix Released by canonical-dx-team> <banshee (Ubuntu Oneiric):Invalid> <desktop-file-utils (Ubuntu Oneiric):Fix Released> <unity (Ubuntu Oneiric):Fix Released by canonical-dx-team> <
[19:22] <benji> rick_h_: I don't remember exactly how the URL generation is divvied up between LP and lazr.restful, but lazr.restful isn't very big and that's where I'd look first
[19:22] <rick_h_> benji: ok cool. Will head there. I've been chasing the ICanonicalDataURL stuff in LP up until now
[19:23] <lifeless> statik: flacoste: just confirming we have a call in 70 minutes? (e.g. did the calendar work...)
[19:24] <flacoste> lifeless: yes
[19:24] <flacoste> lifeless: 66 minutes actually :-)
[19:24] <lifeless> clickety click
[20:43] <abentley> deryck: I'm looking at bug 892211 and I can see the problem: updateFieldVisibilty is calling _extraRenderUI(), which is calling updateFromCookie.  Can we talk about solutions?
[20:43] <_mup_> Bug #892211: reset to default in bug listing visibility widget doesn't work <bug-columns> <Launchpad itself:Triaged> < https://launchpad.net/bugs/892211 >
[20:46] <bac> hi flacoste -- can we decide on the lplib recipe and get it done?
[20:48] <flacoste> bac: on the phone, will ping you when i'm done
[20:48] <bac> flacoste: perfect
[20:57] <deryck> abentley, I'm not available today. cast about for someone else, or I can chat with you about it tomorrow.
[20:57] <abentley> deryck: okay.
[20:58] <sinzui> We have a branch that hardens teams to such a degree, that to write a test that logs in as the teamowner, you must first login as an admin
[20:58] <sinzui> I think I will take a 30 minute break to ponder the irony
[21:09] <lifeless> bac: out of tree is best here
[21:09] <lifeless> bac: leverage (ha hate that phrase) the ubuntu packaging
[21:09] <flacoste> bac: besides what lifeless is saying
[21:09] <flacoste> what other open issues remains?
[21:10] <flacoste> given jelmer pointers, i agree that having the debian tree separate is best
[21:10] <bac> flacoste: where to put it. ~launchpad vs ~lazr-developers
[21:10] <flacoste> i think ~launchpad is better
[21:10] <flacoste> ~lazr-developers is hysterical raisins to me
[21:10] <lifeless> branch ownership?
[21:10] <lifeless> Its in the wiki
[21:10] <lifeless> see dev.launchpad.net/CreatingNewProjects
[21:11] <bac> lifeless: recipe ownership
[21:11] <lifeless> (tl;dr: ~canonical-launchpad-branches)
[21:11] <lifeless> LP is in that team, but so are other canonical folk like ex-launchpadders who may help maintain it if they have access
[21:11] <flacoste> lifeless: any reasons that we kept "or '~lazr-developers'." on that page?
[21:12] <lifeless> flacoste: wanted it to be consistent with current ownerships
[21:12] <lifeless> flacoste: no deeper reason
[21:12] <flacoste> ok, i'd prefer if we don't extend the set of things owner by that team though
[21:12] <lifeless> flacoste: happy for us to remove if
[21:12] <lifeless> editing now
[21:12] <flacoste> thx
[21:13] <flacoste> bac: so the recipe could be owned by ~canonical-launchpad-branches also then
[21:13] <flacoste> and i would put this in a ppa on the launchpad team
[21:13] <bac> flacoste: ok, i'll do that
[21:13] <flacoste> bac: thanks!
[21:14] <bac> lifeless: can you expand your thought on, ahem, leveraging the ubuntu packaging?  are you saying we don't need the packaging branch i created?
[21:14] <lifeless> should be able to use the nest command to grab just the debian dir directly from ubuntu
[21:15] <lifeless> you may need a packaging branch if we need to diverge
[21:15] <bac> lifeless: but i'd like for us to be able to update the changelog, thus the branch
[21:15] <lifeless> hmm, just realised. ~canonical-launchpad-branches may be an issue because of the insane notifications we do. Do we notify recipe owners always?
[21:15] <lifeless> If so, then ~launchpad will be needed, even if its conceptually wrong.
[21:16] <lifeless> bac: auto build recipes don't bother with that
[21:16] <lifeless> bac: that said, it is up to you, I don't have a strong recommendation.
[21:16] <bac> lifeless: they do get the debupstream version from the changelog
[21:17] <lifeless> yes, but every build starts fresh from the branches
[21:18] <lifeless> bac: ah, I think you mean 'I want the package major version to match our releases, not the latest version in Ubuntu'
[21:18] <bac> lifeless: yes, for the PPA
[21:18] <lifeless> bac:  you can do that three ways = custom packaging branch; just set it in the recipe rather than using debupstream; make sure we release into Ubuntu very quickly.
[21:18] <lifeless> bac: the easiest is just to set it in the recipe instead of using debupstream
[21:18] <bac> lifeless: as seen here: https://launchpad.net/~bac/+archive/ppa
[21:23] <poolie> hi all
[21:24] <benji> anyone fancy a quick review? https://code.launchpad.net/~benji/launchpad/bug-894177-2/+merge/84676
[21:26] <poolie> o/ benji
[21:26] <benji> poolie: thanks
[21:27] <poolie> It looks plausible to me but you probably want another review from someone more experienced.
[21:29] <benji> poolie: thanks
[21:49] <lifeless> benji: there is a context manager for switching db user
[21:49] <lifeless> benji: it might be nicer
[21:50] <benji> lifeless: ooh, indeed it would; thanks
[21:51] <benji> bac: absolutely, I'm now a card-carying QA instructionist
[21:51] <lifeless> heh, 3 reviews :P
[21:51]  * benji looses 10 cross-channel discussion points.
[21:52] <lifeless> I missed that bac had
[21:52] <bac> lifeless: sorry, i failed to claim it.
[21:52] <benji> lifeless: I now feel very good about my MP, thanks ;)
[21:52] <lifeless> bac: no worries
[21:52] <bac> lifeless: but it's good as you added the cm bit
[21:53] <bac> teamwork
[21:53] <bac> redundancy
[22:02] <cjwatson> Hmm.  My stripped-down version of lp:~cjwatson/launchpad/refactor-cron-germinate noddy-benchmarks at about twice the speed of the current implementation, for identical output; but I think I've got something wrong that means that it isn't extracting all the benefit it could
[22:03]  * cjwatson wasn't expecting that
[22:03] <lifeless> cjwatson: nice