[01:35] <lifeless> wgrant: see backchannel for poppy discussion
[01:36] <wgrant> I read most of it, but apparently not enough.
[01:38] <wgrant> Does anyone know what's happening with the pofilestatsjob DB permission fixes?
[01:38] <wgrant> I saw a branch for it on like Monday.
[01:38] <wgrant> But it hasn't landed.
[01:38] <wgrant> I'm tempted to just cowboy the two permissions...
[03:30] <james_w> hmm, ec2 land didn't appear to do anything, and I got no mail
[03:30] <james_w> is there any way to find out what happened other than trying again?
[03:31] <wgrant> Sadly not.
[03:32]  * james_w fires it off again
[03:32] <james_w> should I do it with --attached or whatever it is?
[03:33] <wgrant> Possibly. The instance is completely gone?
[03:33] <wgrant> We haven't had disappearing instances for nearly a year....
[03:33] <wgrant> Apart from AWS glitches.
[03:34] <wgrant> You sure it didn't just send to an unobvious email address?
[03:34] <wgrant> It would have failed, because the build to fix them is still pending.
[03:34] <lifeless> wgrant: btw remember the oops ajax thing the other day
[03:35] <wgrant> lifeless: Yes?
[03:35] <lifeless> wgrant: we emit X-Oops-ID now
[03:35] <lifeless> not lazr
[03:35] <wgrant> Ah
[03:35] <wgrant> That would do it.
[03:35]  * wgrant fixes.
[03:35] <wgrant> (although that might break launchpadlib too...)
[03:35] <lifeless> see oops_wsgi
[03:35] <wgrant> lifeless: See SystemErrorView
[03:35] <lifeless> ahem. I should say 'the wsgi stack does x-oops-id'
[03:36] <lifeless> I may not have changed it throughout LP.
[03:36] <wgrant> Hm, although I guess we don't use that for API requests.
[03:36] <lifeless> but we should.
[03:36] <james_w> I don't have any mail from the test run
[03:36] <lifeless> james_w: if it totally blows up that happens
[03:36] <lifeless> james_w: you can exceed the mx size limits
[03:36] <james_w> maybe I've somehow got it configured to an email I no longer have access to
[03:36] <james_w> e.g. @linaro.org
[03:37] <james_w> anyway, I'll try --attached tomorrow and see what happens
[03:37] <james_w> night all
[03:38] <james_w> and thanks wgrant, lifeless
[03:38] <wgrant> james_w: It should have gone to jameswestby.net
[04:08] <lifeless> can has reviewer?
[04:08] <lifeless> https://code.launchpad.net/~lifeless/python-oops-wsgi/timeout/+merge/85056
[04:09] <wgrant> Ugggh
[04:09] <wgrant> Let's not.
[04:09] <wgrant> Can't we solve our current crisis before creating another?
[04:12] <lifeless> data is power
[04:12] <wgrant> Data is hopelessness.
[04:12] <lifeless> the swamp of despair is hopelessness
[04:12] <lifeless> data isn't!
[04:14] <lifeless> wgrant: so does that mean am I getting a review?
[04:18] <wgrant> Sure.
[04:20] <wgrant> lifeless: r=me
[04:23] <lifeless> thanks
[04:28] <wgrant> lifeless: Doesn't gpgfixtures provide better implementations for the stuff that sits *under* GPGHandler?
[04:28] <wgrant> The stuff I've moved does not include any fixtures, and is all code that is either GPGHandler or pokes stuff into the DB through it.
[04:28] <wgrant> Not relating to the underlying keyserver.
[04:29] <wgrant> Unless gpgfixtures covers the LP DB as well, which would be somewhat worrying.
[04:29] <lifeless> wgrant: it changes gpghandler
[04:29] <lifeless> wgrant: and provides test keys too
[04:29] <lifeless> wgrant: gpgverifyd replaces gpghandler
[04:29] <lifeless> more or less
[04:29] <lifeless> I guess I mean 'please check the fallout here, I have nasty WIP'
[04:30] <wgrant> Ah, I thought that didn't exist past a prototype server implementation.
[04:30] <lifeless> I'm on a 4 month yak shave to make that prod
[04:30] <lifeless> currently on the 'and it needs reliable OOPS infrastructure' arc.
[04:30] <wgrant> Right, but I didn't know any LP client code existed for it.
[04:30]  * wgrant hunts.
[04:30] <lifeless> gpgverifyd -> oops -> oops-tools -> pruning -> scriptactivity -> slony-db-migrations
[04:30] <wgrant> Heh
[04:30] <lifeless> wgrant: I'm pretty sure my branches are up on LP
[04:31] <lifeless> wgrant: by heh I hope you mean 'heh that is terrifying'
[04:32] <wgrant> lifeless: Huh
[04:32] <wgrant> Did you just view your usegpgfixtures branch?
[04:32] <lifeless> no
[04:32] <wgrant> Because it didn't time out first time.
[04:32] <lifeless> I did no
[04:32] <wgrant> Hmmm.
[04:32] <wgrant> How did that work, then...
[04:32] <lifeless> existing disk cache
[04:32] <lifeless> and branch tip matches
[04:32] <lifeless> at a guess
[04:32] <wgrant> Doesn't normally help, but perhaps it did here for some reason.
[04:34] <lifeless> ah, found my bug - 708961
[04:34] <wgrant> Bug #708961
[04:34] <_mup_> Bug #708961: loggerhead oops reports are missing diagnostic data <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/708961 >
[04:34] <lifeless> wgrant: https://code.launchpad.net/~lifeless/launchpad/deps/+merge/85005 is the context
[04:35] <wgrant> Ah, not so bad one tiny import conflict in one of the tests.
[04:36] <lifeless> what revno is my lp branch @?
[04:36] <wgrant> usegpgfixtures r13758
[04:36] <lifeless> 13759 locally
[04:36] <lifeless> lets see
[04:37] <lifeless> 'merge up with devel'
[04:37] <wgrant> Heh
[04:37] <lifeless> probably a bunch of conflicts or I wouldn't have bothered
[04:37] <lifeless> pushing it it
[04:37] <wgrant> Odd. Only buildout.cfg/setup.py conflicts here.
[04:37] <lifeless> ENOIDEA
[04:38] <lifeless> its up
[04:38] <wgrant> Thanks.
[04:38] <lifeless> thanks for investigating
[04:39] <wgrant> I'm glad that LP uses four JS frameworks :)
[04:39] <wgrant> YUI3 primarily, YUI2 for calendar widgets, jQuery for the tour, MochiKit for some old translations stuff and not much else.
[04:46] <lifeless> ok, so lets see, get a handle on soyuz and I can week it a call
[04:47] <wgrant> eparse
[04:48] <lifeless> :)
[04:48] <wgrant> Week it a call?
[04:48] <lifeless> 'call it a week' with the object and verb transposed
[04:48] <wgrant> Oh, blah, of course.
[04:49] <wgrant> It is Friday afternoon, meh.
[04:49] <wgrant> soyuz == poppy?
[04:49] <StevenK> And wgrant is EOY'ing :-(
[04:50] <StevenK> wgrant: Did sinzui complain about my branch that he tossed through ec2 again?
[04:50] <lifeless> wgrant: yes
[04:50] <wgrant> StevenK: Vaguely, but without details.
[04:50]  * StevenK will thrash it to bits on Monday
[04:51] <lifeless> I hate that ubuntu's pastebin does openid to get at the raw version
[04:51] <wgrant> lifeless: spam
[04:51] <lifeless> wgrant: how does that help, given that the html version doesn't do openid
[04:51] <wgrant> No idea, but that's the rationale AFAIK.
[04:52] <lifeless> yes
[04:52] <lifeless> nevertheless, its a real nuisance when I want to apply a patch straight from it on a headless machine
[04:52] <wgrant> Yes.
[04:53] <lifeless> 5 out of 5 hunks FAILED -- saving rejects to file poppy-sftp.tac.rej
[04:53] <lifeless> 1 out of 1 hunk FAILED -- saving rejects to file service.py.rej
[04:53] <lifeless> 2 out of 2 hunks FAILED -- saving rejects to file loggingsupport.py.rej
[04:53] <lifeless> I shouldn't have bothered.
[04:53] <wgrant> Healthy.
[04:54] <lifeless> EOL probably
[04:54] <wgrant> I'd assume so.
[05:32] <lifeless> sometimes I love twisted
[05:32] <lifeless> sometimes not so much
[05:34] <lifeless> https://bugs.launchpad.net/launchpad/+bug/901498/comments/20
[05:34] <_mup_> Bug #901498: poppy-sftp OOPSes infinitely <oops> <Launchpad itself:In Progress by julian-edwards> < https://launchpad.net/bugs/901498 >
[05:54] <lifeless> whats the zope thing to check an interface is provided ?
[05:54] <lifeless> and implemented
[05:55] <lifeless> from zope.interface.verify import verifyObject
[05:59] <lifeless> ICanHasReiew? https://code.launchpad.net/~lifeless/python-oops-twisted/bug-902006/+merge/85065
[06:06] <lifeless> wgrant: ^ still around - or have I missed you?
[06:10] <wgrant> lifeless: Looks good.
[06:10] <wgrant> But with that, I might EOY.
[06:11] <lifeless> wgrant: see you on wed?
[06:11] <wgrant> Wed?
[06:12] <lifeless> australasia christmas do
[06:12] <wgrant> Unlikely. It's a little way away, and I have little other cause to go to Sydney :)
[06:13] <lifeless> no worries
[06:13] <lifeless> see you in budapest hten
[06:13] <wgrant> Indeedily.
[06:15] <nigelb> YOu guys sprinting in Budapest in Jan?
[06:16] <wgrant> Yeah, with platform^Wdistro^Wubuntuengineering^Wwhatevertheyarenow
[06:25] <nigelb> heh
[06:28] <lifeless> righto, poppy sorted.
[06:29] <lifeless> lp:/~lifeless/launchpad has the gore
[06:29] <lifeless> bah
[06:29] <lifeless> lp:/~lifeless/launchpad/bug-901498 has the gore
[07:39] <stub> Is this a spurious ec2 error? http://paste.ubuntu.com/764660/
[07:39] <wgrant> stub: Yes. I fixed it this morning.
[07:39] <stub> cool. lp-land then.
[07:40] <wgrant> stub: Oh, new baseline?
[07:40] <wgrant> I was wondering when that would happen.
[07:41] <stub> wgrant: Yes. Just slow getting it landed
[07:41] <stub> pebkac one day, ec2 fail one day...
[07:41] <lifeless> stub: does this include emptyin trusted.sql ?
[07:41] <lifeless> or is that separate
[07:42] <stub> lifeless: yes. But fti.py is still being called.
[07:42] <lifeless> thats fine
[07:42] <lifeless> stub: the dump doesn't include the fti vectors by default?
[07:42] <stub> lifeless: We can trash comments.sql too (I just want to catch production up first since the tree is more up to date at the moment)
[07:42] <lifeless> stub: yeah, I'm not coding in support for comments.sql
[07:43] <wgrant> Why empty it rather than removing it?
[07:43] <stub> lifeless: The dump of the schema includes the fti columns. The sample data goes to lengths to set them all to NULL when generating the sampledata (using an fti.py magic option) and again uses fti.py to regenerate them to real values after restoration
[07:44] <stub> wgrant: minimize code changes to db-devel
[07:44] <stub> wgrant: And one step at a time - easy to back out if I forgot some corner case and we need to recover
[07:44] <wgrant> Oh, didn't realise this was on db-devel.
[07:44] <wgrant> Why's it on db-devel?
[07:44] <lifeless> stub: so one way we could eliminate fti.py is to remove the null-on-dump, then do a no-op update, then remove fti.py ?
[07:45] <lifeless> stub: which would get us to the 'apply patches to change things' state we have prod in, for devs too
[07:45] <stub> lifeless: I like NULL on dump - no need to store generated data in the sample data. I'll just have a little helper we can use and trash fti.py
[07:45] <stub> erm... like NULLs in the dump. Makes the diffs nicer, makes things easier to read
[07:45] <wgrant> The sample data is *all* generated data.
[07:45] <lifeless> stub: most of sampledata is generated in some way ;)
[07:45] <stub> yeah yeah
[07:46] <wgrant> However, I am tempted to agree with stub until we get rid of sampledata entirely.
[07:48] <stub> I can think of one reason to put the fti data into the sample data dump - if we end up with bespoke fti indexes (say, a BugSearch table with its fti data updated from triggers on bug, bugtask, product etc) we can't really automate a way to rebuild it.
[07:48] <stub> rebuild the data I mean
[07:48] <lifeless> seems sound to me
[07:49] <lifeless> another reason is that the content of the sampledata dump isn't really editable anyhow - thats why we load it up, then tweak live, then dump.
[07:49] <wgrant> Well actually...
[07:49] <lifeless> people do, doesn't make it a good idea
[07:50] <lifeless> e.g. editing bugsummary extracted data in the dump will 'work' but generate invalid state
[07:52] <stub> I'm comfortable enough with my hypocrisy to tell people not to while doing it myself...
[07:54] <stub> I don't think I need to announce trusted.sql changes - almost always stored procedures arrive in db patches and I have to tell people to move the code.
[08:07] <stub> trashing trusted.sql will have the nice side effect of making staging restores more readable
[08:43] <jtv> lifeless, stub: good to have you both here.  DB review needed!  https://code.launchpad.net/~jtv/launchpad/db-849683-notnull/+merge/85076
[08:51] <stub> jtv: r=stub
[08:51] <jtv> th
[08:51] <jtv> x
[08:54] <adeuring> good morning
[09:02] <jtv> morning adeuring
[09:02] <adeuring> hi jtv!#
[09:03] <jtv> stub: I wonder if we could safely run our sample data through “cat --squeeze-blank” to normalize blank lines.  Getting so tired of that useless bit at the top of the diff.
[09:15] <stub> jtv: it would bite someone eventually who tries to put a double newline in a string for formatting
[09:16] <jtv> More to the point, would we have any sympathy?
[09:16] <stub> jtv: A regexp that understants the basic string quoting used though would be fine.
[09:17] <stub> jtv: Sure, especially if people want sample data to demonstrate markup for example
[09:17] <jtv> But what about our no-new-sampledata rule?
[09:17] <stub> that is for tests
[09:18] <jtv> Ah, dev sampledata.  Hadn't thought of that.
[09:18] <poolie> allenap, hi, can you reread https://code.launchpad.net/~mbp/launchpad/feature-modulus/+merge/84890
[09:19] <jtv> morning bigjools
[09:20] <bigjools> good morning
[09:20] <bigjools> bliss is reading email before starting IRC
[09:20]  * jtv parses
[09:21]  * jtv ponders
[09:21] <jtv> Who's Bliss?
[09:22] <bigjools> lifeless: \o/
[09:23] <jtv> Let me just go through a few reboot contortions to get audio working for the call.
[09:32] <lifeless> bigjools: ?
[09:33] <bigjools> lifeless: you fixed it
[09:33] <lifeless> bigjools: ah yes
[09:33] <lifeless> bigjools: was fairly straight forward, once I got the rest of my plate clear to actually look at it
[09:33] <lifeless> bigjools: (getting to that point took all day :P)
[09:33] <bigjools> lifeless: what a mess the logging code is :/
[09:34]  * bigjools OTP
[09:34] <lifeless> bigjools: I assume you're fine going forward?
[09:34] <bigjools> lifeless: will talk after I get off phone
[09:35] <stub> bigjools: twisted logging or logging module logging? Think I'm mainly responsible for the mess the latter is.
[09:35] <bigjools> both
[09:36] <bigjools> well, more twisted's
[09:36] <stub> LibrarianLogger should die if that causes you any headaches.
[10:04] <allenap> poolie: Sure.
[10:16] <poolie> thanks
[10:22] <lifeless> night all, have a good weekend
[10:22] <jelmer> have a good weekend lifeless
[10:24] <bigjools> lifeless: still there?
[10:56] <bigjools> stub: is the librarian logging to stdout right now?
[10:58] <bigjools> ah no, the crazy twisted rotating nonsense
[11:17] <jtv> bigjools: garbo is now cronned on dogfood.
[11:18] <bigjools> rejoice for more timeouts on df
[11:24] <jtv> I may be hammering it a bit hard.
[11:24] <jtv> Then again, dblooptuner.
[12:03] <rick_h_> morning
[13:22] <bac> hi adeuring, i'm going to grab stub's MP unless you're working on it
[13:22] <adeuring> bac: no, i haven't had a look yet
[13:23] <bac> ok
[14:24] <bigjools> abentley: can you spare a couple of minutes please? I need to ask about some codehosting tests
[14:24] <abentley> bigjools: I have stand-up in 6 minutes.  Do you want to talk before or after?
[14:25] <bigjools> abentley: I'll try and fit it in now if that's ok!
[14:25] <bigjools> in lib/lp/codehosting/puller/tests/test_acceptance.py there's a assertRanSuccessfully
[14:25] <abentley> bigjools: certainly.
[14:25] <bigjools> it checks to see that stdout is empty
[14:25] <bigjools> do you know the purpose of that:?
[14:26] <abentley> bigjools: no.  Let me annotate it...
[14:26] <bigjools> reason I ask is because I am changing how logging works across our apps because there's a honking great bug with the new oops  stuff, and now I get a non-empty log
[14:26] <bigjools> like this:
[14:26] <bigjools> + 2011-12-09 18:13:30+0530 [-] Log opened.
[14:26] <bigjools> + 2011-12-09 18:13:34+0530 [-] Main loop terminated.
[14:26] <bigjools> which seems innocuous, but ...
[14:28] <abentley> bigjools: I guess it might assume that logging is done to a file, not stdout.  That's the only reason I can think of.  You could ask jml; he wrote that.
[14:28] <bigjools> yeah that's all I could think of too
[14:32] <jml> It's running the cron job directly, so it's assuming no output
[14:32] <jml> and logging to a file
[14:32] <jml> see cronscripts/supermirror-pull.py
[14:33] <bigjools> jml: I guess my logging changes didn't quite work for supermirror!
[14:34] <bigjools> oh I see why, the test doesn't supply --logfile
[15:39] <bigjools> abentley: would you mind checking over my logging changes in this branch please? It affects a couple of codehosting services and I'd feel happier if an expert looked. https://code.launchpad.net/~julian-edwards/launchpad/detailed-gpg-exceptions/+merge/85138
[15:45] <abentley> bigjools: I'm sorry, but none of this is anything I have special knowledge about.
[15:45] <bigjools> abentley: ok fair enough, thanks
[15:45] <abentley> bigjools: np
[16:11] <allenap> adeuring, bac: Please can you review my branch? https://code.launchpad.net/~allenap/launchpad/check-teamparticipation-fix-too-bug-897269/+merge/85148
[16:11] <adeuring> allenap: sure
[16:11] <allenap> adeuring: Thanks.
[16:32] <adeuring> allenap: r=me
[16:33] <allenap> adeuring: Thank you :)
[16:36] <james_w> is lp.bugs.scripts.checkwatches.tests.test_bugwatchupdater.BugWatchUpdaterTestCase.test_known_error_handling the last test to run?
[16:36] <james_w> my ec2 instance has gone away again, and I' wondering if it ran to completion first
[16:41] <allenap> james_w: In what context, or is this ECHAN?
[16:41] <allenap> james_w: Ignore me, I can't read.
[16:42]  * allenap tries to find out.
[16:43] <allenap> james_w: No, it's not the last for me.
[16:43] <james_w> hmm
[16:44] <james_w> would someone please throw https://code.launchpad.net/~james-w/launchpad/binaries-created-since/+merge/85022 at ec2 land for me then please
[16:44] <james_w> I've had it die twice with no indication of any failures
[16:44] <allenap> james_w: Sure.
[16:44] <james_w> thanks
[16:51] <Laney> james_w: There is a typo there "teh `date_created`" ;-)
[16:52] <james_w> damnit
[16:52] <james_w> it's probably being rejected by the spell check then :-)
[16:52] <Laney> unless you are being 31337
[16:52] <bac> jcsackett: hi i'm looking at your branch for driver/maintainer picker -- thanks for making this long-needed improvement.
[16:53] <bac> jcsackett: i notice, however, you got rid of the pop-up help for driver.  was that accidental?
[16:53] <jcsackett> bac: it was. offhand i'm not sure how to include it back in though. i'll poke around.
[16:54] <jcsackett> (i don't think just putting the anchor back in will look right b/c of the html around the button, but maybe)
[16:54] <bac> jcsackett: ok.  i think we need to keep it since no one knows what a driver is.  r=me pending figuring that part out.
[16:54]  * jcsackett nods.
[16:54] <jcsackett> thanks, bac.
[19:13] <lifeless> poolie: oh hai
[19:13] <lifeless> poolie: btw we'll get soft timeouts from bazaar.launchpad.net now
[19:14] <lifeless> poolie: may have to fiddle with oops-tools reports a little to get good summaries, but we'll know how many requests go over 7 seconds
[19:27] <abentley> bac: could you please review https://code.launchpad.net/~abentley/launchpad/fix-expirable-bugs/+merge/85181 ?
[19:27] <bac> abentley: sure
[19:28] <abentley> bac: thanks.
[19:35] <bac> abentley: i don't understand why the original problem occured, producing the KeyError.  the only actual code change i see is using 0 instead of the config value.
[19:36] <abentley> bac: The bug fix is through making BugTaskExpirableListingView a subclass of BugTaskSearchListingView, so that BugTaskSearchListingView.initialize sets up the correct IJSONRequestCache values.
[19:36] <bac> ah, ok.  i overlooked that
[19:37] <abentley> bac: I may not have explained that well.
[19:38] <bac> abentley: no, my fault.  but that's why on-call reviewing is great.
[19:39] <bac> done abentley.  thanks.
[19:40] <abentley> bac: thank *you*.
[19:42] <flacoste> woohoo for autmatically updated preview diff!
[20:12] <Duditz> hi all! please, after I do launchpad actions, when my karma is updated?
[20:13] <jelmer> Duditz: I think it's updated weekly or so
[20:14] <Duditz> great, thanks jelmer
[20:15] <flacoste> rabbit seems to have problems on the latest db_lp build
[20:16] <flacoste> https://lpbuildbot.canonical.com/builders/lucid_db_lp/builds/1577/steps/shell_6/logs/summary
[20:18] <sinzui> bac: do you have time to review https://code.launchpad.net/~sinzui/launchpad/series-package-subscriptions/+merge/85188 when the diff appears?
[20:30] <bac> sinzui: i do
[20:37] <sinzui> I see db_lp failed. I cannot reproduce the error: https://lpbuildbot.canonical.com/builders/lucid_db_lp/builds/1577/steps/shell_6/logs/summary Should I retry the build
[20:50] <bac> sinzui: done.
[20:51] <sinzui> thank you bac
[21:21] <sinzui> jcsackett, do you have time to mumble
[21:23] <jcsackett> sinzui: yes, one moment.
[21:29] <abentley> bac: AFAICT, setup_subscription_link in lib/lp/registry/javascript/structural-subscription.js throws an exception if no subscription link is present.  Was this intentional?
[21:35] <bac> abentley: yes, the link should be present
[21:37] <abentley> bac: You're written code in lp.bugs.browser.structuralsubscription.StructuralSubscriptionMenuMixin that makes it not always present.
[21:43] <bac> abentley: so for anon users the JS is throwing the error?
[21:44] <abentley> bac: Actually, I'm getting the error on https://bugs.launchpad.net/charm
[21:45] <abentley> bac: I don't understand why yet.
[21:45] <abentley> bac: I believe it's the root cause of bug #902252
[21:45] <_mup_> Bug #902252:  sort buttons that are missing on the distribution dynamic bugs listing <bug-columns> <fallout> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/902252 >
[21:51] <abentley> bac: I think this is because I am not a member of the bug supervisor, juju Charm Contributors
[21:53] <bac> abentley: yes, the logic behing userCanAlterBugSubscriptions is crazy.  it's an ubuntu thing.
[21:54] <abentley> bac: So I think the error should be scaled back at most to a warning, maybe an info or debug.
[21:54] <bac> abentley: that is probably a good idea.
[21:54] <abentley> bac: cool, thanks.
[21:57] <abentley> bac: I've confirmed that adding me to "juju Charm Contributors" fixes the bug.
[22:03] <bac> abentley: that isn't very scalable!  :)
[22:04] <abentley> bac:-)
[22:30] <james_w> FAILURE: lib/lp/bugs/javascript/tests/test_buglisting_utils.html
[22:30] <james_w> is that a known failure currently?
[22:30] <james_w> it's very unlikely to do with anything in my branch that just got rejected because of that failure
[22:34] <lifeless> no
[23:15] <james_w> well it passes locally on tip
[23:16] <james_w> and with my branch merged
[23:16] <james_w> so would someone please throw https://code.launchpad.net/~james-w/launchpad/binaries-created-since/+merge/85022 at ec2 land again?