[08:42] <dandrader> mzanetti, gdbus call --session --dest com.canonical.UnityGreeter --object-path / --method com.canonical.UnityGreeter.HideGreeter
[08:42] <Saviq> pstolowski, pete-woods, remote scopes crashing unity8: bug #1418176, actually hoping it's related to bug #1410385 that we don't have any trace on yet
[08:42] <pete-woods> Saviq: thanks
[08:55] <pete-woods> Saviq: have a fix already :)
[08:55] <pstolowski> Saviq, we have a fix for that in silo 8, but currently fighting with test failures there
[08:55] <Saviq> pete-woods, :)
[09:22] <tsdgeos> pstolowski: what do you think of my comment in https://code.launchpad.net/~stolowski/unity-scopes-shell/fix-temp-scopes/+merge/248235 ?
[09:22] <pstolowski> tsdgeos, yeah, i've a branch
[09:22] <tsdgeos> Cimi: and you from https://code.launchpad.net/~cimi/unity8/fix-open-new-scope-from-tmp/+merge/248538 ?
[09:22] <tsdgeos> :D
[09:23] <pstolowski> tsdgeos, tbh i'm not totally sure why we need that, i guess it's for you to be able to mock stuff?
[09:24] <tsdgeos> pstolowski: you mean having the api in a separate place?
[09:24] <tsdgeos> pstolowski: yeah so that we have an expectation of what the api is going to be
[09:24] <tsdgeos> and we can mock it
[09:24] <pstolowski> tsdgeos, having the abstract scopes interface... yeah, ok
[09:24] <tsdgeos> and it doesn't happen that you change it behind our feet without us realizing
[09:25] <tsdgeos> which may be easier to happen if it was all part of your project alone
[09:29] <tsdgeos> pstolowski:
[09:29] <tsdgeos> 	+ libunity-api-dev (>= 7.95),
[09:29] <tsdgeos> 	libunity-api-dev (>= 7.94),
[09:29] <tsdgeos> second needs to be a -
[09:30] <pstolowski> tsdgeos, oh, a mistake in conflict resolution
[09:31] <pstolowski> tsdgeos, pushed
[09:47] <tsdgeos> pstolowski: https://code.launchpad.net/~stolowski/unity-scopes-shell/fix-temp-scopes/+merge/248235 looks good to me, want me to top approve or prefer someone else to review too?
[09:51] <pstolowski> tsdgeos, top approve pls, thanks!
[09:52] <tsdgeos> pstolowski: btw closing from scopes makes so much sense
[09:52] <tsdgeos> \o/
[09:52] <tsdgeos> pstolowski: was wondering if we even wanted to kill the possibility of closing from scope
[09:52] <tsdgeos> since basically now it's just callign scopes
[09:53] <tsdgeos> it's not even checking if the scope was opened though that scope
[09:53] <tsdgeos> but i guess it's fine
[09:56] <Saviq> tsdgeos, pstolowski, there's one reason (I think) why we had it in Scope, and that's a stack of scopes
[09:57] <Saviq> i.e. you go Apps > Store > NewScope > YouTube > Store
[09:57] <Saviq> you have two Store scopes, and you want to retain its history
[09:57] <pstolowski> tsdgeos, yeah. i left it exposed in Scope not to break any of your code.
[09:57] <tsdgeos> Saviq: that won't work atm
[09:58] <tsdgeos> you'll get a gotoscope on the last one
[09:58] <tsdgeos> well we dont' support stacks anyway :D
[09:58] <Saviq> tsdgeos, don't think so?
[09:58] <Saviq> tsdgeos, you only  get gotoScope for favs
[09:58] <tsdgeos> Saviq: yes with the code pstolowski just did
[09:58] <tsdgeos> i think
[09:58] <Saviq> tsdgeos, but anyway, yeah, we have no stack, and it doesn't actually seem like we will
[09:59] <Saviq> anyone seen MacSlow today?
[09:59] <tsdgeos> nope
[10:06] <Saviq> seb128, http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-008
[10:10] <seb128> Saviq, that fixes it
[10:10] <seb128> thanks
[10:10] <Saviq> coolz
[10:10] <seb128> now what about qtmir/gtk? ;-)
[10:16] <Saviq> seb128, they're testing the silo
[10:17] <seb128> great
[10:18] <Saviq> kgunn, I removed the sync now to prevent accidental rebuilds
[11:54] <Cimi> tsdgeos, but Scope::activate(QVariant const& result) is ever being called?
[11:55] <tsdgeos> Cimi: of course
[11:55] <Cimi> tsdgeos, by what?
[11:56] <Cimi> tsdgeos, confused about those mocks
[11:56] <tsdgeos> tsdgeos_work@xps:~/phablet/unity8/unity8/qml/Dash$ wcgrep "activate("
[11:56] <tsdgeos> ./GenericScopeView.qml:72:            // TODO Technically it is possible that calling activate() will make the scope emit
[11:56] <tsdgeos> ./GenericScopeView.qml:75:            scope.activate(result)
[11:56] <tsdgeos> ./ScopesList.qml:126:                        onRequestActivate: root.scope.activate(result);
[11:56] <Cimi> ah I see
[12:12] <Cimi> tsdgeos, because the previous  close scope was checking m_openScope which changed only from the activate call
[12:12] <Cimi> tsdgeos, this activate call only seem to happen when someone clicks an item inside the opened scope
[12:12] <Cimi> that's why I removed that code inside the mock, it looked confusing
[12:13] <tsdgeos> well you're aware there's test code using it, no?
[12:13] <tsdgeos> i mean you just removed part of the test
[12:14] <tsdgeos> i suggest you just stop using the scopeToCallCloseOn
[12:14] <tsdgeos> or wathever weird name i used
[12:14] <tsdgeos> can't remember now
[12:14] <tsdgeos> and just call closeScope on scopes
[12:14] <Cimi> yeah
[12:14] <tsdgeos> and put an assert on Scope::closeScope mock to make it clear we don't want to use it
[12:15] <Cimi> tsdgeos, shall I add something inside the new close inside scopes?
[12:15] <tsdgeos> and make Scopes::closeScope actually work (and assert if the scope you want to close is not the one that was activated)
[12:15] <Cimi> for the mock
[12:15] <Cimi> so I need to create this temp scopes set too?
[12:15] <Cimi> I don't understand the boundaries of mocks and what is needed and what not
[12:17] <tsdgeos> well you need to make it work, otherwise how are you going to test that clicking in that button that is supposed to bring you to another scope actually brought you to another scope?
[12:18] <tsdgeos> there's no need to create/destroy them
[12:18] <tsdgeos> we have a few scopes in the mock that are not there by default
[12:18] <tsdgeos> so you can just do what the old closeScope did, store the pointer in a variable/list and make sure the close you're getting is in that variable/list
[13:52] <Saviq> tsdgeos, hmm, our history popup in the dash appears offscreen, have we been touching that code recently?
[13:52] <tsdgeos> Saviq: not that i remember
[13:53]  * Saviq goes to #sdk
[14:05] <mzanetti> Daekdroom: https://code.launchpad.net/~mzanetti/unity8/launcher-fixes/+merge/248761
[14:05] <mzanetti> dandrader: https://code.launchpad.net/~mzanetti/unity8/launcher-fixes/+merge/248761
[14:06] <dandrader> mzanetti, cool. reviewing it now
[14:07] <Daekdroom> Hm... do I have to review it as well? :)
[14:26] <mterry> Is anyone familiar with what differences exist between tryTest and testTest?  I've got this problem where a DirectionalDragArea isn't working in testTest but does in tryTest...  :(
[14:26] <mterry> dandrader, ^?
[14:31] <MacSlow> mterry, tryTest is interactive... while testTest is automatic
[14:31] <mterry> MacSlow, yeah, but why would drags be affected?
[14:32] <mterry> MacSlow, something seems to be stopping all touch/mouse interactions in test mode
[14:33] <MacSlow> mterry, hm... not sure... I've not run into such issues with drag-related QML-tests (for notifications)
[14:33] <MacSlow> mterry, can you be more specific?
[14:33] <mterry> :(  It also affects dragging down the indicators and the launcher
[14:34] <mterry> MacSlow, in test mode, clicks don't seem to register.  I've removed all code in init() and use a sample test with wait(100000).  So no test code is messing things up.  But for some reason, testTest fails to take input while tryTest is fine
[14:35] <mterry> This is only with a branch I have that is trying to merge in another branch.  Both branches are fine by themselves.  But the size of the branches makes it hard to narrow down the change
[14:35] <mterry> And I'm not even sure where to look because this is such a weird bug
[14:35] <mterry> I don't know where we execute code that is specific to testTest runs vs tryTest runs
[14:36] <dandrader> mterry, "make testFoo" uses qmltestrunner whereas "make tryFoo" uses uqmlscene
[14:37] <mterry> dandrader, huh...
[14:37] <MacSlow> mterry, you can have the commandlines for those different make-targets dumped and then copy&paste them to play around...
[14:37] <MacSlow> mterry, maybe that'll help to better narrow down your issue
[14:37] <mterry> yeah
[14:38] <MacSlow> mterry, I did just that for the new mocked NotificationModel in one of the notification-related QML-tests
[14:38] <dandrader> mterry, with "make test" the tst_Foo.qml file is run by qmltestrunner binary, with "make try", the qml test file is run by the uqmlscene binary. clearer now?
[14:39] <mterry> dandrader, yes no it's clear.  I was just trying to remember what I knew about those two and what they did different
[14:39] <mterry> I wonder if there is also an environment var diff
[14:39] <dandrader> mterry, and in uqmlscene we convert mouse events to touch events before sending them to the qml scene
[14:39] <mterry> hmmm
[14:40] <dandrader> mterry, in order to emulate a touchscreen usage in the desktop
[14:41] <dandrader> mterry, also I don't think you can properly interact with a test in "make testFoo" while it's hanging in a wait()...
[14:42] <MacSlow> mterry, btw... I only use mouseClick() and mouseDrag() in the notification QML-tests.
[14:42] <dandrader> MacSlow, which is a bad habit as it does not simulate well the usage on touchscreen devices
[14:42] <mterry> dandrader, I'm pretty sure you can...  let me test on trunk
[14:42] <facubatista> I just upgraded to Vivid r89 and unity8 seems to have a weird problem, it repeats this every ~10 seconds, in its logs: http://linkode.org/TMgjPipYdh9URrootGEwv3
[14:42] <facubatista> does anybody know what it could be? thanks!
[14:43] <dandrader> mterry, I recall I had inconsistent and weird results wherever I tries to interact with a test while on wait()..... but maybe I'm wrong
[14:43] <dandrader> *whenever
[14:44] <MacSlow> dandrader, hm... that was never pointed out in MR-reviews... I'll keep it in mind for the future.
[14:46] <tsdgeos> dandrader: https://code.launchpad.net/~dandrader/unity8/fixSurfaceActiveFocus/+merge/247836
[14:46] <dandrader> tsdgeos, ok
[14:49] <mterry> dandrader, you are so right!   wait() blocks me from interacting.  Phew!  So something else is wrong because I have failing tests, but I thought I was seeing something much worse.  I could have sworn I've done that in the past. Thanks for the heads up
[14:49] <MacSlow> mterry, mixup between wait() and waitForRendering() maybe?
[14:50] <mterry> Maybe...  it would be nice if there *was* a "stop and let user futz with stuff" command that I could insert in a test for testing purposes
[14:51] <dandrader> tsdgeos, fixed
[14:52] <tsdgeos> dandrader: ok, reapproved
[14:52] <dandrader> tsdgeos, thanks
[15:43] <Saviq> MacSlow, try running the test under xvfb, loop it, there's probably just some timing issue, I was able to repro quite reliably
[15:43] <MacSlow> Saviq, ah ok... will try that
[15:44] <MacSlow>  Saviq, I removed some wait()s I wasn't fond of... guess I overdone it :)
[15:45] <Saviq> MacSlow, let me know if you need some testing done, maybe add debugging etc.
[15:48] <MacSlow> Saviq, do we have a specifc make-target for xvfb-run or do I need to do this manually?
[15:48] <Saviq> MacSlow, xvfbtestNotifications
[15:49] <MacSlow> Saviq, hm... still passes here
[15:50] <MacSlow> Saviq, I'll try my slower laptop
[15:50] <Saviq> MacSlow, yup, that might trigger it too
[15:50] <MacSlow> Saviq, I tend to forget the GeForce-monster that's in this machine
[16:56] <greyback_> dandrader: hey, I've taken over https://code.launchpad.net/~mir-team/qtmir/port-to-event-2.0/+merge/248067 - if you have time, could you give it a review pass please?
[16:56] <greyback_> dandrader: tomorrow obviously
[16:59] <dandrader> greyback_, I'm fine with you taking it over
[17:00] <dandrader> greyback_, oh, you took over the branch, not the review
[17:00] <greyback_> dandrader: yeah
[17:01] <dandrader> so lazy dandrader still has to review it
[19:13] <josharenson> Anyone who has build ubuntu-system-settings-online-accounts? It seems that the online-accounts-service isn't finding mirclient and its compiling in mir-helper-stub.cpp instead of mir-helper.cpp. Is this expected? Its giving me a headache w/ trusted sessions.
[19:16] <gQuigs> who maintains https://unity.ubuntu.com?
[19:16] <gQuigs> I'm looking for an updated version of this page - https://unity.ubuntu.com/getinvolved/development/unity8/#developing-unity
[19:16] <gQuigs> vivid current instructions for developing unity8 (specifically want to do desktop, but on an nvidia card if possible)
[19:17] <josharenson> gQuigs: I'm not sure there is an updated version... Do you have any specific questions?
[19:17] <josharenson> ah
[19:18]  * josharenson looks for a branch that could help
[19:18] <gQuigs> do I need any PPAs on vivid?  and will it even work with the nvidia proprietary driver?
[19:20] <gQuigs> seems it's a wordpress site...
[19:20] <josharenson> gQuigs: still looking, I actually haven't ran it on the desktop in a while... mostly been working on mobile. As for the nvidia driver, I cannot answer that, maybe try #ubuntu-mir
[19:33] <josharenson> gQuigs: I'd try running http://cdimage.ubuntu.com/ubuntu-desktop-next/daily-live/current/ from a usb drive
[19:34] <josharenson> gQuigs: I just tried making it work a hacky way, and broke my computer for a bit
[19:35] <gQuigs> josharenson: oh, I know that doesn't work right now..  so even to develop it only works on open source right now
[19:35] <gQuigs> for some reason I thought it was just not stable for that yet..
[19:35] <gQuigs> josharenson: thanks!
[19:35] <josharenson> gQuigs: yeah I just saw the docs stating that... np, sorry I couldn't be of more help


[12:44] <nixternal> Laser_away: ubuntu-docs package doesn't install a .desktop file, so that is coming from somewhere else.
[12:44] <nixternal> But that doesn't matter, just tell me where this .desktop file is supposed to go and that is all I need to know, what dir is it going into
[12:51] <dsas> nixternal: it's installed by gnome-panel if you're talking about about-ubuntu.desktop
[12:54] <dsas> but I guess edubuntu-docs is the correct place for the edubuntu one, as long as gnome-panel is patched to look for it
[12:54] <dsas> ubuntu-docs is probably the right package to install the about-ubuntu.desktop too really...
[12:58] <LaserJock> dsas: yeah
[12:58] <LaserJock> gnome-panels is what sets up the menu
[12:58] <LaserJock> so it kinda makes some sense to put it in gnome-panels-data
[12:58] <LaserJock> but we need to keep things a bit tighter
[01:28] <dsas> who do I have to bug to get revert rights on h.u.c ?
[01:28] <LaserJock> revert?
[01:28] <LaserJock> probably mdke or Burgundivia
[01:28] <dsas> I want to revert a wikipage from rev 46 to 44
[01:28] <LaserJock> are you a member of the wiki team?
[01:29] <LaserJock> I honestly don't know how the ACLs on h.u.c are set
[01:29] <dsas> LaserJock: I'll try that.
[01:30] <dsas> bah, moderated team.
[01:31] <dsas> if someone who does have rights could revert https://help.ubuntu.com/community/WifiDocs/Device/CompaqW200?action=info to revision 44 I'd be greatful :)
[01:31] <dsas> I could do it manually I guess.
[02:16] <bimberi> dsas: I can do it (although by the looks of the comments I'm too late)
[02:17] <dsas> yeah, thanks for the offer anyway bimberi, I just did things the "manual" way
[02:18] <bimberi> Righto.
[02:23] <bimberi> dsas, LaserJock: delete/rename/revert rights on h.u.c/c are assigned by someone with administrative access to Moin.  mdke has it (iirc). Not sure who else.
[02:24] <bimberi> it's intended that it be linked to membership of the LP wiki team but I'm fairly sure it's not been implemented.
[05:52] <Kamping_Kaiser> There used to be a wiki page detailling how to port ubuntu to a new platform. does anyone know what happened to it? i'v been sewarching for about 30 min and cant see a sign of it
[08:52] <mdke> morning
[08:53] <Kamping_Kaiser> hi
[09:24] <CIA-5> Ubuntu Documentation: mdke * r3985 / (26 files in 20 dirs):
[09:24] <CIA-5> Ubuntu Documentation: * large string changes to windows.xml, as discussed on mailing list
[09:24] <CIA-5> Ubuntu Documentation: * refreshing pot templates
[09:25] <Madpilot> spambot
[09:25] <Madpilot> ;)
[09:26] <Kamping_Kaiser> when did -docs grow another bot?
[09:26] <Madpilot> fairly recently
[09:26] <mdke> it took many months to add it but we've been looking for it for ages
[09:26] <mdke> it's pretty cool!
[09:27] <Kamping_Kaiser> hehe. i only just saw one in another chanel... i feel like i'm being stalked by CIA-* bots ;)
[09:29] <Madpilot> of course the CIA is watching you. We're all Communist penguin-lovin' Open Source freaks, right?
[09:31] <Kamping_Kaiser> s/O*/Free/g
[07:57] <XiXaQ> should this page really be on help.ubuntu.com? https://help.ubuntu.com/community/VHCS
[07:58] <LaserJock> nixternal: got a sec?
[08:00] <mdke> XiXaQ: well, the subject matter looks right. It's pretty ugly though
[08:02] <XiXaQ> I think it should be on the wiki instead.
[08:03] <LaserJock> why?
[08:05] <XiXaQ> because it doesn't explain anything, and it sais it's a work in progress.
[08:05] <LaserJock> so?
[08:06] <Burgwork> XiXaQ: feel free to edit it
[08:06] <Burgwork> in progress is from may of last year
[08:06] <LaserJock> help.u.c vs wiki.u.c is help documentation vs developer documentation not good doc vs. bad doc
[08:07] <XiXaQ> oh
[09:06] <nixternal> LaserJock: yo yo
[10:26] <LaserJock> nixternal: sorry, was picking up my car from the shop
[10:26] <LaserJock> nixternal: did you have a chance to look at the About Edubuntu stuff?
[10:32] <nixternal> LaserJock: I just need to know where to place that .desktop file. telling me gnome-panel doesn't help
[10:32] <nixternal> need the absolute directory
[10:32] <dsas> could someone revert RestrictedFormats/PlayingDVDs to revision 18 or so?
[10:33] <nixternal> I can't do anything on h.u.c/community
[10:33] <nixternal> I can edit a page and that is it
[10:33] <dsas> can anyone? :(
[10:33] <nixternal> rediculous the way it is setup
[10:33] <dsas> someone removed the post-dapper instructions for reading dvds anyway.
[10:33] <nixternal> call it community documentation yet it is restricted
[10:36] <dsas> oh hang on.
[10:36] <dsas> i'm losing my mind.
[10:36] <nixternal> heh
[10:36] <dsas> do you need libdvdread3 *and* libdvdcss2 ?
[10:37] <nixternal> dsas: I don't think so, but I am not 100% positive
[10:38] <nixternal> hehe
[10:39] <LaserJock> well there are a few issues with the wiki stuff
[10:39] <LaserJock> the problem is that right now it's sort of "all or nothing"
[10:39] <nixternal> LaserJock: I need a MOTU mentor! I am going for MOTU this next build cycle no matter what!
[10:40] <LaserJock> so people who can delete, etc. have virtually complete admin rights to the wiki
[10:40] <nixternal> I can't do anything but edit
[10:40] <LaserJock> right
[10:40] <nixternal> which defeats the purpose, but who am I?
[10:40] <LaserJock> the plan is to let all wiki team members have delete/rename, etc. rights
[10:40] <LaserJock> it's not designed that way
[10:40] <LaserJock> it's a bug
[10:41] <LaserJock> one that is not easy to fix apparently
[10:41] <nixternal> ya, for about 6 months now
[10:41] <nixternal> hehe
[10:41] <nixternal> you beat me to the punch on that one
[10:41] <nixternal> we need to update moin as well or switch to mediawiki
[10:41] <LaserJock> yes that's another item
[10:42] <LaserJock> it's all Canonical so it's a bit tough
[10:43] <LaserJock> well, there used to be problems
[10:43] <LaserJock> we couldn't easily upgrade moin
[10:43] <LaserJock> I'm not sure if it was because ubuntu.com was running moin or not
[10:43] <nixternal> MoinMoin is a pain to admin, I will give them that
[10:43] <nixternal> we use it at school and recently did an upgrade to the latest version
[10:43] <nixternal> it wasn't fun, but it wasn't that crazy
[10:44] <LaserJock> we might be able to do better now
[10:44] <LaserJock> but it still means getting sysadmins to do it
[10:44] <LaserJock> we've wanted to upgrade for over a year now
[10:44] <dsas> haven't they upped their sysadmin power over the last few months though? I think there's 3 of them now...
[10:44] <nixternal> ya, and towards the end of a build cycle isn't the best time for them either I am sure
[10:44] <LaserJock> and Corey keeps wanting to move to mediawiki ;-)
[10:44] <LaserJock> dsas: yes
[10:44] <nixternal> LaserJock: sabdfl wants to move to mediawiki
[10:45] <LaserJock> which is funny
[10:45] <nixternal> he stated it in a blog post about 6 months back
[10:45] <LaserJock> since the reason we went with Moin was because they wouldn't let PHP on the Canonical servers
[10:46] <LaserJock> we've got so much data, it's not easy to just up and migrate
[10:46] <LaserJock> we'll probably have to discuss it for Feisty+1
[10:47] <nixternal> and feisty+2, feisty+3, and so on... ;p
[10:47] <LaserJock> nah
[10:48] <LaserJock> one of the reasons we stayed with Moin is because it was better for developer work, I think
[10:48] <LaserJock> now that we have help.u.c we can separate the 2
[10:49] <LaserJock> but then we put quite some effort into moin->docbook
[10:49] <LaserJock> I really like moin for personal use (Desktop Moin)
[10:49] <nixternal> really?
[10:49] <dsas> and there's possibly the launchpad -> Moin integration
[10:49] <nixternal> I was thinking about using it
[10:50] <LaserJock> for personal use it's great because you just drop it in and go
[10:50] <LaserJock> no MySQL or Apache or anything
[10:50] <dsas> dvd page is fixed I think.
[10:50] <dsas> doesn't kde have a equivalent to tomboy?
[10:50] <LaserJock> basket
[10:50] <LaserJock> perhaps
[10:50] <LaserJock> I think that's how it's spelled
[10:51] <nixternal> basket is correct, but far from equivalent to tomboy
[10:51] <nixternal> basket is way more involved and complicated. you can do so much with it, but hell it is nuts
[10:51] <LaserJock> I so wish I could get tomboy for OS X
[10:51] <dsas> sounds like kde </troll>
[10:51] <nixternal> I like tomboy because 1) super easy, and 2) wiki effect
[10:52] <dsas> I still use a scattering of text files and paper notes.
[10:52] <nixternal> hrmm, actually I have looked at tomboy and noticed it is a fairly straight forward and easily coded app, wonder how difficult it is to port from gtK to Qt
[10:52] <dsas> nixternal: does qt have mono bindings?
[10:53] <Burgwork> nixternal: use basket
[10:53] <nixternal> dsas: yes
[10:53] <dsas> cool, didn't know that
[10:53] <nixternal> Burgwork: basket is more than what I need
[10:53] <Burgwork> KDE is more than I need
[10:53] <nixternal> more than what many people need
[10:54] <Burgwork> indeed, why I use GNOME :)
[10:54] <nixternal> sorry, been 10 years with KDE. I won't go anywhere else :)
[10:54] <nixternal> I would rather use Vista :)
[10:55] <dsas> ouch.
[10:55] <nixternal> LaserJock: http://moinmoin.wikiwikiweb.de/MoinX
[10:55] <LaserJock> yep
[10:56] <LaserJock> I used it a fair bit
[10:56] <LaserJock> works very well
[10:56] <nixternal> ahh, I just brain farted
[10:56] <LaserJock> but not quite as light as tomboy
[10:56] <nixternal> you said tomboy for mac, not moin
[10:56] <LaserJock> yeah
[10:56] <LaserJock> although it's sorta similar


[00:00] <cherylj> davecheney: thanks!
[00:27] <waigani> thumper: do you also not want the username quoted in the error returned by the apiserver?
[00:28] <thumper> I think quoted is fine from the api server as it is developer facing
[00:29] <waigani> thumper: yep, wrote too quickly - I see we use %q in the rest of the errors in that package
[04:36] <thumper> wine time
[04:41] <waigani> wallyworld: thanks for the review. I've responded to your comments, but can't seem to update my diff.
[04:41] <wallyworld> waigani: i saw the replies, so marked at +1
[04:42] <waigani> wallyworld: okay thanks
[04:42] <wallyworld> np
[06:43] <wallyworld> dimitern: heya
[06:43] <dimitern> wallyworld, morning
[06:43] <wallyworld> god weekend? i hope you gots sleep :-)
[06:43] <wallyworld> good
[06:44] <dimitern> wallyworld, :) ~18h in total
[06:44] <wallyworld> wow
[06:45] <wallyworld> i have a question - kat finished some goamz signing work, and it's now merged. but it looks like stuff is missing in the v3 branch, i've done a pr  https://github.com/go-amz/amz/pull/33
[06:46] <wallyworld> i'm testing the storage stuff live, but was wondering if you could test the network stuff as i don't have enough to go on with what to test
[06:47] <dimitern> wallyworld, yeah - I was just looking at your two PRs in amz.v3 after v3-unstable was promoted to v3
[06:48] <wallyworld> i've pull her juju-core branch to test juju live katco-:goamz-v3-support
[06:49] <dimitern> wallyworld, I thought I *did* compare v2 to v3 to see if something was missing but apparently I missed something
[06:55] <wallyworld> dimitern: stupid irc dropped out, not sure if i missed any reply
[06:56] <dimitern> wallyworld, I was looking at https://github.com/go-amz/amz/compare/v1...v2 and https://github.com/go-amz/amz/compare/v2...v3
[06:56] <wallyworld> yeah, the v2..v3 diff what what i based the pr on
[06:57] <dimitern> wallyworld, but I can't see the changes in the PR to be missing from v3?
[06:58] <wallyworld> hmm, maybe i had an out of date local copy
[06:58] <wallyworld> let me check
[06:58] <dimitern> wallyworld, that's might be - esp. if you're using symlinks in your gopath
[06:59] <wallyworld> hmm, i just git pulled in my v3 master and no updates
[06:59] <wallyworld> i'll look around a bit
[07:01] <wallyworld> dimitern: so as an example, in https://github.com/go-amz/amz/tree/v3/ec2 there's no blockdevicemappings_test.go
[07:01] <wallyworld> that file should be there and is in v2
[07:02] <dimitern> wallyworld, thats true, but why it doesn't show up on the v2..v3 diff?
[07:02] <dimitern> weird
[07:03] <wallyworld> yeah, and there's a bunch of network stuff missing too
[07:03] <dimitern> wallyworld, ok, I'll do the diff locally to be sure
[07:03] <wallyworld> ok
[07:03] <dimitern> wallyworld, apparently github compare lies
[07:04] <wallyworld> there must be a logical reason you'd think
[07:07]  * dimitern keeps digging
[07:18] <dimitern> wallyworld, for some reason even though v3 was branched off v2 some commits in v2 are missing
[07:18] <wallyworld> dimitern: fwiw, with the go-amz branch in pr 33, the new juju storage stuff works live, and the unit tests pass. the networking stuff fails live for me because of vpc limits
[07:18] <wallyworld> hmm
[07:19] <dimitern> wallyworld, can connect to the ec2 web ui with the shared creds or you just have the api keys?
[07:19] <wallyworld> i never use the web ui, just ElasticFox
[07:20] <wallyworld> i have the api keys also for juju
[07:20] <dimitern> wallyworld, you can clean up the stale vpc from there
[07:21] <dimitern> wallyworld, if you have the account to login to the web ui can you send them to me by mail along with the api keys?
[07:21] <wallyworld> ok, i'll see if i have it
[07:23] <dimitern> wallyworld, in the PR #33 there are still some things missing from v2 btw
[07:23] <wallyworld> ah, ok
[07:24] <dimitern> wallyworld, but not much, so if you go ahead and merge that, I'll propose a follow-up to add the missing
[07:27] <wallyworld> dimitern: ok. i have access to a web ui, using my canonical.com email as the user name, but it appears to be a different account to that controlled using the api keys i have and which i use with elastic fox
[07:28] <wallyworld> dimitern: ok, that's merged
[07:28] <dimitern> wallyworld, ok, I'll ask jam if he has them
[07:28] <dimitern> wallyworld, thanks!
[07:28] <wallyworld> dimitern: once your stuff lands, i'll update a fork of kath's branch i have and land that in core
[07:29] <dimitern> wallyworld, ok, will let you know
[07:29] <wallyworld> ok, i might duck off to have dinner
[08:27] <Muntaner> good morning devs o/
[08:27] <Muntaner> I'm writing my first charm and having some problems, can anybody help me?
[08:33] <dimitern> Muntaner, morning! try asking in #juju
[08:33] <dimitern> for all your charming needs :)
[08:33] <Muntaner> dimitern, ty ;)
[08:33] <TheMue> morning
[08:37] <dooferlad> dimitern, TheMue: morning
[08:38] <dimitern> TheMue, dooferlad, morning folks!
[08:38] <TheMue> dooferlad: dimitern: o/
[08:38] <dooferlad> dimitern: heard anything from voidspace?
[08:39] <dimitern> dooferlad, he become a dad over the weekend
[08:39] <dimitern> :)
[08:40] <dooferlad> dimitern: awesome!
[08:40] <TheMue> aaah, fantastic news
[08:40] <dimitern> so I guess he won't be here today
[08:40] <dimitern> yeah indeed :)
[08:40] <dooferlad> indeed
[08:40] <dimitern> I've seen pics on FB
[08:41] <TheMue> oh, dedn't know he's on FB, so far only G+. while have a look
[08:43] <TheMue> found and added him ;)
[08:54] <jam> dimitern: sorry I misesd you earlier, just missed the schedule. what's up with ec2?
[08:55] <jam> wallyworld: maybe you know?
[08:55] <dimitern> jam, minor mishap with some missing commits from amz.v2 into amz.v3, but wallyworld sorted that out
[08:55] <jam> dimitern: k, I thought there was something you needed w VPC
[08:55] <dimitern> jam, I'm now manually comparing amz.v2 to the updated amz.v3 to make sure all is good, then I'll do a live test
[08:56] <jam> dimitern: I do see a spare network interface in us-east-1
[09:00] <dimitern> TheMue, sorry, I'll be 10m late for our 1:1
[09:01] <TheMue> dimitern: ok
[09:06] <dimitern> wallyworld, jam, I'm happy to report after that PR #33 landed amz.v3 has everything is needs wrt storage and networking
[09:06] <dimitern> I'll still need to do a live test later though
[09:12] <dimitern> TheMue, I'm in the hangout
[09:12] <TheMue> dimitern: coming
[09:38] <dimitern> axw, katco, jam, wallyworld, is anyone using the shared aws account for testing now?
[09:38] <dimitern> I'm thinking of cleaning up the stale VPCs, subnets, security groups, etc.
[09:39] <dimitern> unless anyone responds in the next half hour, I'll go ahead and do it
[09:48] <perrito666> dimitern: for me go for it
[09:49] <dimitern> perrito666, +1
[10:11] <jam> dimitern: I'm using eu-west-1 for a live service
[10:11] <jam> (my IRC proxy)
[10:11] <jam> but nothing in US-east-1
[10:11] <dimitern> jam, ok
[10:41] <wallyworld> dimitern: sorry, had to go down to soccer at short notice
[10:42] <dimitern> wallyworld, np. s'all good :)
[10:42] <wallyworld> dimitern: once you're happy with goaws, I'll land a branch to update core
[10:43] <dimitern> wallyworld, I still need to do a live test, so I'll let you know; but looking at the code it should work
[10:43] <wallyworld> ok, sounds good
[10:43] <wallyworld> i did a storage live test and it was good too
[10:44] <dimitern> wallyworld, cool!
[10:59] <perrito666> morning
[11:04] <dimitern> FYI all leftovers in the shared aws account where cleaned up for all regions (jam's instance is unaffected ofc)
[11:05] <dimitern> we should have a script to do that
[11:08] <TheMue> perrito666: o/
[11:35] <dooferlad> dimitern: hangout?
[11:40] <dimitern> dooferlad, omw, sorry
[11:40] <dooferlad> dimitern: no worries!
[11:42] <dimitern> dooferlad, i'm in the hangout btw
[13:11] <mup> Bug #1427204 was filed: systemd service tests map ordering failures <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1427204>
[13:15] <mup> Bug #1427210 was filed: 'relative path in ExecStart not valid' vivid local deploy failure <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1427210>
[13:16] <mgz> I have filed that one as a blocker, not the map ordering test failures though
[13:16] <mgz> will poke eric when he's on about 'em
[13:30] <dimitern> dooferlad, ping
[13:31] <dooferlad> dimitern: hi
[13:31] <dimitern> dooferlad, I knew it there will be a ci bug reported for that map ordering thing ^^
[13:31] <dimitern> dooferlad, how's that going ?
[13:32] <dooferlad> dimitern: it is happening...
[13:33] <dimitern> dooferlad, did you file a bug? that 1427204 one above should be a duplicate of yours
[13:33] <dooferlad> dimitern: I did.
[13:33] <dooferlad> https://bugs.launchpad.net/juju/+bug/1427149
[13:33] <mup> Bug #1427149: Tests require predictable map ordering <pyjuju:New for dooferlad> <https://launchpad.net/bugs/1427149>
[13:34] <dooferlad> bother, wrong project
[13:34] <mup> Bug #1427149 was filed: Tests require predictable map ordering <juju-core:New for dooferlad> <https://launchpad.net/bugs/1427149>
[13:35] <dimitern> dooferlad, it's the right one I think
[13:35] <dooferlad> dimitern: it is now.
[13:35] <mup> Bug #1427204 changed: systemd service tests map ordering failures <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1427204>
[13:35] <dimitern> dooferlad, ah, ok
[13:36] <dimitern> mgz, dooferlad is already on the map ordering one, so I'll mark the 1427204 as dupe
[13:36] <dooferlad> dimitern: already have
[13:36] <dimitern> dooferlad, yeah, I was just about to say that :)
[13:38] <mgz> ah, pyjuju, is why I didn't see it
[13:56] <dimitern> TheMue, you have a review btw
[13:56] <TheMue> dimitern: great, thank you
[14:00] <mgz> dooferlad: forgot to check with you, you also get the four failures in service/systemd right? the StubCall one is a bit hard to parse but I assume is also map-related rather than something else
[14:01] <dooferlad> mgz: yes
[14:03] <dimitern> axw, are you there by any chance?
[14:04] <dimitern> wallyworld__, ping
[14:04] <wallyworld__> yo
[14:04] <dimitern> wallyworld__, so the goamz live tests pass (so far) except for this - http://paste.ubuntu.com/10501880/
[14:05] <dimitern> wallyworld__, which looks like the check needs .* before and after
[14:05] <wallyworld__> hmmm, ok, i thought it passed before, maybe not
[14:07] <dimitern> wallyworld__, but the networking stuff seems unbroken
[14:07] <wallyworld__> so do you have any pending changes to commit to goamz?
[14:07] <dimitern> wallyworld__, not right now (I have some I'll do later, but not code related)
[14:08] <wallyworld__> ok, i'll fix that test
[14:09] <dimitern> wallyworld__, cheers
[14:10] <wallyworld__> dimitern: i just ran that test with --amazon and it passed for me
[14:11] <wallyworld__> maybe it fails when run with other tests
[14:11] <dimitern> wallyworld__, "--" instead of "-" ?
[14:11] <wallyworld__> it complained tht it wanted ec creds
[14:11] <wallyworld__> let me try again
[14:12] <dimitern> wallyworld__, it should take a few minutes - if it passes in a few seconds only the local live tests were run
[14:12] <wallyworld__> even for one test
[14:12] <wallyworld__> maybe gocheck.f messes with the flag
[14:13] <dimitern> depends on the test
[14:13] <dimitern> it shouldn't
[14:13] <wallyworld__> i ran go test -gocheck.f TestBlockDeviceMappings  -amazon
[14:13] <wallyworld__> maybe -amazon needs to be first
[14:14] <wallyworld__> still passes
[14:14] <dimitern> I run go test -check.v -check.f TestBlockDeviceMappings -amazon and it passed
[14:15] <wallyworld__> ok, trying ./...
[14:15] <dimitern> so it could be flaky
[14:24] <wallyworld__> dimitern: i got 5 vpc related failures but no block ones
[14:25] <wallyworld__> so yeah, looks flakey
[14:29] <dimitern> wallyworld__, I'll have a look
[14:31] <wallyworld__> dimitern: i think though the latest goamz rev is good to use with juju core
[14:31] <dimitern> wallyworld__, I agree
[14:35] <wallyworld__> dimitern: this should do it - it's what i've tested live juju deployments with http://reviews.vapour.ws/r/1046/
[14:35] <rick_h_> dimitern: just heads up https://bugs.launchpad.net/juju-deployer/+bug/1421315 confirms it's between beta 3 and 4
[14:35] <mup> Bug #1421315: subordinate service not appearing in watch output <oil> <juju-core:Triaged> <juju-deployer:Triaged by hazmat> <https://launchpad.net/bugs/1421315>
[14:37] <dimitern> rick_h_, good to know - it makes it easier to track, thanks
[14:38] <rick_h_> sinzui: can we get ^ marked as a beta regression then and a blocker for release?
[14:40] <sinzui> rick_h_, you mean 1.22-beta4 is broken and we need a 1.22-beta5
[14:40] <hazmat> sinzui: yes
[14:40] <sinzui> thank you
[14:40] <rick_h_> sinzui: yes please
[14:40] <rick_h_> sinzui: and we can help QA and verify that beta5 fixes the issue before release
[14:41] <rick_h_> sinzui: vs the current medium status on the bug
[14:41] <hazmat> sinzui: any public info i can watch to track the status of deployer in core qa?
[14:42] <sinzui> hazmat, no, sorry, but after my meeting, I will be able to report where we are with deployer revision testing
[14:42] <hazmat> sinzui: thanks
[14:49] <wallyworld__> dimitern: i need sleep, if you are happy with the goamz update to core, can you $$merge$$ it for me?
[14:51] <dimitern> wallyworld__, will do, np
[14:51] <wallyworld__> ty
[15:04] <dimitern> ericsnow, hey
[15:04] <dimitern> ericsnow, can you take care of this bug please? https://bugs.launchpad.net/juju-core/+bug/1427210
[15:04] <mup> Bug #1427210: 'relative path in ExecStart not valid' vivid local deploy failure <ci> <local-provider> <lxc> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1427210>
[15:05] <ericsnow> dimitern: yep
[15:05] <ericsnow> dimitern: first on my list :)
[15:05] <dimitern> ericsnow, cheers :)
[15:05] <ericsnow> perrito666: standup?
[15:05] <dimitern> ericsnow, the other one - with the map ordering dooferlad is already fixing and I asked him to check in with you when done
[15:07] <rick_h_> jrwren: can you help dimitern https://bugs.launchpad.net/bugs/1421315 with the steps you used to reproduce please?
[15:07] <mup> Bug #1421315: subordinate service not appearing in watch output <api> <juju-gui> <oil> <regression> <juju-core:Triaged> <juju-core 1.22:Triaged> <juju-deployer:Triaged by hazmat> <https://launchpad.net/bugs/1421315>
[15:07] <rick_h_> jrwren: if you have the websocket frames in a pastebin/etc even sweeter
[15:18] <jrwren> rick_h_: I have the websocket frames in a screenshot. I'll share doc.
[15:18] <rick_h_> jrwren: ty
[15:28] <dimitern> jrwren, rick_h_, thanks for sharing the document, but this still doesn't show the issue
[15:29] <rick_h_> jrwren: I'm not seeing the beta4 screenshot
[15:30] <rick_h_> dimitern: basically the images highlight how the allwatcher sent the info about the nrpe charm in the watcher output
[15:30] <rick_h_> dimitern: and in beta4 that is no longer sent
[15:31] <dimitern> rick_h_, sorry, but I'd rather have logs I can search in than a screenshot of half a log
[15:32] <rick_h_> dimitern: right, understand. It was the easiest way I could mention jrwren to QA it as I know how to watch the allwatcher from the websocket the gui manages so this is from a browser session of watcher events
[15:32] <dimitern> rick_h_, ok, it will be great if those dumps are available somewhere as well
[15:33] <dimitern> jrwren, ^^
[15:33] <perrito666> ericsnow: I assumed standup was postponed
[15:34] <ericsnow> perrito666: k
[15:35] <ericsnow> perrito666: ah, I missed Nate's email :)
[15:36] <jrwren> rick_h_: I didn't add beta4 screenshot as it is identical to the others.
[15:37] <jrwren> dimitern: Yes, doesn't show the issue. Still trying to repro.
[15:37] <dimitern> jrwren, ah, sorry I though you already did
[15:38] <jrwren> dimitern: No, I'm guessing this regression is only in master. I've not built master yet, so I cannot confirm.
[15:39] <jrwren> dimitern: It is not in any released version that I've tested, and I've tested all current released versions AFAIK
[15:39] <dimitern> jrwren, not even in 1.22-beta4? that was proposed for release
[15:39] <jrwren> dimitern: this morning i confirmed it is not in 1.22-beta4
[15:40] <dimitern> jrwren, ok
[15:41] <dimitern> rick_h_, ^^
[15:41] <jrwren> dimitern: ugh. Typo in my lp comment. I added another comment.
[15:41] <dimitern> jrwren, no worries, thanks for clarifying
[15:42] <rick_h_> jrwren: oh, important typo lol
[15:43] <rick_h_> jrwren: dimitern ok, so we need to check with the original bug author and confirm what juju he's using
[15:44] <rick_h_> jrwren: dimitern because I'm doubting he's building trunk?
[15:44] <rick_h_> hazmat: did you replicate the subordinate bug and if so on which version of juju? ^
[15:45] <TheMue> dimitern: have you done the live testing? I now have an interesting race condition in state/action_test.go:374
[15:45] <hazmat> rick_h_: i didn't, i just read the log output of deployer, its deployed a subordinate, service waited 5s, and does a watch, and the sub isn't in the output
[15:46] <rick_h_> hazmat: ok, ty.
[15:47] <mup> Bug #1427257 was filed: Juju backup doesn't contain .juju files <juju-core:New> <https://launchpad.net/bugs/1427257>
[15:47] <rick_h_> so might be more a race/timing issue where we didn't replicate that with the gui because we weren't checking the time there.
[15:48] <TheMue> dimitern: if I run the state tests directly in my VM they pass, but when doing it via ssh this test above fails
[15:48] <dimitern> TheMue, I'm doing it now
[15:52] <dimitern> TheMue, what do you mean via ssh?
[15:53] <TheMue> dimitern: I've got a VM running my test system in. when I go in directly it passes. but from inside the editor on the host system I can do a "ssh<EMAIL_ADDRESS>'~/bin/jdt test state'"
[15:54] <TheMue> dimitern: here jdt is the script I told you about
[15:54] <TheMue> dimitern: inside the VM I'm simply doing a "jdt test state", so that's not the reason
[15:55] <TheMue> dimitern: I think the output via SSH back to the editor slows the tests a bit down and that's why the behavior here is different from doing it directly
[15:55] <dimitern> TheMue, could be something ssh-related - try using -v
[15:56] <TheMue> dimitern: will do
[15:59] <TheMue> dimitern: same result. so would be interesting how testing state passed for you
[15:59] <TheMue> dimitern: the latest changes here only have been the comments like in the review
[16:00] <alexisb> rick_h_, I am confused by the comments in lp 1421315
[16:01] <alexisb> it is marked as critical but is not broken in 1.22-beta4?
[16:01] <rick_h_> alexisb: heh you and me both. Sorry, our guy said he confirmed it but then found out it was not true
[16:01] <alexisb> dimitern, rick_h_ am I reading something wrong?
[16:01] <rick_h_> alexisb: so in between we had it run up the flag pole as a breakage in beta4
[16:01] <alexisb> in the lsat 15 minutes :)
[16:01] <rick_h_> alexisb: yep
[16:01] <alexisb> it is going to be a fun monday
[16:01] <rick_h_> alexisb: so now we're working it out and reevaluating atm
[16:01] <alexisb> hazmat, as always thanks for your help
[16:02] <dimitern> alexisb, not more than I am I guess :)
[16:02] <alexisb> rick_h_, ack, just keep the bug updated and we will stay on it
[16:02] <alexisb> but at this point I am not sure what our next step is given the information :)
[16:02] <rick_h_> alexisb: will do, standup atm and will bring it up and update
[16:02] <alexisb> thnx
[16:03] <hazmat> rick_h_: yeah.. if it its not reconfirmed, then not sure.. i'm basically booked for the next 36 hrs re trying to reproduce myself, might want to reach out to the oil guys
[16:05] <dimitern> TheMue, good news
[16:05] <dimitern> TheMue, so far I couldn't manage to reproduce the issue with your fix
[16:05] <TheMue> dimitern: aaaaaah
[16:05] <TheMue> dimitern: \o/
[16:09] <dimitern> TheMue, yep, so far so good, now I'm retrying the same steps without your fix
[16:09] <TheMue> dimitern: interested in the results
[16:13] <dooferlad> dimitern / TheMue: I need some inspiration with how to fix a test. Can either of you jump in a hangout for a while?
[16:13] <perrito666> mm, these automated travel services would be so much better if you could specify an arrival date instead of departure
[16:13] <dimitern> dooferlad, sure, just give me 2m
[16:13] <TheMue> dooferlad: sure
[16:14] <dooferlad> dimitern, TheMue: Thanks guys.
[16:14] <dooferlad> dimitern, TheMue: The usual one that we use for the standup?
[16:15] <TheMue> dooferlad: would say so
[16:16] <dimitern> TheMue, confirmed!
[16:16] <dimitern> TheMue, I managed to reproduce the issue on 1.22 without your fix
[16:16] <TheMue> dimitern: fantastic
[16:37] <dimitern> TheMue, you have LGTM
[16:37] <TheMue> dimitern: great, thx, port it to 1.23 then
[16:37] <dimitern> TheMue, +1
[17:00] <perrito666> so natefinch back?
[17:01] <natefinch> perrito666: yep
[17:02] <perrito666> so ericsnow natefinch wwitzel3  do we staandup or that already happened?
[17:02] <natefinch> perrito666: we can do that now if they're available
[17:02] <ericsnow> natefinch: sure
[17:03]  * perrito666 took the 2 hs thing literally
[17:03] <natefinch> perrito666: haha
[17:03] <natefinch> perrito666: I'm rarely that exact :)
[17:21] <mup> Bug #1427302 was filed: failed to retrieve the template to clone: lxc container 1.21.3 <oil> <juju-core:New> <https://launchpad.net/bugs/1427302>
[17:22] <dooferlad> dimitern: https://github.com/juju/juju/compare/master...dooferlad:master-map-ordering-tests?expand=1
[17:25] <dimitern> dooferlad, this looks good to me - go ahead and propose it and ask ericsnow to have a look please
[17:26] <dooferlad> dimitern: I need to stop for the day in a moment, so I will propose, but if it needs to land today someone else may have to $$prod$$ on github
[17:27] <dimitern> dooferlad, sure, that's ok
[17:27] <dooferlad> dimitern: I am seeing some failures in environs/manual, but I don't know if they are related.
[17:27] <dimitern> dooferlad, paste?
[17:28] <dooferlad> dimitern: http://pastebin.ubuntu.com/10503991/
[17:29] <dimitern> dooferlad, no I don't believe these are related
[17:31] <dooferlad> dimitern, ericsnow: http://reviews.vapour.ws/r/1048/ (should) fix bug #1427149
[17:31] <mup> Bug #1427149: Tests require predictable map ordering <ci> <regression> <test-failure> <juju-core:In Progress by dooferlad> <https://launchpad.net/bugs/1427149>
[17:31]  * ericsnow is looking
[17:32] <dooferlad> dimitern: I will keep an eye on my email, but assume no fast response until tomorrow. Have a good evening!
[17:32] <dimitern> dooferlad, cheers, same to you!
[17:57] <lazyPower> !QUESTION: Why does the local.jenv file have multiple entries for the state server "localhost" and "<IP_ADDRESS>" (by default) - why not just use the <IP_ADDRESS> address? is this something to work around the snowflakeness of the local provider?
[17:57] <mup> lazyPower: In-com-pre-hen-si-ble-ness.
[17:57] <lazyPower> mup: botsnack
[17:57] <mup> lazyPower: Roses are red, violets are blue, and I don't understand what you just said.
[18:08] <TheMue> Would like a review of http://reviews.vapour.ws/r/1050/. It's the port of fix #1425435 from 1.22 to master.
[18:08] <mup> Bug #1425435: juju-deployer/jujuclient incompatibility with 1.21.3 <api> <cts> <network> <oil> <openstack> <orange-box> <regression> <uosci> <juju-core:Triaged> <juju-core 1.22:Triaged by themue> <juju-core 1.23:Triaged> <https://launchpad.net/bugs/1425435>
[18:08] <ericsnow> dooferlad: done
[18:09] <dimitern> lazyPower, 1) it is; 2) because localhost is special in case of ipv4 vs ipv6
[18:09] <lazyPower> aahhh ok ty for the explanation
[18:09] <dimitern> :)
[18:09] <ericsnow> dimitern: I have a patch up for lp-1427210: http://reviews.vapour.ws/r/1047/
[18:09] <dimitern> ericsnow, looking
[18:10] <ericsnow> dimitern: thanks
[18:12] <cory_fu> dimitern: Fair enough about localhost working across IPv4 and IPv6, but couldn't that be handled when the .jenv file is created?  Or is there some other specialness that I'm unaware of?
[18:13] <dimitern> cory_fu, I suppose it can
[18:14] <cory_fu> dimitern: The use-case I'm investigating is attempting to connect to an already bootstrapped local provider from within a container, for review and CI.  I was able to get juju status to work (briefly) by removing the localhost entry, but the .jenv file gets re-written periodically which re-adds the localhost entry
[18:15] <dimitern> ericsnow, reviewed
[18:15] <ericsnow> dimitern: thanks
[18:16] <dimitern> cory_fu, that's because the local provider insists on reporting localhost as one of its endpoints
[18:16] <TheMue> dimitern: the ported fix is available for review too
[18:16] <dimitern> cory_fu, I can't quite recall why, but there was some other good reason - ask thumper
[18:16] <dimitern> TheMue, cheers, will have a look
[18:17] <TheMue> dimitern: great, thanks
[18:18] <mup> Bug #1427302 changed: failed to retrieve the template to clone: lxc container 1.21.3 <oil> <juju-core:New> <https://launchpad.net/bugs/1427302>
[18:21] <mup> Bug #1427302 was filed: failed to retrieve the template to clone: lxc container 1.21.3 <oil> <juju-core:New> <https://launchpad.net/bugs/1427302>
[18:29] <mup> Bug #1427302 changed: failed to retrieve the template to clone: lxc container 1.21.3 <oil> <juju-core:New> <https://launchpad.net/bugs/1427302>
[18:36] <TheMue> dimitern: seen your review, thx already
[18:36] <dimitern> TheMue, np :)
[18:49] <mup> Bug #1427342 was filed: juju package should have strict version dep with juju-core <juju-core:New> <https://launchpad.net/bugs/1427342>
[19:03] <sinzui> natefinch, dimitern, someone landed a change to 1.22 without first landing 1.22-beta5 version. CI knows the version is released
[19:04] <sinzui> natefinch, dimitern I am trying to merge the 1.22-beta5 branch to satisfy CI
[19:05] <natefinch> sinzui: are you saying no code should have been landed before the 1.22-beta5 tag was created?
[19:06] <sinzui> natefinch, CI will not test a version of juju that tries to mutate the agents that are released.
[19:07] <sinzui> natefinch, The branch that incremented juju to beta5 hadn't merged, so CI blocked testing of the last merge to 1.22
[19:08] <natefinch> sinzui: oh, I see what you mean - we have to change the actual files to create a new release number, as well as creating the tag in git... and we hadn't made the change to the files yet.
[19:08] <sinzui> natefinch, dimitern : I am bringing this up because it isn't clear from the failure email sent to the list why publish-revision failed
[19:08] <sinzui> I am fixing it. nothing for your team o do
[19:09] <natefinch> sinzui: ok
[19:09] <sinzui> we will retest in about 15 minutes
[19:16] <natefinch> TheMue: you around?
[19:29] <TheMue> natefinch: yep
[19:34] <natefinch> TheMue: how's the train from Munich to Nuremberg?  I'm considering just flying into Munich, since most of my flights go through there anyway
[19:35] <TheMue> natefinch: should be very good, it's near and Nuremberg-Munich are on the ICE route. the ICE is the fastest train in Germany.
[19:35] <TheMue> natefinch: I'll take it too, but from north. ;)
[19:36] <natefinch> TheMue: nice.  Do you know if you have to book ahead of time, or can you basically walk up and buy a ticket?
[19:38] <TheMue> natefinch: normally you can buy directly at the railway station. only if you want to make sure getting a good seat you'll have to book ahead of time
[19:38] <natefinch> TheMue: cool.
[19:40] <TheMue> natefinch: time is between 2 and 2:30, depending on the exact trains
[19:41] <TheMue> natefinch: sadly Munich Central Station is 40 mins away from the airport
[19:42] <natefinch> TheMue: oh, hmm
[19:42] <natefinch> TheMue: that's unfortunate
[19:42] <natefinch> TheMue: that might make my decision for me, then
[19:43] <TheMue> natefinch: yep
[19:43] <sinzui> hazmat, we expect CI to test deployer along with quickstart starting Thursday
[19:44] <TheMue> natefinch: is their a flight from Amsterdam to Nuremberg? or Heathrow? then this may be better.
[19:44] <hazmat> sinzui: cool, thanks for the update
[19:46] <natefinch> TheMue: looks like most flights want to take me to munich or frankfurt, and then a tiny airplane to nuremberg...   amsterdam or zurich are other possible stops... but they end up being a little longer
[19:47] <natefinch> dang, I was happy with the 8 hour direct flight to Munich :)
[19:47] <TheMue> natefinch: yes, I know, puzzling together the optimal connection isn't very easy.
[20:02] <alexisb> natefinch, ping
[20:09] <thumper> urulama: are you still around?
[20:13] <urulama> thumper: hey. just about to have dinner. will ping you when i'm done :)
[20:14] <thumper> ok
[20:25] <davecheney> thumper:
[20:25] <davecheney> i forgot to ask
[20:25] <davecheney> at the standup
[20:25] <davecheney> what is next with power ?
[20:29] <thumper> davecheney: I need to talk with alexisb about that in my call this morning
[20:30] <davecheney> ok
[20:30] <davecheney> i have the fix as a replacement .deb we can deploy on ppc64 ci machines to get them going
[20:35] <urulama> thumper: back
[20:35] <thumper> urulama: that was quick
[20:35] <thumper> urulama: I'm free for the next 20 minutes
[20:50] <ericsnow> mgz: how do I kick off a run of "local-deploy-vivid-amd64"?
[20:55] <mgz> ericsnow: you mean for a specific branch? or just rerun the last job?
[20:56] <ericsnow> mgz: trying to verify 1427210 is fixed (so job 144)
[20:59] <mgz> ericsnow: it seems to be reliably (twince in the same way) failing with a new error
[20:59] <ericsnow> mgz: k
[21:00] <mgz> conf.Output value "/var/log/juju-jenkins-localdeploy-vivid-amd64/machine-0.log" (Options are syslog) is not valid
[21:00] <ericsnow> mgz: how do I look at the logs?
[21:01] <mgz> ericsnow: it's not yet up on juju-reports so I'm just looking at the job in jenkins, which requires admin/password which can be found is cloud-city
[21:01] <ericsnow> mgz: k
[21:02]  * urulama makes a note to self ... don't talk to thumper :P
[21:02] <thumper> urulama: oh, c'mon
[21:02] <thumper> it wasn't that bad
[21:03] <urulama> you were laughing a lot, yes :D
[21:03] <perrito666> urulama: really? you need a note? I got it in my induction manual
[21:03] <urulama> perrito666: :D
[21:04] <rick_h_> urulama: don't take that from thumper!
[21:04] <rick_h_> urulama: just bring up UX issues until he calls off the phone call
[21:08] <urulama> thumper: fyi, you have +1++ on JES CLI
[21:09] <thumper> awesome
[21:09] <rick_h_> lol
[21:32] <alexisb> thumper, ping
[21:32] <thumper> hey
[21:32] <thumper> coming
[22:29] <ericsnow> could someone take a look at a small patch: http://reviews.vapour.ws/r/1051/
[22:29] <ericsnow> it should unblock CI
[22:31] <menn0> ericsnow: looking
[22:32] <alexisb> wallyworld__, ping
[22:34] <menn0> ericsnow: i'm probably just missing context but why is a command simple when it contains one of the those characters?
[22:35] <ericsnow> menn0: yeah, the condition is reversed (so all those are *not* simple) :)
[22:35] <ericsnow> menn0: I'll fix that
[22:35] <menn0> ericsnow: right, that makes more sense then!
[22:37] <menn0> ericsnow: while you're in there, consider using strings.ContainsAny()
[22:37] <menn0> ericsnow: that would simplify the function somewhat (and make it more efficient)
[22:37] <ericsnow> menn0: sounds good
[22:40] <menn0> ericsnow: initial review done
[22:45] <ericsnow> menn0: thanks
[22:45] <ericsnow> menn0: I've updated the patch
[22:46] <mup> Bug #1403084 changed: Tests that need to be fixed on windows <ci> <tech-debt> <testing> <windows> <juju-core:Fix Released> <https://launchpad.net/bugs/1403084>
[22:48] <sinzui> ericsnow, do you want to claim this bug as in progress or fix committed https://bugs.launchpad.net/juju-core/+bug/1409639
[22:48] <mup> Bug #1409639: juju needs to support systemd for >= vivid <systemd-boot> <juju-core:Triaged> <juju-core (Ubuntu):Triaged> <juju-core (Ubuntu Vivid):Triaged> <https://launchpad.net/bugs/1409639>
[22:48] <ericsnow> sinzui: good point
[22:49] <menn0> ericsnow: re the comment about the error check TODO. where I commented there's no UpdateConfig call. Looks like a copy and paste problem? That TODO appears twice in the PR.
[22:49] <ericsnow> sinzui: I'll updated it
[22:49] <ericsnow> menn0: ah, you're right
[22:54] <menn0> ericsnow: sorry, a couple more little things
[22:55] <ericsnow> menn0: no worries
[22:57] <ericsnow> menn0: fixed
[22:59] <menn0> ericsnow: ship it
[22:59] <ericsnow> menn0: thanks
[23:44] <ericsnow> abentley: are you looking at local-deploy-vivid-amd64?


[11:04] <gommer> weyy
[11:51] <gommer> nos vemos¡¡¡
[16:42] <malitsky> are there any turkish speaker
[17:15] <Eickmeyer> !tu
[17:15] <Eickmeyer> !tr
[17:15] <Eickmeyer> (obs too late)
[18:48] <M_aD> remind me to point gommer to the es channel
[18:49] <Eickmeyer> M_aD: That's done with "!es | ${nick}"
[18:50] <Eickmeyer> In case you didn't know.
[18:50] <M_aD> yep, thanks
[18:50] <themodernist> Any chuck users here that can help me out with a problem?
[18:55] <M_aD> !ask | themodernist
[19:04] <themodernist> I am having a miniaudicle compile error even though all depenencies are installed. Here:  /usr/bin/ld: cannot find -lqscintilla2
[19:16] <Eickmeyer> themodernist: For issues with compiling individual applications, you need to talk to that developer directly. We don't support anything outside of the official repositories or the Ubuntu Studio Backports PPA.
[19:17] <OvenWerks> themodernist: Are you using the qt4 or qt5 version?
[19:18] <themodernist> qt5
[19:18] <OvenWerks> you will likely need libqscintilla2-qt4-dev or libqscintilla2-qt5-dev
[19:19] <OvenWerks> in general for building, you need to have the -dev package of all libs you use
[19:19] <OvenWerks> these packages have the includes that go with the lib.
[19:21] <themodernist> OvenWerks thank you. I will try installing libqscintilla2-qt5-dev


[19:24] <crankharder> can anyone help me figure out why this doesn't respawn if I kill the process spawned on line 11
[19:24] <crankharder> https://gist.github.com/crankharder/0015a8703b7984dc0d2b