[01:11] <hajour> hi AlanBell
[01:14] <hajour> AlanBell,  xchat already trying to get chances done for accessibility things and also for make faster and have ask often for some changes grr cant remember which one anymore .but already half year.and would really appreciate some help to compliance that.for me now already xchat is making irc most accessible for me and i have tried out several
[01:18] <hajour> just wanted to inform you ala
[01:19] <hajour> AlanBell,
[01:20] <MrChrisDruif> hajour; I think AlanBell is asleep or something, as he's grayed out with me, which indicates he's inactive
[01:20] <hajour> well MrChrisDruif  he will read back
[01:20] <MrChrisDruif> :P
[01:21] <hajour> just was remembering me i had promise to tell it
[01:21] <hajour> i had promised the people from xchat i would do that
[01:41] <hajour> goodnight all
[15:15] <mhall119> AlanBell: Pendulum: ping
[16:26] <AlanBell> o/ mhall119
[16:28] <mhall119> AlanBell: probably an unnecessary question now, but if we put the main navigation links for a website in an iframe, does that screw with accessibility?
[16:29] <AlanBell> it might not help :)
[18:54] <charlie-tca> The newest scrollbar change looks easier to use - http://iloveubuntu.net/ayatana-overlay-scrollbars-02-released-orange-borders-and-new-visibility-behavior-natty-testing-ppa
[20:58] <Pendulum> AlanBell: pong
[20:58] <AlanBell> wasn't me
[20:59] <Pendulum> mhall119: pong
[20:59] <Pendulum> oh, wait was answered
[21:00] <mhall119> that's ok
[21:00] <Pendulum> mhall119: how's you?
[21:00] <mhall119> like I said, we'd already decided not to use iframes, so the question was moot
[21:00] <mhall119> Pendulum: doing surprisingly well, no ubuflu for me
[21:00] <mhall119> you?
[21:01] <Pendulum> I was thinking of you all today because we were were at a train museum Q would like
[21:01] <Pendulum> tired
[21:01] <Pendulum> in Baltimore for a week of medical testing
[21:01] <mhall119> I saw your status on FB
[21:01] <mhall119> testing for the same stuff, or different stuff?
[21:02] <Cheri703> side note to Pendulum (Hi :) and there's a u-w meeting :) )
[21:02] <Pendulum> this is all testing to see about what neurosurgery I do/don't need this summer
[21:03] <Pendulum> Cheri703: I got fewer than 6 hours sleep and spent over an hour this morning in testing and this is my first chance to nap. So I think I will miss this one ;-)
[21:04] <Cheri703> Completely understandable!
[21:09] <hajour1> TheMuso, can i pm you?
[21:09] <hajour1> well it also can here
[21:10] <hajour1> i want to ask or you want take over team leadership from speechcontrol or integrate it in orca
[21:10] <hajour1> because i go resign from speechcontrol
[21:12] <hajour1> i can you mail trough mail adresses from contacts i had made on uds after asking the persons or it is ok to give it to you.
[23:25] <TheMuso> hajour1: Thanks for the offer, but I am already pushing myself as to the amount of work I have to do for Ubuntu this cycle, so I will have to politely decline the offer.
[23:38] <hajour1> themuso i wouold apriciate some advice who would be good to give leadership over from speechcontrol .i would apriciate if you would mail me some advice about this
[23:40] <TheMuso> hajour1: I really don't know of anybody I could recommend I'm affraid.
[23:50] <hajour1> mm okey thanks anyway TheMuso


[00:13] <RAOF> kgunn: You rang, m'lud?
[00:20] <kgunn> RAOF: racarr__ was just sayin' that glamor on mir more coupled than he thot & might not lend itself to doing a demo of libreoffice on mir for next week...wondered if you had thots ?
[00:20] <kgunn> not sure how much you've looked at glamor
[00:21] <RAOF> Not a whole lot, although looking at the xf86-video-ati code I thought that the GBM bits were to do with making DRI work rather than 2d.
[00:22] <kgunn> but then we talked about not using glamor...which sounds like on desktop that'd be ok (on mobile, slow)
[00:23] <kgunn> but then there's menus
[00:23] <kgunn> RAOF: so just lookin' for some technical guidance, but my gut thinks go for it w/o glamor and put some work in to get the menus
[00:24] <RAOF> That seems reasonable.
[00:24] <kgunn> but willing to listen to reasons why we should focus on glamor, or not put effort in on menus
[00:24] <RAOF> We don't need glamor for the desktop.
[00:25] <kgunn> i didn't quite understand why "menus are free with galmor"...or am i reading into what Master Carr is saying ?
[00:29] <RAOF> You're reading that into what Master Carr is saying.
[00:29] <RAOF> Menus aren't free; they're the first part of window managment.
[00:29] <RAOF> Which _is_ a bit of a project :)
[00:30] <kgunn> so would that work really be the same w/ & w/o glamor?
[00:33] <RAOF> Yes.
[00:33] <RAOF> Glamor is merely “does it work (with GPU acceleration) on the phone”.
[00:34] <kgunn> right
[00:34] <kgunn> makes sense
[00:36] <RAOF> So one track is “sw-only xf86-video-mir that just uses the Mir API and X's software rendering” → “xf86-video-mir that uses glamor for 2d” → “xf86-video-mir that uses glamor for 2d and supports 3d”
[00:37] <RAOF> Those are all mostly required steps for “fast XMir on the phone”
[00:37] <RAOF> And then there's the “hello, window management” track, which gives you - for example - popup menus that popup in the right place :).
[00:39] <kgunn> ok, tbh, our goal of officelibre on mir is more about unity8 on desktop (not phone)
[00:40] <kgunn> racarr__: ^
[00:42] <kgunn> RAOF: so, i got something i don't understand, trying to debug something using mir_demo_client_egltriangle, so i'm doing the VT1 basic server and VT2 demo on my laptop
[00:42] <RAOF> Ok, sounds good so far.
[00:43] <kgunn> i modify mir_surface.cpp, make install....i even changed the mir_demo_client_egltriangle as to make it update/install as well
[00:43] <kgunn> however...when i run
[00:43] <kgunn> i do not "see the change"
[00:43] <kgunn> from usr/local/bin installs...
[00:43] <kgunn> i have to run the demo client directly from the build folder
[00:43] <kgunn> how come?
[00:44] <RAOF> Well, that's what I do, because /usr/local installs are a *great* way to get extremely surprised in a month's time :)
[00:44] <kgunn> :)
[00:44] <kgunn> ok, so i'll just keep doing that...
[00:44] <kgunn> no problem
[00:44] <kgunn> but is there a reason why ?...i mean i really thot the install would take care
[00:45] <kgunn> also...is there a way to wipe out the local/bin
[00:45] <kgunn> ?
[00:45] <kgunn> to avoid that surprise ?
[00:45] <RAOF> My initial guess as to your problem would be whether or not cmake strips out the RPATH on everything when installing.
[00:45] <RAOF> kgunn: rm -r /usr/local/bin/* ? :)
[00:45] <kgunn> ok...
[00:45]  * RAOF has recently run this, having been surprised by an apitrace install lurking in there.
[00:45] <kgunn> that easy huh
[00:45] <RAOF> Unless you've got something you actually *want* in /usr/local, yeah.
[00:46] <kgunn> cool
[00:46] <RAOF> You might also want to kill /usr/local/lib, because that little gem is *before* /usr/lib in the library search path.
[00:47] <kgunn> yep...researched enough to see that...and its first in my path
[00:48] <racarr__> lol sorry to be confusing about menus
[00:48] <kgunn> racarr__: you weren't...i was playing the board game "Jump to Conclusions"
[00:49] <racarr__> unrelated to glamor :)
[00:49] <racarr__> oh
[00:49] <racarr__> I prefer candyland.
[00:49] <kgunn> lol
[00:49] <AlbertA> kgunn: heh I love those office space references
[00:49] <RAOF> Mmm. Candy mountain!
[00:49] <kgunn> AlbertA: just for you :)
[00:49] <AlbertA> kgunn: I want to file my TPS report now
[00:50] <kgunn> AlbertA: yeah...i'm gonna need you to come in Saturday....yeah...why don't you just plan on coming in Sunday too
[00:50] <racarr__> AlbertA: We're gonna have to ask you to come in to malta on a sunday...
[00:50] <kgunn> lol
[00:50] <AlbertA> evern funnier because we are
[00:50] <AlbertA> haha
[00:50]  * RAOF arrives home Monday morning.
[00:51] <RAOF> (There will not be any RAOF on Monday or Tuesday after the sprint)
[00:51] <AlbertA> RAOF: I guess you didn't get the memo
[00:51] <AlbertA> RAOF: ;)
[00:53] <kgunn> RAOF: you're next movie watching assignment http://www.imdb.com/title/tt0151804/
[01:47] <racarr__> RAOF: Im bored. wanna write an X11 window manager?
[01:47] <RAOF> No, not really :)
[01:47] <racarr__> lol my real question, is how to turn on rootless X.
[01:48] <racarr__> I was thinking I would make input work in rootless (seems like there would be something to do) and maybe try and get some basic
[01:48] <racarr__> infrastructure going.
[01:48] <RAOF> racarr__: I'm currently resurrecting my rootless X thingy, which seems to have been eaten by git.
[01:49] <racarr__> Ah
[01:49] <RAOF> Oh!   The cpu usage thing seems unrelated to mir...
[01:57] <mterry> anpok_, (copying unity8-greeter on top of unity8, then switching greeter code to run unity8 instead makes cpu usage be normal.  So something is inspecting executable names)
[01:58] <mterry> anpok_, but I do still need help on the 'volume up/down presses ignored by android-input layer in greeter' issue...
[02:56] <RAOF> 2nd laptop mode: engage.
[04:07] <RAOF> Dear Google: any email sent to me written in Mandarin is almost certainly spam. kthxbye.
[06:17] <anpok_> yay just finished merging devel and making the unit test non-time-depending in my branch
[06:18] <anpok_> non-time oO
[06:20]  * duflu high-fives anpok_
[06:20] <anpok_> hi
[06:20] <duflu> Hi there
[06:21] <anpok_> so avoid to time dependency in buffer consumption..
[06:22] <anpok_> we might need to consume all occuluded buffers (but not by drawing them :)) and provide expose/occlusion events for displays that got powered of
[06:22] <anpok_> and hope that qt can deal with that
[06:23] <anpok_> *off
[06:23] <duflu> anpok_: Hmm, I had proposed a branch that did just that.
[06:23] <duflu> It got rejected
[06:23] <duflu> Although it's a good idea
[06:23] <anpok_> well you proposed drawing occluded buffers
[06:24] <duflu> anpok_: Different branch
[06:24] <anpok_> oh
[06:24] <anpok_> too many branches...
[06:24] <anpok_> but for this to work we need the client api change ..
[06:25] <duflu> Ah, crap.
[06:25] <anpok_> i mean.. we do not make an occlusion test when the compositor off
[06:25] <anpok_> which we wanted to do anyhow sometime.. maybe today?
[06:29] <RAOF> Well, that looks like _part_ of libreoffice...
[06:31] <anpok_> hm lets see how bzr deals with that
[06:34] <anpok_> duflu: https://bugs.launchpad.net/mir/+bug/1318852 AlbertA is referring to the usage of src_alpha, one_minus_src_alpha as a blending function - which only works when the textures are not premultiplied
[06:35] <anpok_> but which does not cause much trouble because we rarely have transparent client buffers
[06:35] <duflu> anpok_: Depends how often you run "mir_demo_client_egltriangle -b 0" ;)
[06:36] <anpok_> duflu: well and how often do we verify that resulting rgb and a channels are mathematically correct and follow an additive blending model?
[06:37] <RAOF> Also, when are we going to support sRGB alpha? :)
[06:38] <anpok_> duflu: the screencast bug fixed some time ago by applying filters (and I think avoid alpha writes) is caused by the used blending functions
[06:38] <RAOF> Hah!
[06:38] <RAOF> mir_surface_is_valid isn't particularly useful :)
[06:38] <anpok_> we could safely assume premultiplied alpha for any client buffer and used (one, one_minus_src_alpha)
[06:38] <anpok_> RAOF: hm where are you?
[06:39] <duflu> anpok_: I hope you're right. Although I can't yet see how this should produce a fragment with alpha != 1.0 ...
[06:39] <duflu>         glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
[06:39] <RAOF> anpok_: Still in hobart?
[06:40] <anpok_> hm not makeing much sense, libreoffice valid surface?
[06:41] <duflu> RAOF: Oh... mir_surface_is_valid(NULL)  ?
[06:41] <duflu> https://bugs.launchpad.net/mir/+bug/1248474
[06:44] <anpok_> assume you have an opaque background d_r, d_g, d_b, d_a, and blend a window shadow (s_r,s_g,s_b,s_a) above it with, lets assume a pixel s_a= 0.25 then your resulting alpha = s_a*s_a + d_a*(1-s_a) => 1/8 + 1*(3/4) => 7/8
[06:44] <RAOF> duflu: Actually mir_surface_is_valid() for any non-surface :)
[06:44] <duflu> Wow  Oo
[06:44] <duflu> Awesome. Surfaces everywhere!
[06:44] <duflu> It's a new paradigm
[06:45] <anpok_> if you use GL_ONE instead (and make the shadow buffers and window decorations premultiplied)
[06:45] <anpok_> you get -> 1*s_a + d_a(1-s_a)= 1/4 + 3/4 = 1
[06:45] <racarr__> Ah, yes, non surfaces are surfaces, 1=0, I see it all so clearly now...*runs off in to the night*
[06:46] <anpok_> racarr__: see you late
[06:46] <anpok_> r
[06:46] <duflu> racarr__: Consider that a good point to have a drink et al
[06:46] <RAOF> anpok_: Oh, no. I think something is destroying a surface, then X is handling an event that was queued from that surface.
[06:47] <racarr__> Haha, I just got back from the wine bar and was just checking IRC before sleep :)
[06:47] <RAOF> So 0x926158 probably _was_ a valid surface, quite recently.
[06:47] <racarr__> Good indeterminate time all!
[06:47] <RAOF> But now it's a SIGSEGV
[06:47] <RAOF> racarr__: Enjoy post-wine!
[06:47] <duflu> Whee, the handle validation problem
[06:47] <anpok_> racarr__: apply the advanceable clock mp, it is global, but makes you independent on any extern time source
[06:47] <duflu> anpok_: OK, I trust you without stopping to check the math. If you have a superior solution in mind propose away :)
[06:48] <anpok_> duflu: .. maybe i manage today... need to finish my input nightmare
[06:59] <RAOF> BAH!
[06:59] <RAOF> What's nulling mir_win->win?
[07:06] <duflu> RAOF: XMir's still *magic* after all
[07:35] <RAOF> Ah. And the reason why input isn't working is that nothing hooks it up. Oops!
[07:44] <RAOF> Wow. Apart from the bit where I've got the rendering offset and the bit where mir_demo_server_shell has issues with alt-tab, libreoffice is surprisingly usable.
[07:45] <duflu> RAOF: Whoa, that is worthy of celebration/video
[07:45] <RAOF> I think I'll wait until I've got the rendering correctly offset first :)
[07:45] <duflu> RAOF: Bah, Compiz never got that right ;)
[07:46] <RAOF> It got it more right than “big black box between the top-left corner and where the window wants to be”
[07:48] <RAOF> duflu: I'm not sure why you're exposing DPI to clients at all? I thought 100% of what you wanted was correctly-sized decorations, which are done in the server anyway?
[07:49] <duflu> RAOF: Clients need DPI (or something) to know how big to render text/buttons/etc. And particularly if a client is modifying its titlebar, it needs to agree with the server on the scale.
[07:49] <RAOF> Oh, they certainly do eventually.
[07:50] <duflu> But even before that, we want to avoid huge-titlebar-with-tiny-widgets or vice-versa
[07:50] <duflu> Cos then Mir wouldn't be any better than Unity 7 ;)
[07:58]  * duflu still thinks Trevinho is awesome
[10:50] <anpok_> now that the revert of 1hz rendering landed - i guess have to manually merge devel again? Or are we soon reverting the revert again?
[10:57] <alan_g> anpok_: I don't know that we have a plan for 1hz. But what makes this rev different to any other change to devel?
[11:00] <alf_> Saviq: greyback: https://code.launchpad.net/~afrantzis/qtubuntu/fix-1321189/+merge/220613
[11:00] <alf_> Saviq: greyback: please note the lack of extensive testing
[11:00] <greyback> alf_: fix makes sense, that was my hunch anyway
[11:00] <Saviq> alf_, awesome
[11:01] <Saviq> Mirv, can you integrate that into the qtubuntu builds ↑?
[11:01] <Saviq> Mirv, it should fix the rendering issues under Qt 53.
[11:01] <Saviq> 5.3
[11:02] <anpok_> alan_g: it just touches the alarm tests due to some bsr and I have two branches in that area too
[11:02] <anpok_> and i am lazy enough to not like conflicts :)
[11:05] <alan_g> anpok_: I don't see 1hz landing again until we've discussed what went wrong. So plan on your stuff landing before it gets sorted out.
[11:22] <anpok_> alf_: not sure if you read the irc backlog of last night .. i finnally figured out why my clock improvements did not really improve things.
[11:23] <alf_> anpok_: I haven't read it... at what time should I look?
[11:24] <anpok_> oh not important.. 1900 my time .. maybe 2000 yours?
[11:24] <anpok_> short story
[11:24] <anpok_> posting actions on a io_service does not make the io_service reevaluate the pending timers
[11:25] <anpok_> only when I create a new timer it will go and look for a new "now"
[11:29] <Mirv> Saviq: yes
[11:30] <Mirv> Saviq: sounds excellent
[11:30] <Mirv> pushing a build right away
[11:30] <Mirv> Saviq: note that even that your some output Qt 5.3 was actually using OpenGL ES 3.0, but let's see
[11:31] <Mirv> (ES 3.0 is now supported in 5.3)
[13:06] <Mirv> alf_: that was some awesome one-liner
[13:07] <alf_> Mirv: glad it helped :)
[13:56] <mterry> anpok_, did you get my message late last night about the cpu issue with the greeter?
[14:04] <anpok_> mterry: probably not
[14:04] <mterry> anpok_, ok, so I investigated more
[14:04] <anpok_> ah at 3:57
[14:04] <mterry> ah ok
[14:05] <anpok_> and volome up down still an issue
[14:05] <mterry> anpok_, yeah both are still issues, I just know more  :)
[14:05] <anpok_> :)
[14:05] <anpok_> the other one is already erased
[14:06] <mterry> anpok_, volume up/down is interesting.  So it's an android-input issue about focus.  But if I run the greeter as the user shell, it works.  So it's not related to the actual code of the greeter either
[14:06] <mterry> Something about how the greeter environment is set up, versus a user environment apparenlty
[14:06] <anpok_> hm ok i thought it would be a display off -> no focused surface issue or something
[14:07] <mterry> anpok_, the problem appears on first boot even before display off
[14:12] <mterry> Shoot.  Now it's working on my device and I don't know what I did
[14:13] <anpok_> but you DID something?
[14:14] <mterry> anpok_, I've been trying lots of things, but it started working, and after undoing what I did most recently it was still working.  So I must have done something last night and not noticed it worked.  I'm going to work backwards now  :)
[14:14] <anpok_> ok cool all issues erase.. me hurries back into input nightmares
[14:17] <anpok_> you still might have found a bug
[14:17] <mterry> anpok_, heh, no I want you on retainer  :)
[15:00] <anpok_> mterry: meeting the kids -> then I am all yours
[15:00] <anpok_> *then
[15:00] <mterry> ricm:)
[15:00] <mterry> whoops
[15:00] <mterry> :)
[15:00] <anpok_> at least I make you think that :)
[16:07] <AlbertA> kgunn: alf: so I flashed a fresh image
[16:07] <AlbertA> kgunn: alf: with the current solution (buffer consuming thread) I still see a probably one frame flash
[16:07] <AlbertA> of old content
[16:08] <alf_> AlbertA: sure, it depends how fast you do it :)
[16:09] <AlbertA> kgunn: alf: with 1Hz branch but set to 20Hz timeout I always see it...
[16:10] <AlbertA> kgunn: alf_: I wonder why
[16:10] <kgunn> like alf_ said, doesn't it depend on how fast you do it ?
[16:11] <AlbertA> kgunn: I mean in the 20Hz case, it doesn't matter how slow you do it
[16:11] <AlbertA> kgunn: 30 seconds later, it still flashes the one frame
[16:12] <kgunn> AlbertA: oh wait...so, you're cutting the compositor out of the chain in this method right
[16:12] <kgunn> so we
[16:12] <kgunn> have left the frames we dumped in there...
[16:12] <AlbertA> kgunn: right only framedropping
[16:12] <kgunn> just prior to turning off
[16:12] <kgunn> so those are what you see
[16:12] <AlbertA> kgunn: alf_: but that should be similar in the buffer consuming compositor too...I would think
[16:13] <kgunn> AlbertA: i didn't think so...cause buffer consuming compositor actually rendered to the "display"
[16:13] <kgunn> so they're gone
[16:13] <AlbertA> kgunn: I suppose the difference is
[16:14] <AlbertA> kgunn: it advances the compositor buffer
[16:14] <AlbertA> kgunn: and in framedropping it doesn't
[16:16] <kgunn> exactly
[16:22] <kgunn> dednick: can you retarget https://code.launchpad.net/~nick-dedekind/unity-mir/trusted-sessions/+merge/210775 to unity-mir/devel ?
[16:22] <kgunn> then i can put it in an existing silo
[16:22] <kgunn> with https://code.launchpad.net/~mir-team/unity-mir/mir-0.2.0-compatibility-changes/+merge/218734
[16:22] <kgunn> AlbertA: or should we just merge https://code.launchpad.net/~mir-team/unity-mir/mir-0.2.0-compatibility-changes/+merge/218734
[16:23] <kgunn> into unity-mir/devel...
[16:23] <kgunn> and MP unity-mir/devel to unity-mir trunk >
[16:23] <kgunn> ?
[16:23]  * kgunn goes to grab sandwich
[16:23] <AlbertA> kgunn: yeah merge, if unity-mir/devel => means track mir changes it makes sense
[16:25] <kgunn> dednick: nvmd :)
[16:25] <kgunn> AlbertA: yes it does
[16:25] <dednick> kgunn: huh? :)
[16:26] <kgunn> lol...go back to trusted sessioning
[16:55] <kdub_> AlbertA, camako: duflu asked for a resubmit on https://code.launchpad.net/~kdub/mir/overlay-gl-program/+merge/220690, so if you could take a look over again, I'd appreciate it :)
[16:55] <camako> kdub_, will do
[16:59] <AlbertA> kdub_:sure
[17:47] <ogra_> moop
[17:47] <kgunn> ogra_: yep, waiting on jdstrand
[17:47] <ogra_> yeah
[17:47] <kgunn> oh crap i gotta run...bbiab
[17:48] <kgunn> AlbertA: can help with the discussion ogra_
[17:48] <AlbertA> ?
[17:48] <jdstrand> ogra_: do you still have /tmp/mir_socket too?
[17:49] <ogra_> yes
[17:50] <jdstrand> kgunn: so, there should be two sockets. one for the root process and one for the session. the one for the session has been correctly moved to XDG_RUNTIME_DIR aiui. why is the root one in /tmp? can't it go in /run/mir or something?
[17:53] <ogra_> jdstrand, kgunn had to run and pointed to AlbertA ... i guess we need to summmarize for him
[17:53] <ogra_> AlbertA, so according to the landings 0.1.9 should hav abstracted the socket name for mir_socket but we still see mir_socket for system-compositor as well as the session Mir
[17:53] <ogra_> and both even with 666 permissions
[17:53] <ogra_> seemingly https://code.launchpad.net/~mir-team/mir/utopic r1185 was supposed to change that
[17:53] <ogra_> but it looks like it didnt
[17:53] <ogra_> (teh secutity team would like to have abstract socket names ... jdstrand can probably elaborate)
[17:53] <jdstrand> kgunn: plus, why is /tmp/mir_socket writable by world?
[17:53] <jdstrand> ah, I missed that he ran
[17:54] <jdstrand> so, /tmp/mir_socket is 777 and /run/user/32011/mir_socket is 775
[17:55] <jdstrand> if we are using a named socket, I would expect 700 for both and /tmp/mir_socket to be in fome root owned directory (eg /run/mir)
[17:55] <jdstrand> s/fome/some/
[17:56] <ogra_> i think the session needs to be able to talk to it
[17:56] <ogra_> not sure about the architecture here though
[17:57] <jdstrand> if so, then still could use a root-owned dir
[17:57] <jdstrand> the one in /run seems to lenient though
[17:58] <AlbertA> ogra_: we decided not to go for abstract socket names since the security team said at the time apparmor did not mediate them
[17:58] <jdstrand> too*
[17:58] <jdstrand> ah, well, that will be this cycle
[17:58] <jdstrand> jj has most of it ready
[17:59] <jdstrand> AlbertA: ok, what about 775 for the one in XDG_RUNTIME_DIR? could that be 700?
[17:59] <ogra_> jdstrand, does that matter ? the dir is already 700
[17:59] <jdstrand> actually, that doesn't really matter, /run/user/32011 is 700
[17:59] <alan_g> Shouldn't the filesystem endpoint be suppressed on the system compositor anyway?
[17:59] <ogra_> :)
[18:00]  * ogra_ thinks the session socket is all fine ... but the system one looks worrying
[18:00] <AlbertA> jdstrand: at least a group no?
[18:00] <jdstrand> AlbertA: ok, so, the perms on the one in XDG_RUNTIME_DIR are weird, but not a security issue since a parent dir is 700. could we move /tmp/mir_socket to /run/mir (or something-- some root-owned dir)?
[18:00] <AlbertA> jdstrand: because we need mir clients to be able to connect to it
[18:03] <jdstrand> AlbertA: if you need the root owned socket to be 777, that's fine, but can it be put in a non worldwritable directory?
[18:03] <AlbertA> alan_g | EOD: but then how do you get the fd to connect to?
[18:03] <jdstrand> /run/mir_socket would even be fine
[18:04] <AlbertA> jdstrand: not sure who makes it 777...I suppose unity-system-compositor is changing the perms
[18:04] <ogra_> but can user processes then write to it ?
[18:04] <ogra_> sounds like that is needed
[18:04] <AlbertA> jdstrand: but sure it doesn't have to be /tmp
[18:05] <AlbertA> ogra_: the way I see it
[18:05] <AlbertA> ogra_: the nested mir server (unity8 process) needs to talk to it...so that could just be a group permission
[18:05] <ogra_> which the user is in
[18:06] <ogra_> which in turn makes it fully user writable
[18:06] <jdstrand> it may not necessarily be a security issue depending on how it opens the file and handles failure modes correctly. but putting it in /run makes sure it won't ever be
[18:07]  * jdstrand notes that confined apps cannot connect to /tmp/mir_socket now, nor /run/mir_socket. they do have access to /run/user/32011/mir_socket
[18:07] <ogra_> but in the split greeter world also the greeter needs to be in that group ... (the lightdm user) ... not sure what the security implications of that are
[18:08] <AlbertA> ogra_: in any case the socket file name/path is configurable so it just a matter of setting the right option when launching unity-system-compositor
[18:08] <ogra_> right
[18:08] <ogra_> mterry, ^^^
[18:08] <ogra_> can lightdm start u-s-c with a socket in a root owned dir ?
[18:09] <ogra_> instead of tmp ?
[18:09] <mterry> ogra_, so we need a world-accessible place for tjhe USC socket?
[18:09] <ogra_> well, jdstrand would like to see it in /run
[18:09] <mterry> ogra_, yeah, but the client sessions need to be able to access it
[18:09] <jdstrand> I would be surprised if it didn't work...
[18:10] <mterry> ogra_, both lightdm and USC are run as root, so I don't see a problem then
[18:11] <ogra_> hmm, where do we set the var currently ...
[18:11]  * ogra_ cant find it in usc-wrapper or ubuntu-touch-session
[18:12] <ogra_> i know we had $MIR_SOCKET once
[18:12] <ogra_> or is that dead
[18:14] <jdstrand> fyi, when we have abstract socket mediation in apparmor it opens the possibility to lock this down even more (eg, should be able to disallow any connections from unconfined and only allow connections from a particularly confined process-- eg, the session compositor)
[18:14] <jdstrand> we don't have to do that now or anything, just saying
[18:21] <AlbertA> ogra_: it's MIR_SERVER_FILE
[18:21] <ogra_> AlbertA, right, but i dont see it being set anywhere .. we used to export that var in one of the start scripts before
[18:21] <AlbertA> ogra_: ah I see
[18:22] <ogra_> (not a  Mir thing :) )
[18:27] <jdstrand> ogra_: so, it being in /tmp isn't a mir thing? I just did 'stop lightdm ; touch /tmp/mir_socket ; start lightdm' and was able to prevent lightdm from starting
[18:28] <ogra_> jdstrand, no that var isnt a mir thing
[18:29] <ogra_> jdstrand, ignore that ... i was looking at bending the var to make it use /run for a test
[18:29] <ogra_> but i cant find where we set it anymore
[18:29] <jdstrand> I'd like to file a bug, but don't know where...
[18:30] <ogra_> unity-system-compositor creates the socket on startup now i think
[18:31] <jdstrand> http://ubuntu-codesearch.surgut.co.uk/ didn't help me
[18:32] <jdstrand> ./src/system_compositor.cpp:        return the_options()->get("file", "/tmp/mir_socket");
[18:32] <jdstrand> (unity-system-compositor)
[18:33] <ogra_> yeah
[18:34] <AlbertA> ogra_: yes if it's not set, mir will create a default socket in /tmp/mir_socket
[18:34] <AlbertA> I mean if MIR_SERVER_FILE is not set
[18:34] <ogra_> right
[18:37] <jdstrand> fyi, bug #1322300
[18:37] <jdstrand> perhaps that should be retargeted to mir. feel free to do so
[18:38] <jdstrand> AlbertA: is the protocol for talking to the mir_socket defined somewhere?
[18:39] <AlbertA> yeah in mir
[18:39] <AlbertA> jdstrand: it's essentially google protobuf messages over the socket
[18:42] <jdstrand> thanks
[19:02] <kgunn> AlbertA: thanks, sorry had to run...back now, read the scrollback...so end result is to change /tmp/mir_socket default in mir? or in usc ?
[19:02] <AlbertA> kgunn: usc
[19:02] <kgunn> via MIR_SERVER_FILE got it
[19:07] <jdstrand> kgunn: not sure if you saw it, but I filed bug #1322300
[19:08] <kgunn> jdstrand: yep...
[19:08] <kgunn> just makin' sure i understood...if we were fixing it in usc or in mir
[19:25] <kgunn> mterry: meant to follow up with you and anpok_ , did you guys have luck in determining where the high cpu load was coming ?
[19:25] <kgunn> (and mem?)
[19:26] <mterry> kgunn, no...  anpok_ pointed me at ricmm who said we have some code to disable sensors for unity8 (which may be related because sensors also take high CPU in this case), but didn't mention where.  I've been distracted by the volume button bug in meantime though
[19:33] <mterry> kgunn, I'm trying to follow up with ricmm, but maybe he's EOD or something
[19:33] <ogra_> mterry, he's sick
[19:34] <mterry> ogra_, oh poor guy
[19:34] <ogra_> he was around for a split second from his rrom earlier
[19:35] <jdstrand> kgunn: I think the priority is higher than Opinion fwiw
[19:36] <jdstrand> it is perhaps 'low' in practice, but I can easily prevent mir from starting without privs if I can create a file in /tmp before mir starts
[19:36] <anpok_> re
[19:59]  * kdub_ grumbles about our recomposite signalling
[20:07] <kgunn> jdstrand: per discussion above with AlbertA, seems we want to fix it in USC....i only tied it to mir as "opinion" so it doesn't get lost
[20:07] <kgunn> make sense?
[20:08] <jdstrand> kgunn: oh, I missed that it was against the mir task. sorry
[20:08] <AlbertA> kdub_: heh... but you are making it better now...:)
[20:08] <jdstrand> kgunn: yeah, that makes sense
[20:08] <kgunn> mterry: ricmm is in malta this week with kidney stones i hear ...wonder if rsalveti might know how/where code is to turn off sensors
[20:09] <mterry> rsalveti, poke about your knowledge of any turning-off-sensors-for-unity8 code we have?
[20:09] <kdub_> AlbertA, yeah, lucky me :)
[20:10] <rsalveti> qtubuntu-sensors?
[20:10] <kdub_> but really, this isn't 'rewire the recomposition signalling' its 'make it possible to replace the compositor easily'
[20:10] <rsalveti> mterry: not sure if we have an easy way to disable it, Saviq would know
[20:10] <rsalveti> but the bridge is in qtubuntu-sensors afaik
[20:11] <mterry> rsalveti, hrm, a quick grep doesn't see the string unity8 in there
[20:11] <mterry> rsalveti, (I'm trying to solve a problem that is apparently some piece of code examining the process name for 'unity8')
[20:11] <rsalveti> no, that would be the just for qt, that implements the bridge between qml and platform-api
[20:12] <rsalveti> hm, weird
[20:15] <rsalveti> yeah, guess ricmm would be your guy
[20:16] <dandrader> mterry, what sensor are you talking about?
[20:17] <greyback> mterry: you sure it's unity8? Or just something that loads the ubuntumirserver QPA plugin?
[20:17] <mterry> dandrader, sensors.qcom and whatever Binder_2 both stay at ~10% CPU (along with the greeter).  ricmm said we had some code to disable sensors for unity8, which I'm guessing is related?
[20:17] <greyback> mterry: have you profiled the process to see what method is being called so much?
[20:18] <mterry> greyback, I tried to use callgrind, but that slowed it down enough (even on lowest settings) that lightmd killed it.  I haven't gotten to the point of recompiling lightdm with larger timeouts
[20:18] <greyback> mterry: try "perf"
[20:19] <mterry> greyback, oh yeah?  Lighter weight?
[20:19] <greyback> mterry: *much*
[20:19] <mterry> greyback, OK, will do
[20:20] <greyback> mterry: this is a note I have on how to get/use it, hope it helps: http://pastebin.ubuntu.com/7502908/
[20:21] <greyback> important to install the linux-*-tools package that suits the kernel
[20:22] <mterry> greyback, OK thanks!
[20:22] <dandrader> mterry, well, there's platforms/ubuntu/ubuntucommon/screen.cc:127:"void QUbuntuScreen::toggleSensors(bool enable) const {" in qtubuntu that I think is used by both ubuntumirserver (unity8) and ubuntumirclient QPAs, if that's any help
[20:23] <greyback> dandrader: looking at the same :)
[20:25] <mterry> dandrader, qtubuntu does check for "unity8" as a process name, but it doesn't seem to be used anywhere!  I added debugging output and changed the check to look for unity8-greeter too, but no go
[20:26] <mterry> greyback, just filed https://code.launchpad.net/~mterry/unity-mir/no-focus/+merge/220718 for the volume up/down issue I've been seeing
[20:26]  * mterry is now laser focused on cpu bug
[20:27] <greyback> mterry: no, it does no such thing. Unity8 loads the server plugin supplied by qtubuntu. qtubuntu does listen for orientation events somehow
[20:27] <mterry> greyback, grep qtubuntu for unity8, it does do a check.  But I've been told that is dead code?
[20:27] <mterry> SurfaceFlinger support I guess
[20:29] <greyback> mterry: well I'm surprised. Yes it's checking the process name, and disabling sensors if it is unity8
[20:29] <mterry> greyback, so while I think that's dead code, I'm worried that code got copied to some other component and is the source of my current problems
[20:30] <greyback> mterry: that piece of code is very much being used still.
[20:31] <mterry> greyback, !  I must be crazy then, because I put a qDebug() line in there and couldn't see it
[20:33] <greyback> mterry: I must be mistaken. qtubuntu code a maze
[20:33] <mterry> let me double check
[20:41] <greyback> mterry: sorry to divert, but could you please link a bug to https://code.launchpad.net/~mterry/unity-mir/no-focus/+merge/220718
[20:43] <mterry> greyback, done
[20:44] <greyback> mterry: thanks!
[22:07] <robert_ancell> What are edge_flags from MirMotionEvent?
[22:08] <robert_ancell> RAOF, are you getting loads of Cyrillic spam too?
[22:47] <kdub_> just went to launchpad.net and expected to see the mir homepage
[22:47] <kdub_> we should look into fixing that
[22:47] <kdub_> :P
[23:03] <RAOF> robert_ancell: Dunno, but MirMotionEvent will probably be significantly different once we've worked out what we want in it :)
[23:04] <robert_ancell> ha!
[23:04] <RAOF> robert_ancell: Not too much Cyrillic spam, no.
[23:04] <robert_ancell> I get tonnes of Cyrillic spam to my Canonical account
[23:11] <RAOF> This is the stuff that makes it through the filters, right? I've not checked my Spam folder for the Canonical account in forever.
[23:21] <robert_ancell> No, the filters catch it all
[23:22] <robert_ancell> but I get enough false positives that I have to check the spam folder


[00:32] <TimM[m]> Hi all, would anyone be interested in collaborating to charm up Jitsi and BigBlueButton?
[02:29] <thumper> wallyworld: ping
[02:29] <wallyworld> yo
[02:30] <thumper> I think you have a bug in the 2.8 upgrade step for the tasks sequence
[02:30] <thumper> shouldn't the tasks sequence be bumped for every model?
[02:30] <wallyworld> ok, will fix, what's the issue?
[02:30] <wallyworld> probs, i'll need to check
[02:31] <thumper> do we create the task id from the sequence value +1 ?
[02:31] <thumper> is that why we're bumping the sequence id?
[02:32] <wallyworld> the sequence starting value and increment logic changed
[02:32] <wallyworld> so to avoid doubling up when using 2.8 on a 2.7 db, the sequence was incremented
[02:32] <wallyworld> otherwise the latest sequence number could have been used twice
[02:32] <thumper> that didn't answer my question
[02:33] <thumper> it doesn't make sense to me why we actually have this upgrade step
[02:34] <wallyworld> because we went from calling sequence() to sequenceWithMin()
[02:35] <wallyworld> so starting id is 1 not 0
[02:36] <wallyworld> and if you compare the old logic vs new logic, running 2.8 would have reused an existing task id
[02:36] <wallyworld> i haven't got the exact code handy
[02:37]  * thumper is looking at it now
[02:37] <wallyworld> the code has moved as well
[02:38] <wallyworld> rather, additonal use of task sequence added
[02:39] <thumper> ok
[02:39] <wallyworld> action id used to add 1 to sequence()
[02:39] <thumper> I do think that the upgrade step needs to be run across all models
[02:39] <wallyworld> which started from 0
[02:39] <thumper> right now it only does the controller model
[02:39] <wallyworld> yeah, it does
[02:39] <wallyworld> which is a bug :-(
[02:39]  * thumper is writing an upgrade step now for unit machine id denormalisation
[02:40] <wallyworld> drive by? :-)
[03:50] <TimM[m]> 1st pass at a "juju personas" document https://discourse.jujucharms.com/t/juju-user-personas/2808
[07:56] <jam> manadart: ping
[07:57] <jam> or maybe stickupkid
[10:24] <sdhd-sascha> Hi, i use juju with an lxd cluster. Now i remove one lxd-server from the cluster. Where can i find the configuration for the ip address ?
[10:24] <sdhd-sascha> I searched and changed all occurrences at `~/.local/share/juju`
[10:24] <sdhd-sascha> But i still get this error, when i try to remove or add unit's. Or when i try to call `juju storage`
[10:24] <sdhd-sascha> `ERROR getting state: getting storage provider registry: Get https://...:8443/1.0: Unable to connect to: ...:8443`
[10:26] <stickupkid> sdhd-sascha: is this the same one you signed up to?
[10:56] <sdhd-sascha> stickupkid: it was the initial lxd-server from the cluster, where i later bootstrapped juju.
[10:58] <stickupkid> sdhd-sascha, yeah, so I believe the issue is that we only know about that ip. To change the ip of that will require so mongo surgery. I think it's not unreasonable to make a bug for this.
[10:59] <stickupkid> manadart, achilleasa_ that's correct ^
[10:59] <stickupkid> ?
[10:59] <sdhd-sascha> stickupkid: where can i find the mongodb?
[10:59] <manadart> stickupkid: Yep.
[11:00] <stickupkid> sdhd-sascha, https://discourse.jujucharms.com/t/login-into-mongodb/309
[11:00] <sdhd-sascha> stickupkid: super. Thank you :-)
[11:00] <stickupkid> sdhd-sascha, would you mind taking the time to file a bug? https://bugs.launchpad.net/juju/+bugs
[11:01] <sdhd-sascha> stickupkid: yes, i will. Maybe i have time to create a patch, too
[11:02] <stickupkid> sdhd-sascha, I'm unsure what's the best way to solve this, maybe the lxd provider/environ should help the instancepoller
[11:02] <sdhd-sascha> Ah, ok. I will see
[11:03] <sdhd-sascha> Thank you
[11:39] <stickupkid> manadart, jam you seen this stack trace before ? https://paste.ubuntu.com/p/djJKY7dszN/
[11:40] <jam> 2020-03-18 11:38:45 INFO juju.cmd supercommand.go:83 running jujud [<IP_ADDRESS> 9825e246a9ec70e6551744d033802f19d78cabce gc go1.14]
[11:40] <jam> runtime: mlock of signal stack failed: 12
[11:40] <jam> runtime: increase the mlock limit (ulimit -l) or
[11:40] <jam> runtime: update your kernel to 5.3.15+, 5.4.2+, or 5.5+
[11:40] <jam> fatal error: mlock failed
[11:40] <jam> stickupkid: ^ I have not seen that before.
[11:40] <jam> sounds like a bug in focal if I had to guess
[11:40] <stickupkid> jam, neither have i
[11:40] <manadart> stickupkid: Nope.
[11:41] <stickupkid> jam, just wrapping up my focal PR, I'll see if it happens again
[12:18] <stickupkid> manadart, CR my changes since thumper last reviewed - https://github.com/juju/juju/pull/11332
[12:18] <stickupkid> manadart, also I need help testing if possible
[12:19] <manadart> stickupkid: Yep. Gimme a few.
[12:22] <hml> stickupkid: 1 line review pls?  https://github.com/CanonicalLtd/juju-qa-jenkins/pull/402
[13:00] <stickupkid> manadart, whilst you're there - https://github.com/juju/juju/pull/11333/files#diff-e8543713fc0c30ea33131d41edf815e7R16
[13:33] <manadart> rick_h_: Were we going to hang on and talk test?
[13:35] <rick_h_> manadart:  yep my bad
[13:35]  * rick_h_ got distracted
[15:42] <hml> anyone noticed something wrong with changes to “juju model-config logging-config”
[15:43] <hml> i updated logging-config value and it didn’t take effect in my model, though shown in the model config.
[15:43] <hml> had to bounce jujud for machine and unit agents
[15:44] <hml> in develop
[15:58] <danboid> Where is the juju user data stored eg credential/login stuff?
[15:59] <danboid> or in other words, how do I move a juju account?
[15:59] <rick_h_> danboid:  so it's in .local/share/juju
[16:00] <rick_h_> danboid:  to move an accout the best thing is to just juju login to the controller from a new location
[16:00] <rick_h_> danboid:  but if you need credntials/etc you need the .local/share/juju/credentials.yaml and clouds.yaml
[16:01] <danboid> rick_h_, Thanks
[16:12] <danboid> rick_h_, I presume a single juju user account be used from multiple machines then?
[16:39] <rick_h_> danboid:  yes, normally if you create a juju user and give them as passowrd you can then juju login with that user/pass as long as you know the IP of the controller
[16:39] <rick_h_> danboid:  so it's pretty easy to have multiple clients against a single controller
[16:39] <danboid> Great, thanks
[17:54] <stickupkid> rick_h_, my PR landed in 2.7
[17:54] <stickupkid> rick_h_, and so has manadart's
[17:57] <rick_h_> stickupkid:  woot woot, will watch for a ci run with that sha then ty!
[17:57] <stickupkid> nps
[19:51] <sdhd-sascha> hey, hi,
[19:51] <sdhd-sascha> i tried to connect to the mongodb, but cannot find the correct password. Like, described here:
[19:51] <sdhd-sascha> https://discourse.jujucharms.com/t/login-into-mongodb/309/5?u=sdhd
[20:00] <sdhd-sascha> Hmm, i just inside an juju controller, but can't find the `init.d` or `systemd` startup of the `mongod` ? Who launches this daemon?
[20:01] <rick_h_> sdhd-sascha:  those are started via systemd as long as you're on ubuntu >= xenial
[20:02] <sdhd-sascha> rick_h_: thank you. I'm on 20.04 on the host. And the container is `bionic`
[20:02] <rick_h_> sdhd-sascha:  this is juju bootstrapped on localhost?
[20:02] <sdhd-sascha> yes
[20:03] <rick_h_> sdhd-sascha:  so to access the contrller you do "juju switch controller; juju ssh 0"
[20:03] <rick_h_> sdhd-sascha:  that puts you on the controller machine which has mongodb and jujud running
[20:03] <sdhd-sascha> inside the controller, this command gives no output ... `# systemctl | grep mongo`
[20:03] <sdhd-sascha> But, `pstree -p` shows that mongod is running...
[20:03] <sdhd-sascha> Nope, if i try `juju ssh`, i have this:
[20:03] <sdhd-sascha> ```
[20:03] <sdhd-sascha> $ juju ssh 0
[20:03] <sdhd-sascha> ERROR opening environment: Get https://<IP_ADDRESS>:8443/1.0: Unable to connect to: <IP_ADDRESS>:8443
[20:04] <rick_h_> sdhd-sascha:  what version of Juju?
[20:04] <sdhd-sascha> rick_h_: that's because i delete `<IP_ADDRESS>` before from the cluster...
[20:04] <sdhd-sascha>  wait...
[20:04] <sdhd-sascha> 3.22 (13840) on every server
[20:04] <timClicks> I believe the service is called juju-db
[20:05] <rick_h_> sdhd-sascha:  what is the Juju version though? what does the version in juju status show you?
[20:05] <rick_h_> timClicks:  +1
[20:05] <sdhd-sascha> sorry
[20:05] <sdhd-sascha> ```
[20:05] <sdhd-sascha> juju               2.7.4                       10906  latest/stable     canonical✓  classic
[20:05] <sdhd-sascha> lxd                3.22                        13840  latest/stable     canonical✓  -
[20:05] <sdhd-sascha> ```
[20:06] <rick_h_> sdhd-sascha:  is your contrller up and running? can you do juju status successfully?
[20:06] <sdhd-sascha> rick_h_: yes
[20:06] <sdhd-sascha> ```
[20:06] <sdhd-sascha> | juju-b1a552-0  | RUNNING | <IP_ADDRESS> (eth0)       |      | CONTAINER | 0         | mars     |
[20:06] <sdhd-sascha> +----------------+---------+------------------------+------+-----------+-----------+----------+
[20:06] <sdhd-sascha> | juju-b1a552-1  | RUNNING | <IP_ADDRESS> (eth0)       |      | CONTAINER | 0         | merkur   |
[20:06] <sdhd-sascha> +----------------+---------+------------------------+------+-----------+-----------+----------+
[20:06] <sdhd-sascha> | juju-b1a552-2  | RUNNING | <IP_ADDRESS> (eth0)       |      | CONTAINER | 0         | mars     |
[20:06] <sdhd-sascha> ```
[20:06] <rick_h_> sdhd-sascha:  is it something you can pastebin? https://paste.ubuntu.com/
[20:07] <rick_h_> sdhd-sascha:  so that's lxc list which is showing you the containers you have running
[20:07] <rick_h_> looks like you've got a 3 machine HA cluster going?
[20:07] <sdhd-sascha> rick_h_: what exactly, should i print ?
[20:07] <sdhd-sascha> rick_h_: yes, 3 HA
[20:07] <rick_h_> sdhd-sascha:  `juju status`
[20:08] <sdhd-sascha> https://www.irccloud.com/pastebin/qGvYj9Bz/
[20:09] <rick_h_> sdhd-sascha:  hmm, ok can you try that ssh command again with --debug `juju ssh 0 --debug`?
[20:09] <sdhd-sascha> https://www.irccloud.com/pastebin/ahwq5OaF/
[20:10] <rick_h_> sdhd-sascha:  does that make any sense to you? It's confusing to me as the lxd machines are all 10.0.2.xx and not sure what a tomcat port has to do with anything?
[20:11] <sdhd-sascha> rick_h_: today, your colleage, say's i should send a bugreport about the failure with the deleted lxd-server.
[20:11] <sdhd-sascha> I will do tomorrow.
[20:11] <sdhd-sascha> But now, i only want to access the mongodb. But didn't have a password...
[20:12] <rick_h_> sdhd-sascha:  ok, the services are run via /etc/systemd/system/juju-db.service and /etc/systemd/system/jujud-machine-0.service
[20:12] <sdhd-sascha> rick_h_: I bootstrapped the lxd-cluster from <IP_ADDRESS>. Then i bootstrapped juju from the same ip. Then i figured out, that the machine has not enough RAM. So i deleted it from the cluster... ;-) ...
[20:13] <sdhd-sascha> rick_h_: Ah, thank you... i searched for `mongo`
[20:13] <sdhd-sascha> :-)
[20:13] <rick_h_> sdhd-sascha:  the db password will be on the machine in the /var/lib/juju/agents/machine-0/agent.conf
[20:14] <rick_h_> sdhd-sascha:  that post is the right one: https://discourse.jujucharms.com/t/login-into-mongodb/309 but since your juju ssh is wonky you'll have to pull the script apart manually
[20:14] <rick_h_> sdhd-sascha:  you can skip the juju ssh to the machine since it's lxd and just lxd exec bash on the right instance
[20:14] <sdhd-sascha> rick_h_: my agent.conf's didn't have a value `statepassword` like i said before
[20:14] <rick_h_> juju-b1a552-0 from the status output
[20:15] <rick_h_> sdhd-sascha:  it should be there.
[20:15] <sdhd-sascha> rick_h_: ah, thank you :-) i found it ;-)
[20:15] <rick_h_> sdhd-sascha:  coolio
[20:15] <sdhd-sascha> :-)
[20:17] <sdhd-sascha> login works. great +1