[00:05] <mars> thumper (and sinzui), but 664220
[00:05] <mars> bug 664220
[00:05] <_mup_> Bug #664220: Person search is broken on edge <Launchpad Registry:New> <https://launchpad.net/bugs/664220>
[00:26] <lifeless> mars: bug 664220
[00:26] <_mup_> Bug #664220: Person search is broken on edge <Launchpad Registry:New> <https://launchpad.net/bugs/664220>
[00:26] <lifeless> bah
[00:26] <lifeless> mars: bug 664220
[00:26] <_mup_> Bug #664220: Person search is broken on edge <Launchpad Registry:New> <https://launchpad.net/bugs/664220>
[00:26] <lifeless> bah.
[00:26] <lifeless> I've duped it anyhow
[00:28] <mars> lifeless, thanks.  dupe search did not turn up that bug
[00:28] <mars> neither did google
[00:28] <lifeless> mars: bugs.lp.net/launchpad-project/+bugs?field.tag=timeout
[00:28] <lifeless> I always hit that up and eyeball these days
[00:54] <LPCIBot> Project devel build (138): STILL FAILING in 3 hr 31 min: https://hudson.wedontsleep.org/job/devel/138/
[00:54] <LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][ui=none][bug=347218] Allow bug supervisor to set
[00:54] <LPCIBot> official_bug_tags for a distribution.
[00:54] <LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][ui=none][no-qa] Fix multiline glob imports in doctests.
[00:54] <LPCIBot> * Launchpad Patch Queue Manager: [r=mars][ui=none][bug=648476] Adds the "Add member" link to the block
[00:54] <LPCIBot> that displays in the member listing when there are no members;
[00:54] <LPCIBot> team owners should still have access to this link, regardless of
[00:54] <LPCIBot> membership status.
[00:54] <LPCIBot> * Launchpad Patch Queue Manager: [r=abentley][ui=none][no-qa] Fix bin/kill-test-services to work
[00:54] <LPCIBot> properly again
[00:54] <LPCIBot> * Launchpad Patch Queue Manager: [r=sinzui][ui=none][bug=655802] Fixed timeout when AJAX picker
[00:54] <LPCIBot> searched person or team vocabularies.
[00:54] <LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][ui=sinzui,
[00:54] <LPCIBot> salgado][bug=652232] Move links into sidebar on code.lp.net/$person
[00:54] <LPCIBot> page.
[01:02] <wallyworld> rockstar: ping - quick question
[01:02] <rockstar> wallyworld, whazzup?
[01:03] <rockstar> Oh balls.  Just realized it's time for the AsiaPac reviewer's meeting.
[01:03] <wallyworld> the registrant attribute on IBranchMergeQueue.....
[01:03] <wallyworld> says "The user that registered the branch"
[01:03] <wallyworld> that isn't correct is it?
[01:04] <rockstar> wallyworld, no, it's not.  I apparently can't always finish my thoughts.
[01:04] <wallyworld> looks like a cut'n'paste :-)
[01:05] <wallyworld> btw, i thought the reviewers' meeting time had changed?
[01:10] <lifeless> bdmurray: https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html
[01:10] <bdmurray> lifeless: so, it really is okay just incomplete rather
[01:11] <bdmurray> lifeless: it only allows it for a project and I've another branch that allows it for a distribution
[01:13] <lifeless> bdmurray: please mark it as qa-ok then
[01:13] <lifeless> cause its blocking deployments
[01:15] <lifeless> we need to iterate on our toolchain to allow more precision
[01:23] <LPCIBot> Project db-devel build (88): STILL FAILING in 3 hr 35 min: https://hudson.wedontsleep.org/job/db-devel/88/
[01:23] <LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 11748,
[01:23] <LPCIBot> 11749, 11750, 11751, 11752, 11753, 11754, 11755, 11756, 11757,
[01:23] <LPCIBot> 11758, 11759, 11760, 11761 included.
[01:23] <lifeless> oh hai.
[01:30] <rockstar> Dammit PQM...
[01:47] <thumper> rockstar: whazzup?
[01:47] <lifeless> rockstar: thats more buildbot :)
[01:48] <rockstar> thumper, All lines of log output:"[['Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist. ']]"
[01:48] <thumper> :(
[01:48] <rockstar> lifeless, ^^ That error is not buildbot...
[01:49] <lifeless> rockstar: the irc message is hudson
[01:49] <lifeless> the size of the change is buildbot
[01:49] <rockstar> lifeless, yeah, I can /ignore LPCIBot.  :)
[01:49] <lifeless> the failure root cause is probably the subunit bug I linked here this morning
[01:49] <lifeless> that it doesn't support filtering the bogus errors from zope.testing
[01:51] <rockstar> So this is great.  I submitted two pipes of a pipeline to pqm.  pqm pukes on the first one, but seems to gobble up the second one.  All the changes are landed, but now the bug the first pipe was linked to isn't going to find the QA-bot.
[01:52] <StevenK> Awww
[01:52] <StevenK> rockstar: This is why I feed branches at PQM piece-meal
[01:53] <lifeless> rockstar: by pukes
[01:53] <lifeless> rockstar: do you mean 'we were in testfix' ?
[01:53] <lifeless> rockstar: if you used --fixes lp:xxx, then the qabot should hopefully find it anyway.
[01:53] <rockstar> lifeless, no, see my message to thumper above.
[01:53] <lifeless> oh, I see
[01:53] <lifeless> so codehosting was down
[01:54] <rockstar> StevenK, I did feed them piece-meal, in that I sent them both separately.
[01:54] <lifeless> spm: would like to know if we have a log of what went on for rockstar above
[01:54] <rockstar> lifeless, yeah, it's not necessarily pqm's fault, but this camel is really tired of straw...
[01:54] <spm> hm?
[01:54] <StevenK> rockstar: Sorry, what I mean is submit ; wait for the e-mail until it says sucess and then submit the next one
[01:54] <lifeless> rockstar: would tarmac handle that any better?
[01:55] <rockstar> lifeless, not really "better" per se.  It won't merge the branch if the dependent branch hasn't been merged yet.
[01:55] <lifeless> (not that its pqm vs tarmac, this is all about operational polish)
[01:55] <lifeless> rockstar: thats intersting for me, because I often want to land all the branches at once.
[01:56] <lifeless> rockstar: is there a knob for controlling htat
[01:56] <rockstar> lifeless, no, there isn't.
[01:56] <lifeless> spm: 13:48 < rockstar> thumper, All lines of log output:"[['Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist. ']]"
[01:56] <lifeless> spm: usually means ssh handshaking didn't.
[01:56] <spm> mmm
[01:56] <lifeless> indeed
[01:56] <rockstar> lifeless, I'm sure we can, but I think we can probably teach launchpad to have a better knob for controlling it.
[01:57]  * rockstar quits for the night instead of getting his grump on
[01:58] <lifeless> gnight
[02:02] <lifeless> hmm, need the fire on I think.
[02:02] <lifeless> brb
[02:15] <wgrant> Shouldn't a UI designer be doing UI reviews?
[02:18] <wgrant> There was a proposal that we would be able to forward things to the design team.
[02:18] <wgrant> But that never happened.
[02:18] <wgrant> And it doesn't help overall UI consistency.
[02:18] <wgrant> Which Launchpad is sort of completely lacking.
[02:26] <lifeless> its not completely lacking
[02:26] <lifeless> I think thats a bit harsh
[02:27] <wgrant> True, it is better than it used to be.
[02:48] <wallyworld> thumper: you around?
[02:48] <thumper> yep
[02:49] <wallyworld> wanna have that skype call?
[02:51] <wallyworld> thumper: ^^^^^ - i also had a question about that +branch bug
[02:51] <thumper> wallyworld: sure
[02:52] <thumper> wallyworld: skype doesn't like me
[02:52] <wallyworld> thumper:  so it's not the only one then?
[02:54]  * lifeless hates on doctests some more
[02:54] <thumper> I can hear you
[02:54] <wallyworld> thumper: can you hear me?
[02:55] <lifeless> ok
[02:55] <lifeless> this is weird
[02:55] <lifeless> ah no, its not. Its subunit
[02:55] <lifeless> jml: I think we're going to have to change the zope behaviour here.
[02:55] <lifeless> jml: unless you want to filter in the ec2land code
[02:59] <lifeless> mwhudson: hey
[02:59] <mwhudson> lifeless: hello
[02:59] <lifeless> my uniqueconfig branch bounced
[03:00] <lifeless> I have a fix but its arguable
[03:00] <mwhudson> gar, lp-service just did too :(
[03:00] <lifeless> I want to see if you'd care
[03:00] <mwhudson> ffs
[03:00] <mwhudson> lifeless: link me up
[03:00] <lifeless> lp:~lifeless/launchpad/uniqueconfig 11748
[03:00] <lifeless> mwhudson: this isn't the thread thing
[03:00] <mwhudson> ah ok
[03:00] <lifeless> I'm going to have a poke at that now
[03:01]  * mwhudson looks
[03:02] <lifeless> the error was testrunner_12345
[03:02] <lifeless> instead of testrunner
[03:04] <mwhudson> lifeless: it's not very nice, but i think it's good enoguh
[03:04] <lifeless> thanks
[03:04] <lifeless> Spelling it out long ways was incomprehensible
[03:05] <lifeless> not to mention redundant
[03:16] <lifeless> mwhudson: ok, threading thing upcoming
[03:19] <lifeless> mwhudson: https://code.edge.launchpad.net/~lifeless/launchpad/threads/+merge/39009
[03:23] <mwhudson> lifeless: oh, before i do the second clicky, did you make a branch of zope.testing for this based on lp:~mars/zope.testing/3.9.4-p1 ?
[03:23] <lifeless> no
[03:23] <lifeless> we don't want this upstream
[03:23] <lifeless> so that would be pointless
[03:23] <mwhudson> well, it might make life ever so slightly easier if someone wants to make a 3.9.4-p3 version for whatever reason
[03:24] <lifeless> tar xzf ...
[03:24] <lifeless> (no really)
[03:24] <lifeless> I'll probably get tag filtering done on the flight
[03:24] <lifeless> and we can back this out then
[03:25] <mwhudson> that makes it a bit harder for the next hacker to use version control
[03:25] <mwhudson> i've done stuff like that and then been freaked out when bzr diff didn't work :)
[03:26] <lifeless> the thing is that this is already out of vc
[03:26] <lifeless> if we were using branchs ala config-manager
[03:26] <lifeless> I'd totally agree
[03:26] <lifeless> if you like I can do it
[03:26] <lifeless> it just seems odd
[03:26] <lifeless> particularly for a short term (hopefully) hack
[03:27] <mwhudson> i would rather you did, but don't want to make too big a fuss
[03:27] <lifeless> compromise
[03:27] <mwhudson> and you know the thing about short term hacks... (although i agree in this case it probably will be)
[03:27] <lifeless> if after uds I haven't done the real deal
[03:27] <lifeless> I'll do it
[03:27] <mwhudson> k
[03:28] <wgrant> mwhudson: lucilleconfig was added as a temporary hack until the schema was sorted out.
[03:28] <wgrant> 6 years and a few days ago.
[03:28] <wgrant> It is still there.
[03:28] <lifeless> wgrant: NOT HELPING
[03:28] <mwhudson> lifeless: approved
[03:28] <wgrant> NO TEMPORARY HACKS.
[03:28] <lifeless> mwhudson: thanks
[03:28] <lifeless> mwhudson: now, should I ec2land it :P
[03:28] <mwhudson> eh
[03:28] <mwhudson> probably i guess
[03:28] <lifeless> yeah, I was trolling
[04:11] <jam> mwhudson: it seems windmill still doesn't like me
[04:11] <mwhudson> jam: yeah, i gave up and just lp-landed it
[04:11] <jam> r
[04:24] <jam> mwhudson: thank you
[04:25] <lifeless> I ♥ addDetail
[04:25] <jam> lifeless: you ♥ unicode, too, I see
[04:27] <jtv> lifeless: damn, how do I type that?
[04:27]  * jtv gotta have
[04:32] <LPCIBot> Project devel build (139): STILL FAILING in 3 hr 38 min: https://hudson.wedontsleep.org/job/devel/139/
[04:32] <LPCIBot> * Launchpad Patch Queue Manager: [r=edwin-grubbs][ui=salgado,
[04:32] <LPCIBot> sinzui][bug=652156] Updates the projectgroup branches page to show a
[04:32] <LPCIBot> message consistent with the other codehosting_usage messages
[04:32] <LPCIBot> when there are no branches, instead of an empty table.
[04:32] <LPCIBot> * Launchpad Patch Queue Manager: [r=jtv][ui=none][bug=659050,
[04:32] <LPCIBot> 663075] Only load the link bug and subscription ++form++ when the
[04:32] <LPCIBot> user is logged in.
[04:32] <LPCIBot> * Launchpad Patch Queue Manager: [r=mwhudson][ui=none][bug=624009] Only send the initial review email
[04:32] <LPCIBot> when the merge proposal needs review.
[05:24] <lifeless> statik: oh hai :)
[05:35] <lifeless> \o/
[05:35] <lifeless> \o/
[05:35] <lifeless> \o/
[05:35] <lifeless> \o/
[05:35] <lifeless> \o/
[05:35] <lifeless> \o/
[05:35] <lifeless> A
[05:36] <wgrant> Oh?
[05:36] <wgrant> That bad?
[05:37] <lifeless> that good
[05:37] <lifeless> totally ephemeral librarian
[05:37] <wgrant> Nice!
[05:37] <wgrant> It even finds its own ports to lurk on?
[05:38] <lifeless> yes
[05:38] <lifeless> and root dir
[05:39] <lifeless> it also shows pretty clearly that we have a leak on the librarian :)
[05:39] <lifeless> not in, of
[05:39] <lifeless> lp:~lifeless/launchpad/librarian if you're interested
[05:52] <lifeless> thumper: trade you reviews?
[06:09] <LPCIBot> Project db-devel build (89): STILL FAILING in 3 hr 58 min: https://hudson.wedontsleep.org/job/db-devel/89/
[06:11] <thumper> lifeless: I'm done for today...
[08:02] <LPCIBot> Project devel build (140): STILL FAILING in 3 hr 29 min: https://hudson.wedontsleep.org/job/devel/140/
[08:02] <LPCIBot> * Launchpad Patch Queue Manager: [r=mwhudson][ui=none][bug=660264] Implement LaunchpadForkingService to speed up bzr+ssh connection times.
[08:02] <LPCIBot> * Launchpad Patch Queue Manager: [r=edwin-grubbs][ui=none][bug=663828] Split ReadyService into its own file for easier maintenance of TacTestSetup.
[08:46] <adeuring> good moring
[09:15] <mrevell> Hello
[09:32] <jml> lifeless: the ec2 land code is complex enough already... and I've seen that you've changed testrunner, so it's all good
[09:41] <wgrant> bigjools: How long has p-dr been broken?
[09:42] <wgrant> It should have died within a day of the Intrepid purge, if that was it.
[09:42] <wgrant> And I can't think what else it could have been.
[09:42] <wgrant> :/
[09:43] <LPCIBot> Project db-devel build (90): STILL FAILING in 3 hr 33 min: https://hudson.wedontsleep.org/job/db-devel/90/
[09:43] <LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 11762,
[09:43] <LPCIBot> 11763, 11764 included.
[09:56] <bigjools> wgrant: I don't know.  A Long Time.
[10:01] <wgrant> Ah, good.
[10:49] <bigjools> wgrant: can you remember if there was another bug that left buildds idle?
[10:49] <bigjools> not the aborted/aborting one that I fixed
[10:49] <bigjools> artigas/hooker are not happy
[10:49] <wgrant> bigjools: What's their status?
[10:49] <bigjools> idle
[10:50] <wgrant> The slave too?
[10:50] <bigjools> lots of these in their logs:
[10:50] <bigjools> 2010/10/21 10:19 +0100 [HTTPChannel,202,91.189.90.177] 91.189.90.177 - - [21/Oct/2010:09:19:53 +0000] "POST /rpc HTTP/1.0" 200 222 "-" "xmlrpclib.py/1.0.1 (by www.pythonware.com)"
[10:50] <wgrant> artigas is sparc, hooker ia64, right?
[10:50] <bigjools> yarp
[10:50] <jml> bigjools: that just means "Successful XMLRPC request"
[10:50] <bigjools> quite
[10:50] <wgrant> bigjools: Calling the status() method says BuilderStatus.IDLE?
[10:51] <bigjools> who knows, that's not something that's easy to find out
[10:51] <jml> bigjools: fwiw, it wouldn't be too hard to get the actual methods called in the log.
[10:51] <bigjools> we restarted the buildds and they're still idle
[10:51] <wgrant> bigjools: There are no errors in the log about the directory already existing?
[10:52] <wgrant> And it's not the b-m thing where it ignores new builders until it's restarted?
[10:52] <bigjools> nope
[10:53] <wgrant> Well, I'd be hijacking cesium for a quick python -c "import xmlrpclib; xmlrpclib.ServerProxy('http://artigas.buildd:8221/rpc').status()"
[10:56] <bigjools> yeah I might do that
[10:59] <bigjools> wgrant: it's IDLE
[11:00] <bigjools> as expected
[11:00] <wgrant> bigjools: What does b-m say about it?
[11:00] <bigjools> zip
[11:00] <wgrant> I'm suspecting the usual b-m bug.
[11:00] <wgrant> Except that these builders aren't new.
[11:00] <bigjools> I'm not sure that is a bug
[11:01] <lifeless> win 67
[11:01] <jpds> lifeless: £ or $ ?
[11:01] <wgrant> bigjools: Isn't it?
[11:02] <bigjools> wgrant: I had another instance yesterday of the b-m throwing lots of connection errors, but no builder had been added, so my original assessment was probably wrong
[11:02] <bigjools> this is something different again
[11:03] <wgrant> Yay
[11:03] <wgrant> Maybe it will mysteriously vanish with builderslave-resume.
[11:04] <bigjools> best branch name evar
[11:05]  * bigjools considers renaming it to buildd-manager-apocalypse
[11:05] <bigjools> jml: how can we get the methods in the log, BTW?
[11:06] <jml> bigjools: off the top of my head, I don't know. it's a matter of finding out what does the dispatch to xmlrpc_FOO and whacking a log in there.
[11:06] <jml> or just putting log statements in the actual xmlrpc_FOO methods
[11:07] <bigjools> yeah that was what I would do, I thought you had a "clever" way :)
[11:16] <jml> one of these days I'll write a decorator that logs function calls and return values
[11:22] <wgrant> I don't understand why people like the GitHub "Fork" thing... it makes no sense :/
[11:23] <jml> it makes a little bit of sense
[11:23] <jml> I wish Launchpad had server-side branching
[11:23] <wgrant> Why?
[11:23] <StevenK> Because it's a shedload quicker for Launchpad to branch Launchpad than it is for you too
[11:24] <jml> StevenK: well, that's only true if you don't ever intend to work on your branch
[11:25] <jml> although "branch to local" then "push to LP" is probably slower than "branch on server", "branch to local"
[11:25] <wgrant> Modulo bzr bugs it shouldn't be significantly slower.
[11:25] <jml> wgrant: sometimes it's more a way of thinking than anything else, I guess.
[11:25] <wgrant> (I know that in practice it is)
[11:27] <jml> you know, I'm not grateful enough for the fact that I'm not an IP lawyer
[11:27] <wgrant> jml: The Apple thing?
[11:28] <jml> wgrant: well, that's the trigger, but it's also every damn thing about IP law
[11:28] <wgrant> Heh, yes.
[11:28] <wgrant> It is messy stuff.
[11:28] <jml> I just want to make stuff, pay artists for stuff I like and get to use the stuff I buy.
[11:29] <wgrant> And not have Apple steal your product names? :)
[11:29] <lifeless> jml: any word from legal?
[11:30] <jml> lifeless: no, none yet.
[11:32] <LPCIBot> Project devel build (141): STILL FAILING in 3 hr 30 min: https://hudson.wedontsleep.org/job/devel/141/
[11:32] <LPCIBot> Launchpad Patch Queue Manager: [r=abentley][ui=none][bug=114766] Restrict the ability to nominate
[11:32] <LPCIBot> bugs for a release to bug supervisors, owners or drivers.
[11:33] <wgrant> :(
[11:33]  * StevenK notes that hudson has gotten quicker
[11:35] <jml> StevenK: oh is the time in the IRC message the time for the build?
[11:37] <wgrant> It took me a couple of days to work that out.
[11:38] <lifeless> jml: you have mail. I'd appreciate you taking the time to read it thoughtfully ;)
[11:38] <lifeless> jml: you'll understand why I specifically mention this when you see its size!
[11:38] <jml> lifeless: ok :)
[11:40] <lifeless> jml: I think we should filter in ec2test, but I'll do prep to make it easy, in subunit.
[11:41] <jml> lifeless: well, lib/devscripts/ec2test/remote.py is the relevant place.
[11:42] <jml> lifeless: also, importantly, lib/devscripts/ec2test/tests/test_remote.py
[11:53] <lifeless> I need an incremental eyeball
[11:53] <lifeless> rev 11773 of lp:~lifeless/launchpad/threads
[11:54] <jml> lifeless: ok.
[11:55] <lifeless> this should, finally, fix the test environment headaches
[11:55] <lifeless> with threads
[11:55] <jml> anything to distract me from email
[11:55] <jml> +            new_threads = new_live_threads()
[11:56] <jml> lifeless: that's the only interesting change in that revision
[11:56] <lifeless> thats it
[11:56] <lifeless> if you look at the commit message, or the context, it should make more sense
[11:56] <jml> lifeless: well, that's a perfectly syntactically formed line of Python :)
[11:56] <lifeless> thank you
[11:56] <jml> lifeless: fetching the branch now to get context
[11:57] <lifeless> I spent hours on it
[11:57] <lifeless> jml: loggerhead can show that ;)
[11:57] <jml> lifeless: loggerhead is too slow.
[11:57] <lifeless> hah, ouch,
[11:57] <wgrant> Loggerhead still times out for me on the first request for any LP branch.
[11:57] <wgrant> But apart from that it's not too slow.
[11:59] <jml> wgrant: it's not significantly faster than me fetching the branch and using my editor.
[11:59] <jml> wgrant: especially given the way it always times out on the first request for any LP branch
[11:59] <jml> lifeless: +1
[11:59] <deryck> Morning, all.
[12:00] <wgrant> jml: Ah, I guess it's different since you live next to the DC.
[12:00] <StevenK> jml: Yes, 'in 3 hours 3 minutes' is how long it took
[12:01] <lifeless> jml: I've thrown it straight at PQM
[12:01] <jml> StevenK: I read it as "will still be failing in 3 hours 3 minutes"
[12:01] <StevenK> jml: Patches welcome
[12:01] <lifeless> jml: if it doesn't get through you probably want to resubmit it yourself: '[r=mwhudson][ui=none][bug=663644][no-qa] Switch to a patched zope.testing that does not emit subunit errors on leaked threads, for windmill test sanity.'
[12:02] <StevenK> \o/ \o/
[12:02] <lifeless> (I think we may be in testfix)
[12:02] <StevenK> lifeless: Was the patch to zope.testing horrible?
[12:02] <lifeless> no its tiny
[12:02] <lifeless> we'll get a longer term fix later
[12:03] <lifeless> hmm, shoving testfix on that
[12:03] <jml> lifeless: would you like to borrow some of my apostrophes?
[12:03] <lifeless> because it does, thought a different one.
[12:03] <lifeless> jml: prhaps
[12:05] <lifeless> jml: you're turning into mpt
[12:05] <lifeless> (not a bad thing)
[12:05] <jml> lifeless: my penmanship is vastly inferior.
[12:06] <lifeless> but your list of ways to improve things are equivalent
[12:06] <bigjools> given enough pens and enough jmls, the penmanship could be magnificent
[12:06] <lifeless> or the universe may end
[12:07] <bigjools> think of all the hair
[12:07] <lifeless> StevenK: whats the thread topic you started about threading errors in hudson ?
[12:07]  * bigjools goes back to fixing p-d-r
[12:07] <lifeless> found it I think
[12:08] <StevenK> lifeless: Failures on Hudson
[12:08] <wgrant> bigjools: Which files are screwed?
[12:08] <bigjools> querying that as you type
[12:08] <wgrant> Ah, so that kind of fixing.
[12:09] <bigjools> I'm not sure what could have caused this
[12:09] <wgrant> The Intrepid purge could easily have, if the timing was just right...
[12:09] <bigjools> other than over-zealous librarian file collection
[12:09] <wgrant> But that seemed unlikely.
[12:10] <bigjools> we probably marked something expired when it should not have been
[12:10]  * bigjools would love reference counts on LFAs
[12:10] <wgrant> 01:17 <wgrant> So, this query isn't perfect. It violates the PPA blacklists and stay of execution. But that should all be long-dead for intrepid.
[12:10] <bigjools> hmm
[12:15] <bigjools> wgrant: they are all gutsy files
[12:16] <wgrant> bigjools: What's datesuperseded/dateremoved?
[12:17] <wgrant> Sources or binaries?
[12:17] <bigjools> only checkiungbinaries
[12:17] <bigjools> sigh
[12:17] <bigjools> only checking binaries
[12:17] <wgrant> Er, yes, of course.
[12:18] <bigjools> all 90 are superseded at the same time: 2010-05-28 14:12:50.17775
[12:20] <wgrant> Not Deleted?
[12:20] <bigjools> so if I update these to all have dateremoved set then it should fix p-d-r
[12:20] <lifeless> bigjools: LFAs are not really intended to be shared with other objects
[12:20] <lifeless> bigjools: does soyuz share them ?
[12:20] <wgrant> But it would also leave cruft all over the disk.
[12:20] <bigjools> lifeless: it shares them across publications
[12:20] <lifeless> (LFAs are the reference counts for content objects)
[12:21] <lifeless> gnight
[12:21] <bigjools> wgrant: point
[12:21] <bigjools> nn lifeless
[12:22] <bigjools> it's only 90, I can collect filenames and do it manually
[12:22] <wgrant> bigjools: What's the expiry date on the LFA?
[12:23] <bigjools> 2010-01-07
[12:23] <bigjools> !
[12:23] <wgrant> ... pardon?
[12:23]  * bigjools scratches  head
[12:23] <wgrant> Is datepublished set?
[12:24] <bigjools> yes
[12:24] <wgrant> :(
[12:24] <bigjools> I suspect we set expires back a long way to force GC action
[12:25] <wgrant> Hmm.
[12:25] <bigjools> that date is close to our sprint in NZ
[12:25] <wgrant> It is, yes.
[12:25] <wgrant> And I found a bug in that query soon after.
[12:26] <wgrant> So it's fine. Delete them manually.
[12:27] <wgrant> (the January query included in the EXCEPT clause only those binaries outside (feisty, gutsy), ignoring the possibility that (feisty, gutsy) pubs could still be alive outside the primary archive)
[12:28] <bigjools> yeah
[12:28] <bigjools> people backporting no doubt
[12:28] <bigjools> I wonder if we could do what  lifeless suggests
[12:28] <bigjools> would make life easier
[12:28] <wgrant> Not easily.
[12:28] <wgrant> Without redesigning most of the data model in unobvious ways.
[12:29] <wgrant> (that date does match: the paste of the query is from the 2010/01/14, and it backdated expiry by a week)
[12:29] <bigjools> well if it gives us gains elsewhere it's worth it
[12:29] <wgrant> By "unobvious" I mean that it's not obviously possibly at all.
[12:30] <bigjools> it's always possible
[12:30] <wgrant> Not without making everything even uglier.
[12:30] <bigjools> so pessimistic already at such a tender age ...
[12:30] <wgrant> Shh.
[12:30] <bigjools> :)
[12:31] <bigjools> it took me years to get this jaded
[12:37] <wgrant> Maybe we should expire Jaunty without backdating before it gets OMGCRITICAL, since I managed to find a bug in the query the day after both in January and this time...
[12:38] <wgrant> But 'twas too late :(
[12:40] <bigjools> yeah
[14:20] <jml> bigjools: do we know how many people have uploaded to a PPA?
[14:20] <jml> bigjools: also, do we know how many of them are Ubuntu devs?
[14:20] <bigjools> jml: I'm sure that info can be mined
[14:21] <jml> bigjools: I guess I don't know how to find "uploader" in the databes
[14:21] <jml> database
[14:21] <bigjools> jml: packageupload.signing_key
[14:22] <jml> bigjools: ta
[14:22] <bigjools> jml: you know how to write the query?
[14:22] <jml> bigjools: not yet, but I'll figure it out soon enough, I think.
[14:25] <bigjools> jml: ok - you need to join to spph and its archive and make sure purpose=2
[14:26] <jml> bigjools: ahh of course, to rule out uploads to non-ppa
[14:26] <wgrant> Or just go straight from the PU to the archive.
[14:26] <bigjools> no
[14:26] <bigjools> well - depends what he wants
[14:26] <bigjools> do you need copies to PPAs too?
[14:26] <wgrant> PU->archive gets uploads to PPAs, while skipping copies from primary to PPAs.
[14:27] <bigjools> "Launchpad. A home for your apps."
[14:27] <jml> uploads are fine for this, I reckon.
[14:27] <bigjools> nice
[14:27] <wgrant> bigjools: Yes :(
[14:28] <wgrant> Someone didn't even bother Googling, apparently...
[14:28]  * bigjools wonders if Launchpad is a TM in the USA
[14:33] <jml> I've got ~4k people as having uploaded to a PPA. Does that sound right?
[14:34] <jml> http://paste.ubuntu.com/517436/
[14:37] <wgrant> Looks good to me.
[14:37] <bigjools> jml: seems reasonablew
[14:37] <jml> ta.
[14:42] <wgrant> Is there some trick to getting Skype from Partner to not hang when signing in?
[14:44] <jml> wgrant: don't know. I have no idea where my skype comes from, tbh.
[14:53] <jml> sinzui: you'll let me know when the bridging-the-gap registry work is ready for review, right?
[14:53] <sinzui> yes
[14:53] <sinzui> I still do not see the last branches landed :(
[14:54] <jml> sinzui: cool.
[14:56] <gmb> Can anyone remind me how to trigger run an action in a view from a unit test? I'm tying myself in knots here.
[14:59] <jml> gmb: "run an action"?
[15:01] <gmb> jml: Not sure what the right language is here. I have an initialized view. I pass it form data with a LaunchpadTestRequest... how do I get its "continue" action to be called? Or do I have to call it directly and pass data into it (which seems odd)?
[15:06] <jml> gmb: I don't know. In the past I've done direct calls. Maybe looking at the view base classes might give you a clue as to what to do?
[15:06]  * jml is now otp
[15:06] <salgado> gmb, doc/launchpadformharness.txt
[15:07] <gmb> salgado: Thanks!
[15:33] <gmb> mars: ping
[15:33]  * bigjools back in 30m
[16:15] <gmb> mars: Around?
[16:56] <LPCIBot> Yippie, build fixed!
[16:56] <LPCIBot> Project devel build (142): FIXED in 4 hr 1 min: https://hudson.wedontsleep.org/job/devel/142/
[16:56] <wgrant> !!!!!
[17:00] <bigjools> lol
[17:00] <bigjools> wgrant: errr it's 3am there!
[17:01] <wgrant> Yeah, but we need to deliver our final project to the client in a couple of days.
[17:01] <wgrant> Normal sleeping patterns do not apply.
[17:13] <bigjools> sinzui: do you think that lp/registry/interfaces/distroseriesdifference.py should be in lp/soyuz ?  I think it's something that can only exist with Soyuz enabled on a distro.
[17:14] <sinzui>  bigjools yes, and I think we should look at distroseries in general and ask if other aspects are soyuz
[17:14]  * sinzui was thinking of moving pocket next month
[17:15] <bigjools> sinzui: yes, I want to eventually rip loads of stuff out of distroseries
[17:16] <sinzui> bigjools, I want to add and is_lts flag to distroseries. I do not think derivatives care, but there may be some rule I do not know about
[17:17] <sinzui> bigjools, I also think it is time to ask if version is really required. Debian's experimental series will never be released as versions
[17:23] <bigjools> sinzui: derivatives don't currently care, no.  What's it going to be for?
[17:23] <bigjools> not sure we can get rid of version, although I'd like to
[17:24] <sinzui> yes, I think version is required by lots of things
[17:25] <sinzui> We cannot display "Ubuntu 10.04 LTS" in our pages because we cannot put LTS in the version
[17:25] <bigjools> LTS is Ubuntu-specific
[17:25] <sinzui> I think so too
[17:26] <bigjools> why can't you put LTS in the version?
[17:27] <sinzui> I Do not think "10.10 LTS" validates
[17:28] <jelmer> IIRC we try to parse distroseries version strings with the debian version string parser, for sorting purposes.
[17:29] <sinzui> bigjools, it has to pass sane_version validation which is a subset of debversion
[17:29] <bigjools> :(
[17:29] <bigjools> sinzui: is it only sorting that we need that for?
[17:30] <bigjools> is it set in stone that version is a debversion-style string?
[17:30] <jelmer> sinzui: Would a separate string field with a subtitle for a version string perhaps be an option?
[17:31] <sinzui> bigjools, re-reading my comment  DistributionMirror and buildd require it to be a debversion. The db constraint is weaker
[17:31] <sinzui> jelmer, it would if we wanted to support other distros.
[17:32] <jelmer> sinzui: but don't we already do so ? we have debian, gentoo, nexenta, etc registered
[17:33] <sinzui> No
[17:33] <sinzui> We only support ubuntu
[17:34] <jml> actually, while you're talking about this
[17:35] <sinzui> We have lots of registry distros. Only Ubuntu works. Debian kind of works because we have partial publishing history, no other distro works. The do not have packages or mirrors, they cannot have a bug tracker or be translated
[17:35] <jml> https://dev.launchpad.net/RegistrySimplifications
[17:35] <sinzui> I love the spec
[17:36] <jml> although I think it's based on db tables rather than interfaces and so misses little globules of fun like __str__ and named_version
[17:37] <jelmer> sinzui: But isn't the intention that Distribution and DistroSeries are generic and not Ubuntu-specific? None of the existing fields appear to be specific to Ubuntu.
[17:37] <bigjools> I have run out of brain juice for one day.
[17:37] <sinzui> jml: Sure there are anachronisms in the spec, but I think it really is what we need to do. The language we use in the UI really frustrates users
[17:38] <sinzui> jelmer, yes, but the generic interpretation has proven to be useless for most use cases
[17:38] <bigjools> good night everyone
[17:39] <sinzui> jelmer, users cannot use distro object to run a project like Ubuntu. to make a derivative, you need to other objects
[17:40] <jml> bigjools: g'night
[17:40] <sinzui> jelmer, most users want a distroseries to manage packages, and they do not get them. Debian is faulty because you cannot report a bug in a Debian package that is not already in Ubuntu
[17:41] <sinzui> source package names are debian names too. We cannot support Fedora or Gentoo: ack != ack-grep != text/ack
[17:44] <jelmer> sinzui, the distroseries in Debian are used for e.g. packaging branches though. and it would be useful to be able to mark a bug as existing in Debian too, without it existing in Ubuntu.
[17:45] <jelmer> sinzui: I see it's not entirely useful at the moment, but it seems a pity to me to make it more Ubuntu-specific now.
[17:48] <sinzui> jelmer, I am not advocating making distros Ubuntu specific. I am pointing out that as the Launchpad's primary registry admin and answer contact, user are very disappointed. Generic is not good enough for them and no community is will to extend Lp to support their distro
[17:56] <jelmer> sinzui: I don't see how in this particular case a text tag ("LTS") that is more generic versus a is_lts boolean would be less useful for users.
[17:56] <jelmer> sinzui: Anyway, I didn't mean to derail this discussion.
[17:58] <sinzui> jelmer, I think a bool allows pages and tooltip to show what LTS means
[18:26] <lifeless> moin
[18:29] <jml> hi
[18:37] <jelmer> sinzui: Ah, hmm, I hadn't considered that.
[18:41] <lifeless> oh awesome, we got hudson to pass
[18:46] <jml> lifeless: awesome indeed.
[18:46] <jml> g'night all
[18:49] <lifeless> leonardr: ping
[18:49] <leonardr> hi lifeless
[18:49] <lifeless> I have a branch, which appears to break xx-wadl
[18:50] <lifeless> I was wondering if I could forward the failure to you, and we can try to think of what it might be together
[18:50] <leonardr> lifeless, sure
[18:50] <lifeless> its sending now
[18:51] <lifeless> please excuse the slightly crappy layout, I have't updated my submit-to-lp-tree yet
[18:55] <deryck> bryceh, hey, can you mark bug 617699 qa-ok, since as I understand from the standup the qa is done?
[18:55] <_mup_> Bug #617699: Export bug_tracker APIs for upstream components <qa-needstesting> <story-bugzilla-component-link> <Launchpad Bugs:Fix Committed by bryce> <https://launchpad.net/bugs/617699>
[18:56] <deryck> and slide the card across, too, please.
[18:56] <leonardr> lifeless: the error is this "_StringException: <unprintable _StringException object>" thing?
[18:57] <leonardr> what happens when you run that test (or -vvt webservice) locally?
[18:57] <lifeless> leonardr: look at the gz file
[18:57] <lifeless> search for xx-wadl
[18:57] <leonardr> ok
[18:58] <lifeless> its got nonutf8 text or a utf8 reencoded blad of some sort, in the traceback
[18:58] <lifeless>     print webservice.get(
[18:58] <lifeless>         '/', 'application/vd.sun.wadl+xml', api_version='devel').body
[18:58] <lifeless> Differences (ndiff with -expected +actual):
[18:58] <lifeless>     - Some fake WADL.
[18:58] <lifeless>     + <?xml version="1.0"?>
[18:58] <lifeless> ...
[19:01]  * leonardr having difficulty getting the gzip log out of evolution
[19:01] <lifeless> right click save as ?
[19:02] <leonardr> the context button for the attachment is depressing, and then popping back up, without offering me any actions or doing anything
[19:04] <leonardr> ok, taking a look now
[19:06] <lifeless> leonardr: ok, I think I see
[19:06] <lifeless> its a literal 'testrunner' string that I missed.
[19:06] <leonardr> lifeless: are you expecting the huge failures where you get real wadl instead of the string 'some fake wadl'?
[19:07] <lifeless> no, which is why I asked for a hand :)
[19:07] <lifeless> but staring at it with fresh eyes has helped me
[19:07] <lifeless> I presume you wrote this ?
[19:07] <lifeless> if so I'd like to give a little feedback
[19:07] <leonardr> sure
[19:08] <lifeless> literal string values (not keys) should set of alarm bells
[19:08] <lifeless> try and find the object in use instead
[19:08] <lifeless> e.g. http://pastebin.com/7GJFXNAS
[19:09] <leonardr> oh, for testrunner. i thought you meant for 'some fake wadl'
[19:09] <leonardr> sure
[19:09] <leonardr> lifeless: yes, fixing the 'testrunner' problem will solve the failure
[19:10] <leonardr> the fake cached wadl was being written to the wrong place
[19:10] <lifeless> I'll throw it back at ec2
[19:10] <lifeless> hopefully it will go through :)
[19:11]  * leonardr crosses fingers
[19:21] <lifeless> statik: around?
[19:35] <lifeless> Ursinha: so, we're live with RFWTAD
[19:36] <lifeless> Ursinha: how does it feel ?
[19:36] <Ursinha> lifeless, I saw the email
[19:36] <Ursinha> lifeless, we don't have edge, what do we have?
[19:37] <lifeless> in what regard?
[19:38] <lifeless> Ursinha: https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html seems odd
[19:39] <Ursinha> lifeless, yeah, I'm checking that
[19:39] <lifeless> Ursinha: both lpnet and edge are running 11704
[19:39] <lifeless> qastaging is running tip of stable
[19:40] <Ursinha> lifeless, I used to check edge as landed stuff from stable and staging for landed stuff from db-stable
[19:40] <Ursinha> s/as/for/
[19:40] <Ursinha> we don't have edge now, so...
[19:40] <lifeless> use qastaging
[19:41] <Ursinha> lifeless, we have both then
[19:41] <Ursinha> cool
[19:41] <lifeless> we're not pushing to production-stable now either
[19:42] <lifeless> so we can take that config out
[19:42] <lifeless> (I think thats why its showing older revs as a starting point)
[19:43] <Ursinha> lifeless, exactly
[19:44] <lifeless> and we can change the db-stable reference branch from production-stable to stable
[19:44] <Ursinha> lifeless, where can I check for the latest deployed revision then
[19:44] <lifeless> (because we're now going to deploy from stable)
[19:44] <Ursinha> ah, stable
[19:44] <Ursinha> hm, no
[19:44] <Ursinha> from stable
[19:44] <Ursinha> to?
[19:44] <lifeless> lets start over :)
[19:44] <Ursinha> hehe
[19:45] <lifeless> we have updates to do for the db-stable and the stable report
[19:45] <lifeless> lets do stable first
[19:45] <lifeless> candidates to deploy are in the branch .../stable
[19:45] <lifeless> deployed revisions are found by querying lpnet
[19:46] <Ursinha> lpnet, right
[19:46] <lifeless> what we need to do is
[19:47] <lifeless> in get_edge_revision
[19:47] <Ursinha> not querying production-stable branch anymore, but... scraping lpnet page?
[19:47] <lifeless> s/edge/lpnet
[19:47] <lifeless> yes
[19:47] <Ursinha> ah, cool
[19:47] <lifeless> and change edge.launchpad.net -> launchpad.net
[19:47] <Ursinha> lifeless, mind filing a bug for that? I'll get to it then, might be fast
[19:47] <lifeless> what else do we need to change
[19:47] <lifeless> we need to not check the merged branch
[19:48] <lifeless> because we're doing a push deployment
[19:48] <lifeless> mmm, thats it
[19:48] <lifeless> I think ?
[19:48] <Ursinha> I guess so
[19:49] <lifeless> Ursinha: it should be trivial, I have filed a bug for reference purposes
[19:49] <lifeless> https://bugs.edge.launchpad.net/qa-tagger/+bug/664671
[19:49] <_mup_> Bug #664671: deployment of stable has changed <qa-tagger:New> <https://launchpad.net/bugs/664671>
[19:49] <Ursinha> lifeless, perfect
[19:50] <Ursinha> thanks
[20:00] <lifeless> jkakar: hey
[20:00] <jkakar> lifeless: Hi!
[20:00] <lifeless> abentley is having storm pains
[20:01] <lifeless> I wonder if you can spare a few minutes to eyeball some symptoms
[20:01] <jkakar> lifeless: Is it about the bug he posted?
[20:01] <lifeless> possibly
[20:01] <jkakar> lifeless: Anyway, yes, am happy to help but I need 5 minutes.  Will ping in a minute.
[20:01] <jkakar> Or 5. :)
[20:01] <lifeless> last I saw it was on lp-code, I suggested he take it to storm
[20:02] <lifeless> sure thing
[20:03] <lifeless> jkakar: yes, when you return -  https://bugs.edge.launchpad.net/storm/+bug/659316
[20:03] <_mup_> Bug #659316: KeyError in storm from test <Launchpad Bazaar Integration:Triaged> <Storm:New> <https://launchpad.net/bugs/659316>
[20:04] <lifeless> abentley: one thing you might try is the 0.18 of storm
[20:04] <abentley> lifeless: I'll look into that.
[20:05] <lifeless> its either released or just about to be
[20:05] <lifeless> I know that we have a blocking bug which is blocking its release, but if that branch works with that specific test, we can focus on getting 0.18 released and in LP
[20:06] <jkakar> lifeless, abentley: Okay am back... was ordering a new laptop battery to be delivered to the hotel during UDS.  Anyway, 0.18 isn't out yet, gary_poster is working on it, trunk will become 0.18.
[20:07] <jkakar> abentley: Can you reproduce this outside of Launchpad code?
[20:07] <jkakar> I don't have Launchpad code here and don't really want it to eat my hosts/apache/etc. :/
[20:07] <abentley> jkakar: no, this is as simple as I've been able to make it.
[20:07] <lifeless> jkakar: vm's ftw
[20:08] <lifeless> jkakar: https://dev.launchpad.net/Running/VirtualMachine
[20:08] <lifeless> jkakar: I like my hosts file too
[20:09] <abentley> jkakar: so far, it's still using a lot of Launchpad foo like login, logout, and AFAICT, they're required to exercise the problem.
[20:09] <jkakar> abentley: Okay.
[20:10] <abentley> jkakar: I could set up a shared screen session, though I don't remember how ATM.
[20:10] <jkakar> abentley: *That* would be helpful.
[20:10] <jkakar> abentley: That plus Skype might do the trick.
[20:11] <abentley> jkakar: okay, what SSH public key should I use?
[20:11] <jkakar> abentley: The one on Launchpad, please.
[20:15] <abentley> jkakar: you should be able to ssh to abentley@99.245.196.243 now.
[20:15] <jkakar> abentley: It's asking me for your password.
[20:16] <abentley> jkakar: my bad.  Try again?
[20:17] <jkakar> abentley: Am in... stumpy!
[20:17] <jkakar> abentley: Skype?
[20:17] <abentley> jkakar: Yep.  What's your id?
[20:17] <jkakar> abentley: jkakar
[20:30] <benji> bzr uncommit is beautiful
[20:31] <lifeless> thanks :)
[20:31] <lifeless> [on behalf of the whole team, which I'm not in anymore ;P]
[20:32] <benji> :)
[20:57] <jkakar> abentley: https://bugs.edge.launchpad.net/storm/+bug/244769
[20:57] <_mup_> Bug #244769: Reference == Int works to build join condition, but Int == Reference fails <Storm:New> <https://launchpad.net/bugs/244769>
[21:06] <gary_poster> jkakar, lifeless: is this a bug to hold 0.18 on?
[21:06] <gary_poster> or abentley
[21:06] <abentley> gary_poster: I think no.
[21:07] <gary_poster> ok thanks abentley
[21:10] <rockstar> thumper, when you're around, I'd like to chat with you.
[21:10] <thumper> rockstar: ack
[21:10] <thumper> rockstar: I need to talk Maia to school shortly
[21:10] <thumper> she slept in
[21:12] <rockstar> thumper, my experience with Maia is that she talks you to school.
[21:14] <thumper> rockstar: uh ha
[21:14] <thumper> rockstar: we had a school concert last night
[21:14] <thumper> and she didn't get to bed until 10pm
[21:14] <thumper> she woke up about 15 minutes ago, and is just having breakfast
[21:20] <jkakar> abentley: I've logged out, you can remove my SSH key.
[21:20] <abentley> jkakar: cool.
[21:20] <jkakar> lifeless: We didn't find the issue in Storm, but I think I may have enough to build a test case.
[21:20] <jkakar> lifeless: We did find the right place to put a Store.flush call to fix the issue.
[21:22] <lifeless> awesome
[21:24] <jkakar> It's a very strange situation that I *think* I might kinda understand, but we'll see.  There's a lot going on in the code we reviewed to try to understand the issue.
[21:24] <jkakar> Also, folks, if you have Storm issues feel free to ping, you don't have to wait for lifeless to ask me to help you. :)
[21:25] <jkakar> If I can't help you figure out an issue we can at least file a bug and try to generate a test case.  We're friendly on #storm, come talk to us when you run into problems instead of spinning in frustration.
[21:26] <deryck> I need a review.  Anyone game for reviewing a 143 line diff.
[21:34] <thumper> rockstar: back
[21:37] <rockstar> thumper, cool.  Lemme go into the skype room.
[22:09] <wallyworld> morning
[22:10] <rockstar> wallyworld, abentley, thumper, now fer the standup?
[22:11] <wallyworld> rockstar: yep
[22:11] <thumper> ack
[22:13] <wallyworld> thumper: abentley rockstar: my sound dies when i did an upgrade it appears :-(. i'll try and fix
[22:19] <wallyworld> abentley: i'm back
[22:33] <wallyworld> rockstar: i have to do the school drop off this morning, can you ping me after your class?
[22:34] <rockstar> wallyworld, sure.  It'll be in 90-ish minutes.
[22:34] <wallyworld> ok. speak then
[22:34] <rockstar> wallyworld, do you have to do it now.  My skype computer's time was off.
[22:35] <wallyworld> rockstar: ?
[22:35] <rockstar> wallyworld, I have about 10 minutes before I have to go.  I thought I was going to be late.
[22:35] <wallyworld> ok. we can chat now
[22:36] <rockstar> wallyworld, actually, let's talk after.  We shouldn't need to hurry.
[22:36] <wallyworld> rockstar: ack
[22:37] <wallyworld> lifeless: is it just me, or did a change to tachandler yesterday break the library layer startup when running tests?
[22:41] <lifeless> wallyworld: just you, I hope
[22:41] <lifeless> I mean, its possible I naffed it up, but hudson reckoned its ok
[22:42] <wallyworld> lifeless: in TacTestSetup, i had to comment out self._waitForDaemonStartup()
[22:42] <wallyworld> the refactoring, for me, seems to have broken that
[22:43] <lifeless> well thats trivially looking for LOG_MAGIC
[22:43] <wallyworld> yes, and it complains about it somehow - i'd have to check again to see the exact error
[22:44] <lifeless> please
[22:44] <wallyworld> ok. give me a minute
[22:52] <wallyworld> lifeless: wtf, it worked just now. i switched to the relevant bzr branch and re-ran the same tests a yesterday. go figure
[22:53]  * wallyworld duck out to do school dropoff
[23:37] <Ursinha> lifeless, actually it's not just renaming get_edge_revision, because edge was a qa environment
[23:37] <Ursinha> I need to get the qastaging revno instead
[23:38] <Ursinha> and for checking which revision has landed, duplicate that scraping for lpnet instead of checking prod-stable branch
[23:38] <Ursinha> landed in prod, that is
[23:40] <lifeless> Ursinha: so the qastaging revno is the stable tip, more or less
[23:40] <Ursinha> lifeless, yes
[23:40] <lifeless> anyhow, whatever works is fine by me
[23:41] <Ursinha> lifeless, I'll do what I just told you, that should work appropriately
[23:42] <lifeless> cool
[23:45] <lifeless> gmb: can you add your new flag to https://dev.launchpad.net/LEP/FeatureFlags