[09:18] <zzarr> hello!
[09:21] <zzarr> I'm going to buy a Dragonboard 410c I wonder if it is possible to rotate the screen?
[09:21] <zzarr> (HDMI output)
[09:22] <zzarr> I wish to have a display in portrait mode
[09:23] <ogra_> zzarr, we have no graphical support on the dragonboard yet (in snappy ... not sure there wil be non-snappy images for it )
[09:24] <zzarr> I though that the xenial image had Mir support for it
[09:24] <ogra_> if you throw something together yourself (i.e. to use X11 on a standard minimal install) there seems to be a freedreno based xserver from linaro though
[09:24] <ogra_> there will be Mir support for it in the snappy image at some point, for sure
[09:24] <ogra_> current focus is on IoT and headless though
[09:27] <zzarr> ogra_, this is a quote from alan_g "So what I did was install the vivid based image from 96boards and then update from the xenial archive. Then Mir 0.20 works."
[09:27] <ogra_> zzarr, well, then 6talk to 96boards, or linaro or so ... thats nothing we produce
[09:27] <alan_g> I also said this was hardly a supported approach
[09:27] <zzarr> alan_g, I missed that
[09:28] <zzarr> but it is a real Ubuntu right?
[09:28] <ogra_> we have a kernel in the archive ... but i doubt any of the tradition installers will ever get support for this device ... there are many biary blobs involved to even boot
[09:29] <ogra_> so it is unlikely yoou will see official traditional images for it
[09:29] <ogra_> (snappy OTOH will get graphical suport at some point, but is still a bit away from that)
[09:30] <alan_g> 96boards produce a vivid based image and instructions for installing that. Updating that from the xenial archives works well enough to prove Mir works, but isn't what anyone will provide support for.
[09:31] <ogra_> yeah
[09:31] <zzarr> well, what matters for me right now is that I can boot a graphical system (X or Mir) that can run a custom application written in Qt Creator (by me)
[09:32] <ogra_> that should even just work with fbdev
[09:32] <ogra_> (though, not at stellar speed i guess :) )
[09:32] <zzarr> and that I can rotate the screen to portrait
[09:32] <zzarr> okey, that's nice :-D
[10:06] <zzarr> order placed :-D
[10:10] <alan_g> alf_: do you want to review before I TA? https://code.launchpad.net/~raof/mir/new-display-api/+merge/286975
[10:22] <zzarr> okey, I guess that you all are (not) itching to know what I'm going to do with the board, I'm going to make a "smart mirror"
[10:24] <zzarr> there are a type of mirror film that reflects from one side, but lets light through in the other direction
[10:24] <zzarr> so I figured that I should make a mirror with a touch screen behind
[11:05] <alf_> alan_g: I'll take a quick look
[16:44] <xperia> Hi everyone! I am trying to Install Ubuntu-Desktop-Mir on a new Bootstraped Rootfs but somehow i am not able to pass the Login Screen after the Boot. Can somebody please tell me what are the Steps to install a full functional Ubuntu Touch Desktop on a bootstraped ubuntu rootfs please?
[16:49] <alan_g> xperia: perhaps you are seeing bug 1549455
[16:49] <ubot5`> bug 1549455 in unity8 (Ubuntu) "Unity 8/Mir doesn't load" [High,Incomplete] https://launchpad.net/bugs/1549455
[16:55] <xperia> alan_g: its exactly this Bug! have the same Problem like Described.
[16:56] <xperia> alan_g: is this somehow related to unity8 becouse if i try also just to install the newest version of ubuntu-desktop its same.
[16:57] <alan_g> xperia: sorry, I've not been actively following the problem, just thought it sounded similar
[17:01] <ChrisTownsend> xperia: There is some entropy issue that can cause failed logins.  Have you waited a while after a reboot to try to log in?  A while meaning at least 30 seconds, but maybe even longer just to be sure.
[17:01] <ChrisTownsend> That issue bites me all of the time:-(
[17:03]  * ChrisTownsend Tries to find the entropy bug...
[17:05] <ChrisTownsend> https://bugs.launchpad.net/mir/+bug/1536662
[17:05] <ubot5`> Launchpad bug 1536662 in Mir "[regression] Black screen: Mir hangs and then crashes on startup/login due to reading from /dev/random" [High,In progress]
[17:13] <alan_g> bschaefer: ^
[17:13] <bschaefer> ChrisTownsend, xperia hmm that *should* be fix with umm
[17:13] <bschaefer> uSC
[17:14] <bschaefer> 0.4.1? or 0.4.2
[17:14]  * bschaefer checks
[17:14] <ChrisTownsend> bschaefer: Really?  I thought I hit it the other day.
[17:14] <bschaefer> hmm
[17:14]  * ChrisTownsend Tries
[17:14] <alan_g> bschaefer: is USC used for Ubuntu-Desktop-Mir?
[17:14]  * alan_g forgets
[17:14] <bschaefer> alan_g, as far as i know? It should be?
[17:15] <bschaefer> ChrisTownsend, would you oknow :)?
[17:15] <ChrisTownsend> Yes, u-s-c is used in a Unity8/Mir desktop session.
[17:15] <bschaefer> im fearful this fix was said to be fixed but never released...
[17:16] <bschaefer> (which is slightly my own doing ... since i had to revert it last minute but didnt revert it from trunk)
[17:16]  * bschaefer double checks it made it
[17:16] <ChrisTownsend> bschaefer: I still have the issue on my fully updated xenial machine.
[17:17] <bschaefer> ChrisTownsend, alright hmm let me check the package source
[17:17] <ChrisTownsend> bschaefer: Ok
[17:17] <bschaefer> ChrisTownsend, one thing you can do is make a bunch of noise with your devices :)
[17:17] <bschaefer> in hope that it generates some entropy
[17:18] <ChrisTownsend> bschaefer: lol, yes, but that's not really a workaround.
[17:18] <bschaefer> huh the fix is there...
[17:18] <bschaefer> ChrisTownsend, strange, do you have a log by chance :)
[17:18]  * bschaefer must have put the override in the wrong place maybe
[17:19] <ChrisTownsend> bschaefer: I can get one.  Is it in u-s-c.log?
[17:19] <bschaefer> ChrisTownsend, yeah
[17:19] <bschaefer> ChrisTownsend, since the current *fix* should just create a dummy cookie factory, but i wasnt ever really able to test it
[17:22] <ChrisTownsend> bschaefer: Here is the log: http://pastebin.ubuntu.com/15207496/
[17:22] <ChrisTownsend> bschaefer: I'm going to try to log into the machine now after having let it sit for a while.
[17:22] <ChrisTownsend> bschaefer: And now it works.
[17:22] <ChrisTownsend> bschaefer: So fix is not working as expected.
[17:28] <bschaefer> ChrisTownsend, thanks!
[17:28] <bschaefer> yup
[17:28] <ChrisTownsend> bschaefer: Sure, np!
[17:29] <bschaefer> hmm i dont see anything about that log
[17:29]  * bschaefer attempts to reproduce it
[17:29] <bschaefer> ChrisTownsend, easier to reproduce on a reboot?
[17:29] <ChrisTownsend> bschaefer: Yes, it has to be after a reboot.
[17:30] <bschaefer> thanks
[17:30] <ChrisTownsend> bschaefer: Sure
[17:38] <bschaefer> alan_g, is the default server config all loaded before overrides take in effect (for an overriden mir::Server?)
[17:38]  * bschaefer is wondering if we *attempt* to create a cookie authority, then override it
[17:39] <bschaefer> looks like it depends on ... if the function is called or not?
[17:39] <bschaefer> ie. the_cookie_authority()
[17:39] <xperia> ChrisTownsend: Thanks a lot for your Tips! I waited 5 Minutes but nothing happens. Just the Background Screen is showed and nothing else. Looked at all Logs but could not find any usefull information to find out what the Problem could be to solve. With Ubuntu Desktop i have the Same Problem. No Laucher and No Top Bar is showed. I am able however with the Right Mouse to Start Programms Like...
[17:39] <xperia> ...Nautilus and Navigate trough all dirs. Just Windows Frame Border is missing around it. Its Strange. Some worte its related to the GPU Driver.
[17:39] <alan_g> Shouldn't be - overrides should throw if anything has been built
[17:40] <bschaefer> ChrisTownsend, idk if thats the same issue ^
[17:40] <ChrisTownsend> xperia: Hmm, ok, definitely sounds like you have some other issue.  Unfortunately I have nothing else to add at this time:-(
[17:40] <bschaefer> if you hit this issue your desktop wouldnt do anything
[17:41] <bschaefer> alan_g, thanks!
[17:41] <ChrisTownsend> bschaefer: Right, just black screen and maybe it eventually crashes back to lightdm.
[17:41] <bschaefer> ChrisTownsend, hmm since last time you did see a log info about it?
[17:41] <bschaefer> soo this could be a different issue, but could be related...
[17:42] <bschaefer> ie. see the log say NOT ENOUGH ENTROPY?
[17:42] <ChrisTownsend> bschaefer: Well, it's the same symptom, but maybe a different cause.
[17:43] <bschaefer> true hmm i wonder if my override is doing something bad...
[17:43] <ChrisTownsend> bschaefer: I'll try again and see if anything is in the unity8.log since that is not starting.
[17:43] <bschaefer> ChrisTownsend, alright, im also going to upgrade and check it out (soo ill most likly be off irc)
[17:44]  * bschaefer should really get a test laptop
[17:45] <ChrisTownsend> bschaefer: This is the unity8.log: http://pastebin.ubuntu.com/15207712/
[17:45] <bschaefer> hmm
[17:45] <bschaefer> if it was the entropy issue... i wonder
[17:45] <bschaefer> you would expect
[17:46] <bschaefer> to see Not enough entropy like you saw before?
[17:46] <ChrisTownsend> bschaefer: But u-s-c.log looks sane.
[17:46] <ChrisTownsend> bschaefer: The only thing I would see before in u-s-c.log is an exception line which I'm not seeing now.
[17:46] <bschaefer> but same symptoms, ie. once you generate enough *entropy* or do things enough
[17:46] <bschaefer> hmm
[17:46] <ChrisTownsend> bschaefer: Right
[17:47] <bschaefer> if it was an issue with my override you would expect to see the issue *every* time
[17:47]  * bschaefer will be upgraded soon
[17:47] <bschaefer> ill look at it
[17:47] <ChrisTownsend> bschaefer: I do see the issue every time if I don't wait long enough before logging in.
[17:48] <bschaefer> thats strange
[17:48] <ChrisTownsend> bschaefer: I just don't see std::exception(blah) in u-s-c.log like I would before.
[17:48] <xperia> best would be if there is a possibility haveîng a very verbose version of ubuntu-desktop-mir that can be installed to see what exactly is happening and where it hangs.
[17:48] <bschaefer> thats my starting plan :)
[17:49] <bschaefer> reproduce, recompile/test
[17:49] <ChrisTownsend> bschaefer: Yeah, you should get a testing laptop.  One for that purpose would be pretty cheap.
[17:49] <bschaefer> yeah
[17:49] <xperia> i would need to have a armhf version of it
[17:51] <bschaefer> xperia, err this isnt the desktop?
[17:51] <bschaefer> deskop is x86/amd64
[17:52]  * bschaefer goes to test and logs of irc
[17:52] <xperia> well have the same problem with ubuntu-desktop and ubuntu-desktop-mir
[17:52] <xperia> mir is touch gui of ubuntu desktop
[17:53] <xperia> btw just to be sure that i have doen everything right
[17:53] <xperia> what for steps are needed to install ubuntu-desktop-mir inside a chrooted debootstrap rootfs?
[17:54] <xperia> is apt-get install ubuntu-desktop-mir only needed or it is requered to do more like modify some scripts add aditional users and so on ?
[17:54] <xperia> maybe is realted also to some missing additional config steps.
[17:55] <ChrisTownsend> xperia: Sounds to me you are doing something *very* custom.
[17:55] <xperia> yeees i am trying to port ubuntu touch desktop to a new device
[17:55] <bschaefer> ChrisTownsend, hmm getting a different issue
[17:56] <xperia> it works actually. ubuntu boots on new device. login screen is showed. i am able to login but after this just background and nothing else.
[17:56] <bschaefer> ChrisTownsend, http://paste.ubuntu.com/15207808/
[17:56] <bschaefer> xperia, yeah that sadly isnt the same issue im looking at :( or suspecting
[17:57] <ChrisTownsend> xperia: I don't think your pulling in a desktop environment.  You probably need unity8.
[17:57] <ChrisTownsend> bschaefer: You may need to remove some package.
[17:57] <bschaefer> :|
[17:57] <bschaefer> yeah
[17:57] <bschaefer> figured
[17:57] <xperia> bschaefer i am sure we have both the same problem
[17:57] <bschaefer> but which ones haha
[17:57] <xperia> its the gpu driver
[17:57] <bschaefer> xperia, but you see unity8 right?
[17:58] <bschaefer> err or based on my log?
[17:58] <xperia> what for a gpu do you have ?
[17:58] <bschaefer> some intel one
[17:58]  * bschaefer looks
[17:58] <xperia> do sudo lsmod
[17:58] <bschaefer> 00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated Graphics (rev 09)
[17:59] <xperia> and what does sudo lsmod show
[17:59] <xperia> on my side the gpu driver is not loaded but it looks like its needed for the display of the Ubuntu GUI
[18:00] <bschaefer> i915
[18:00] <xperia> need to work on this. loading of the rigth gpu driver on my side.
[18:00] <ChrisTownsend> bschaefer: Did you apt-get autoremove any unneeded packages?
[18:01] <bschaefer> o lots
[18:01] <ChrisTownsend> bschaefer: Also, what mir mesa packages to you have?
[18:03] <bschaefer> ChrisTownsend, 4
[18:03]  * bschaefer also isnt sure which mesa package you're refering to :)
[18:03] <bschaefer> mir-client-platform-mesa4:amd64
[18:04] <bschaefer> ii  mir-platform-graphics-mesa-kms7:amd64                0.19.3+16.04.20160212-0ubuntu1              amd64        Display server for Ubuntu - platform library for KMS Mesa
[18:04] <bschaefer> ii  mir-platform-graphics-mesa-x7:amd64                  0.19.3+16.04.20160212-0ubuntu1              amd64        Display server for Ubuntu - platform library for X11 Mesa
[18:04] <ChrisTownsend> bschaefer: lol, yeah, those are what I was talkin' 'bout.
[18:05] <xperia> bschaefer: from your Log it Load this Graphic Library here => graphics-mesa-kms.so.7 then it try to load mircommon Kernel Module => mircommon: Loading module: /usr/lib/x86_64-linux-gnu/mir/server-platform/input-evdev.so.4
[18:05] <xperia> and it crashes. I am sure its related to Driver like on my Side.
[18:05] <xperia> [2016-02-26 09:53:07.267594] mircommon: Loading module: /usr/lib/x86_64-linux-gnu/mir/server-platform/input-evdev.so.5
[18:05] <xperia> [2016-02-26 09:53:07.268073] mircommon: Loading module: /usr/lib/x86_64-linux-gnu/mir/server-platform/input-evdev.so.4
[18:05] <bschaefer> xperia, try doing a auto remove of packages
[18:05]  * bschaefer just removed a bunch
[18:05] <bschaefer> let me reboot
[18:09] <bschaefer> hmm now gtk3 wont load :|
[18:09] <bschaefer> umm
[18:09] <bschaefer> ChrisTownsend, same issue let me check
[18:10] <ChrisTownsend> bschaefer: Why does this stuff have to be so temperamental????:)
[18:10] <bschaefer> :||||
[18:11] <bschaefer> ChrisTownsend, not sure :( and im pretty sure this is blocking your stuff atm?
[18:11] <bschaefer> hmm
[18:11] <ChrisTownsend> bschaefer: You have the same platform module issue?
[18:11] <ChrisTownsend> bschaefer: From you previous pastebin that is?
[18:11] <bschaefer> ChrisTownsend, yeah
[18:11] <ChrisTownsend> bschaefer: Mine is not a client platform module issue.
[18:12] <bschaefer> i just upgrade a bunch though...
[18:12] <bschaefer> upgraded*
[18:19] <ChrisTownsend> bschaefer: It looks like from your pastebin, it is trying to load an older version of the driver .so's.  Here's yours: server-mesa-x11.so.7 and graphics-mesa-kms.so.7.  Mine are both .8.
[18:19] <ChrisTownsend> Dang, he just left.
[18:22] <bschaefer> ChrisTownsend, hmm works fine for me
[18:22] <bschaefer> unity8 :|
[18:22] <bschaefer> takes 5-8 seconds to load
[18:22] <bschaefer> but idk if thats normal or not...
[18:23] <bschaefer> dam entropy pool
[18:23] <ChrisTownsend> bschaefer: You mean you can (fairly) immediately get to Unity8 after a reboot.
[18:23] <ChrisTownsend> ?
[18:23] <bschaefer> ChrisTownsend, yeah
[18:23] <bschaefer> twice in a row from boot
[18:23] <ChrisTownsend> bschaefer: 5-8 seconds is normal.
[18:23] <bschaefer> yeah
[18:23] <ChrisTownsend> bschaefer: Never works for me.
[18:23] <bschaefer> let me ... write something that will drain my entropy
[18:23] <bschaefer> ChrisTownsend, try to do a dist-upgrade?
[18:23] <bschaefer> and what version of USC do you have
[18:23] <ChrisTownsend> bschaefer: I did as of about an hour ago.
[18:24] <bschaefer> dang
[18:24] <ChrisTownsend> $ apt-cache policy unity-system-compositor
[18:24] <bschaefer> hmmmm
[18:24] <ChrisTownsend> unity-system-compositor:
[18:24] <ChrisTownsend>   Installed: 0.4.2+16.04.20160219.1-0ubuntu1
[18:24] <bschaefer> yeah
[18:24] <bschaefer> hmm
[18:25] <bschaefer> but yeah let me write something that will drain my entropy pool then attempt to log in
[18:26] <ChrisTownsend> bschaefer: It should be emptied on reboot, no?
[18:26] <bschaefer> entropy gets generated from devices
[18:26] <bschaefer> starting from boot
[18:26] <ChrisTownsend> bschaefer: Maybe you have busy devices?:)
[18:26] <bschaefer> soo it really depends on how much *gets* generated on boot
[18:26] <bschaefer> haha
[18:26] <bschaefer> i didnt touch anything
[18:26] <bschaefer> in hopes to get something...
[18:27] <bschaefer> ChrisTownsend, you can do: cat /proc/sys/kernel/random/entropy_avail
[18:27] <bschaefer> maybe if you can try to print that out in tty1 ... before logging into unity8 to see how much you have?
[18:27] <ChrisTownsend> bschaefer: Also, before, it would crash back out to lightdm and I'd get the exception message in u-s-c.log, but now, it just sits at the black screen.
[18:28] <ChrisTownsend> bschaefer: Ok, I'll try that.
[18:28] <bschaefer> ChrisTownsend, hmm
[18:28] <bschaefer> vogons any other changes in USC/boot stuff with mir that could cause a black screen with no message?
[18:28]  * bschaefer still assumes my code somewhere but i can reproduce
[18:29] <bschaefer> ChrisTownsend, the thing is *all* we need is 1 byte
[18:29] <bschaefer> of entropy
[18:29] <bschaefer> err 1 bit
[18:29] <bschaefer> all we need to know is we can read from it, as we select(..) on /dev/random
[18:29] <bschaefer> which should tell us its ok to read from
[18:29] <ChrisTownsend> bschaefer: Hmm, ok.  entropy_avail showed stuff and it worked.
[18:29] <bschaefer> ChrisTownsend, yeah ... im worried that you logging into your tty
[18:29] <bschaefer> will cause entropy
[18:29] <ChrisTownsend> bschaefer: Probably
[18:30] <bschaefer> with the clickity clackity of the keyboard
[18:30] <bschaefer> ChrisTownsend, how much?
[18:30] <ChrisTownsend> bschaefer: Actually, it's through ssh, but NIC has activity
[18:30] <bschaefer> ChrisTownsend, like pretty low? 20-30?
[18:30] <bschaefer> or high?
[18:30] <ChrisTownsend> bschaefer: Wouldn't typing on the keyboard to log in create entropy?
[18:30] <bschaefer> yes
[18:30] <ChrisTownsend> bschaefer: It was in the 30 range.
[18:30] <bschaefer> but
[18:30] <bschaefer> maybe not
[18:31] <bschaefer> ChrisTownsend, o thats super low
[18:31] <ChrisTownsend> bschaefer: This time, it didn't work.
[18:31] <bschaefer> mine is sitting at ~1000 right now
[18:31] <bschaefer> hmm 30? isnt enough
[18:31] <bschaefer> hmm i wonder if they collect entropy and dont write to /dev/random ... until?
[18:31] <bschaefer> 256 or something?
[18:31] <bschaefer> ChrisTownsend, keep checking the entropy?
[18:31] <bschaefer> is it going up?
[18:31] <bschaefer> that doesnt make sense though...
[18:32] <ChrisTownsend> bschaefer: Strange, it went from 61 to 35.
[18:32] <bschaefer> bregma, would you have any ideas about entropy and when it would write to /dev/random?
[18:32] <bschaefer> ChrisTownsend, huh... is something eating it all up?
[18:32] <bschaefer> that *we* arent controlling?
[18:32] <ChrisTownsend> bschaefer: Now, it's going back up...96.
[18:32] <bschaefer> that would make sense to me? You have low entropy on boot, then something eats all of it
[18:32] <ChrisTownsend> bschaefer: But unity8 already failed.
[18:32] <bschaefer> hmm what caused it to drop...
[18:32] <bschaefer> right
[18:32] <ChrisTownsend> No idea
[18:34] <ChrisTownsend> bschaefer: Ok, I just tried it and entropy was at ~17 and unity8 failed to load.
[18:34] <bschaefer> ChrisTownsend, can you do a watch -n <command to read entropy> on your ssh?
[18:34] <bschaefer> while you're about to boot unity8?
[18:34] <bschaefer> so you can see if it drops to 0?
[18:35] <ChrisTownsend> ok, I'll try it
[18:36] <bschaefer> we dont even read from that FD
[18:36] <bschaefer> all we do is, open /dev/random, select on that FD
[18:36] <bschaefer> and when it becomes ready, we drop, then read from it
[18:36] <bschaefer> but that code *shouldnt* be running
[18:36] <bschaefer> :|
[18:37] <bschaefer> since we override it with a nothing factory
[18:37] <bschaefer> but does it actually get overriden... it should throw if something is there...but let me check
[18:37] <ChrisTownsend> bschaefer: I saw entropy drop twice.  I'm going to see if it does this without trying to log in to unity8.
[18:38] <bschaefer> drops to 0?
[18:38] <ChrisTownsend> ~0, definitely single digits.
[18:38] <bschaefer> yeah
[18:39] <bschaefer> ChrisTownsend, because once we see /dev/random is open to be read, we then drop to use /dev/urandom... which wont block on that
[18:39] <bschaefer> but we shouldnt be using that code... haha... ok umm
[18:39] <ChrisTownsend> bschaefer: Hmm, so as soon I start typing in my password in lightdm, it drops to ~0.
[18:39] <bschaefer> i need to be able to reproduce this
[18:39] <bschaefer> hmm what?
[18:39] <bschaefer> pam?
[18:39]  * bschaefer wants to blame pam
[18:39] <bschaefer> but i wont
[18:39] <ChrisTownsend> bschaefer: Not even hitting enter, so not pam.
[18:40] <bschaefer> but doesnt lightdm interact with lightdm?
[18:40] <bschaefer> before enter?
[18:40]  * bschaefer cant find the override the cookie factory function?
[18:40] <bschaefer> i must be blind as i remember writting it
[18:40] <ChrisTownsend> bschaefer: So I see it drop to 0, then wait to let it build again, and then it works.
[18:40] <bschaefer> yeah
[18:40] <bschaefer> soo yeah something is eating the entropy pool, but i dont see why we would block on that?
[18:40] <bschaefer> if anything exists
[18:40] <bschaefer> we wait 30 seconds
[18:41] <bschaefer> for /dev/random to be working again
[18:41] <ChrisTownsend> bschaefer: I don't think unity8 waits 30 seconds.
[18:41] <bschaefer> and also this function shouldnt even be running...
[18:41] <bschaefer> yeah
[18:41] <bschaefer> but it jumps back up quickly
[18:42] <ChrisTownsend> bschaefer: unity8 fails saying connecting to Mir has failed which must be the time it is waiting for entropy to build.
[18:42] <bschaefer> o yeah that function gets generated...
[18:42] <ChrisTownsend> bschaefer: I think it's a race.
[18:42] <bschaefer> yeah
[18:42] <bschaefer> dang
[18:42] <bschaefer> ChrisTownsend, but but but ... it shouldnt be running that code :)
[18:42] <bschaefer> but i guess it must
[18:42] <bschaefer> as this makes to much sense
[18:42] <ChrisTownsend> bschaefer: Well, not sure what to say.
[18:42] <bschaefer> but where is that expection?
[18:43] <bschaefer> yeah im just rambling to my self
[18:43] <ChrisTownsend> I know you are:)
[18:44] <bschaefer> hmmm
[18:44] <ChrisTownsend> bschaefer: If whatever is eating the entropy didn't eat it, then I think it would be fine.
[18:44] <bschaefer> ChrisTownsend, let me do some testing, to see what happens when i drop my entropy pool to 0 but just looping for ever with a
[18:44] <bschaefer> random call
[18:44] <ChrisTownsend> bschaefer: Ok.
[18:44] <bschaefer> ChrisTownsend, yeah i bet it wouldnt but ... we should wait a few seconds
[18:44] <bschaefer> which should be enough to recover?
[18:45] <bschaefer> ChrisTownsend, how fast do it come back?
[18:45] <ChrisTownsend> bschaefer: I think if I type my password in slowly enough in lightdm, then it'll work.
[18:45] <bschaefer> ChrisTownsend, ill be logging out...bb in like ~10-15
[18:45] <bschaefer> haha
[18:45] <ChrisTownsend> bschaefer: Fairly fast
[18:45] <bschaefer> ChrisTownsend, but it seems to do the check in an instant
[18:45] <bschaefer> yeah
[18:45] <ChrisTownsend> bschaefer: Well, u-s-c is happy, it's that unity8 is not patient.
[18:45] <bschaefer> which 1 second *should* be enough time of waiting? I wonder of unity8 just instantly fails?
[18:45] <bschaefer> yeah
[18:46] <bschaefer> hmm soo if unity8 waited like 1 second when attempting to create the mir server?
[18:46] <ChrisTownsend> bschaefer: Yeah, the unity8 upstart is just fired off and it does it stuff immediately.
[18:47] <bschaefer> didnt we use to have a spinner/sleep for this?
[18:48]  * bschaefer relogs and messes around
[18:48] <ChrisTownsend> bschaefer: Some sort of query of u-s-c from unity8 would be nice, like "Hey, u-s-c are you ready?", and u-s-c is like, "Nope", and unity8 waits a bit before trying again.
[18:48] <bschaefer> yeah that would be nice ...
[18:48] <bschaefer> brb
[18:48] <ChrisTownsend> ok
[18:53] <bschaefer> ChrisTownsend, yeah i can reproduce when i do: cat /dev/random then attempt to log in
[18:54] <bschaefer> and my entropy drops to ~0 then climbs to 20-30 but yeah mir server does not start
[18:54] <bschaefer> (from the unity8 log)
[18:54] <bschaefer> but my USC log is normal...
[18:54]  * bschaefer wonders if he can reproduce this issue on a tty
[18:54] <bschaefer> with a demo server
[18:54] <ChrisTownsend> bschaefer: Ok.  IS most definitely a race in that u-s-c is not quite ready when unity8 starts up.
[18:55] <bschaefer> yeah
[18:55] <bschaefer> but ... hmm why
[18:56] <ChrisTownsend> bschaefer: You mean why is u-s-c not ready?
[18:57] <bschaefer> ok... dont cat dev random and attempt to start a server in the tty... that will lock the machine up
[18:58] <bschaefer> ChrisTownsend, yeah on the demo server it locks up... but once i stop cating /dev/random the server works perfectly
[18:58] <bschaefer> sooo the issue is unity8 not waiting a mirco second once we attempt to start login
[18:59] <bschaefer> or start it
[18:59] <bschaefer> (well an issue)
[18:59] <ChrisTownsend> bschaefer: Well, any way to make u-s-c ready sooner, like before?  Or does it have to wait on some entropy?
[19:00] <bschaefer> ChrisTownsend, well USC shouldnt need entropy...
[19:00] <bschaefer> but i should stop saying that
[19:00] <anpok> hm
[19:00] <ChrisTownsend> bschaefer: Or whatever it is?  It's obvious that *something* related to Mir needs it.
[19:00] <bschaefer> yeah
[19:01] <anpok> bschaefer: what happened with the make the wait for dev random asynchronous?
[19:01] <ChrisTownsend> bschaefer: If I wait long enough then watch entropy, then log in, entropy doesn't drain and all is fine.
[19:01] <bschaefer> anpok, does anything else input wise depend on /dev/random on boot? Im pretty sure the cookies is the issue
[19:01] <anpok> +plan
[19:01] <bschaefer> anpok, needs to be done
[19:01] <bschaefer> i should write that and test it fixes this
[19:01] <ChrisTownsend> bschaefer: You have a task!
[19:01] <ChrisTownsend> :)
[19:01] <bschaefer> anpok, thought the USC fix would be a good hold until then
[19:01] <bschaefer> :)
[19:01] <bschaefer> but
[19:02] <bschaefer> the confusing part is the USC fix seems to do nothing but remove the throw?
[19:02] <anpok> there is another problem?
[19:02] <ChrisTownsend> bschaefer: In all fairness, the time needed to wait before logging in is much less than before.
[19:02] <bschaefer> ... well the throw is no longer happening but thats most likely due to unity8 puking beofr ehtne
[19:02] <bschaefer> yeah
[19:02] <anpok> ah yes..
[19:03] <bschaefer> anpok, my worry was, that i override the cookie factory
[19:03] <bschaefer> after the cookie factory is asked to be made
[19:03] <anpok> so u8 is adding the cookies to input events, right? (where is that actually happedning?)
[19:03] <anpok> -d
[19:03] <bschaefer> ie. when the_connection_creator
[19:04] <bschaefer> anpok, nope, this is all on boot
[19:04] <bschaefer> soo if i did a lazy eval
[19:04] <bschaefer> the secret shouldnt be generated...
[19:04] <bschaefer> until libinput generates an event for u8
[19:04] <anpok> aehrm
[19:04] <bschaefer> that is a keyboard/mouse
[19:04] <anpok> libinput is not in the u8  process
[19:04] <bschaefer> :|
[19:04] <bschaefer> anpok, how does it get event
[19:05] <bschaefer> events*?
[19:05] <bschaefer> a mir surface?
[19:05] <anpok> yes
[19:05] <bschaefer> which ... would be libinput? on mirs side
[19:05] <bschaefer> as u8 does not use the cookies yet
[19:05] <anpok> the one the nested display creates for each output the nested servers uses
[19:05] <bschaefer> afaik
[19:05] <anpok> yes
[19:06] <anpok> so the libinput-input platform reads events and attaches an empty cookie to it..
[19:06] <bschaefer> anpok, im pretty sure... whats happening in usc
[19:06] <bschaefer> i override the cookie factory after
[19:06] <bschaefer> the WM builder is overriden
[19:06] <bschaefer> and when the WM builder is overriden it uses
[19:06] <bschaefer> like the focus controller and a few other things
[19:06] <bschaefer> which will end up building the cookie authority
[19:06] <bschaefer> before we overrid
[19:07]  * bschaefer checks thats the issue
[19:08] <anpok> hm nothing should be created when you are still allowed to inject implementations
[19:09] <bschaefer> anpok, but ... what if you do
[19:10] <bschaefer> anpok, http://paste.ubuntu.com/15208526/
[19:10] <bschaefer> anpok, yeah actually ... those are just functions
[19:10] <bschaefer> that arent called until
[19:10] <bschaefer> after that...
[19:10] <bschaefer> :|
[19:10] <anpok> yeah
[19:10] <bschaefer> so much for that idea... as i've no clue *why* it even thinks it want entropy
[19:10] <bschaefer> ie. i've no clue why it doesnt use the stub version
[19:11] <bschaefer> thats most troubling... hmm
[19:11] <anpok> oh but it is usc failing to start or u8
[19:12] <bschaefer> anpok, both
[19:12] <bschaefer> usc is failing, then u8 freaks out
[19:12] <bschaefer> and says mir server could not start
[19:12] <bschaefer> anpok, but it also waits for a micro second to do this as well
[19:13] <bschaefer> if it only gave usc ~500ms it *should* be fine
[19:13] <ChrisTownsend> I don't think u-s-c is failing per se as it's up and running.  It's u8 failing because it seems u-s-c is not "ready".
[19:13] <bschaefer> since ChrisTownsend is losing entropy when he types
[19:13] <bschaefer> and USC blocks for a little bit waiting for /dev/random
[19:13] <bschaefer> but unity8 sees this as a failure
[19:13] <bschaefer> and terminates
[19:13] <anpok> bschaefer: but why would usc wait for /dev/random?
[19:13] <bschaefer> or just logs an issue and stops
[19:14] <bschaefer> anpok, well from the cookie authority ... even though i override it...
[19:14] <bschaefer> anpok, i just can seem to reproduce this when theres little entropy
[19:14] <ChrisTownsend> I think maybe u8 should try more than once befroe giving up, maybe adding some delay between tries and then giving up after x amount of tries.
[19:16] <ChrisTownsend> Yeah, only seems to occur for me when entropy is maybe less than 30, but that's just observation, not a measured threshold.
[19:16] <anpok> bschaefer: but there is only one place in the code.. and you seem to override that..
[19:17] <anpok> bschaefer: are you sure the right versions are being used?
[19:17] <bschaefer> anpok, i know... thats my confusion this entire time...
[19:17] <bschaefer> anpok, yeah i grabed the source from universe :(
[19:17] <bschaefer> anpok, which is why im wondering... if the override didnt work?
[19:18] <bschaefer> for w/e reason...
[19:19]  * bschaefer attempts to override the demo server...
[19:21] <bschaefer> anpok, but the override has to be working
[19:21] <bschaefer> because it was crashing before
[19:22] <bschaefer> anpok, does anything else depend on random?
[19:22]  * bschaefer cant think of it 
[19:24] <bschaefer> anpok, umm im reading this... and i dont override the create functions...
[19:25] <bschaefer> but the create should be...
[19:25] <bschaefer> the override lambda it self
[19:26] <bschaefer> ChrisTownsend, thanks i think i've enough to work with
[19:26]  * bschaefer finds a better solution here
[19:26] <ChrisTownsend> bschaefer: Oh good!
[19:26] <ChrisTownsend> bschaefer: Thank you too!
[19:26] <bschaefer> np!
[19:43] <bschaefer> urg stub works perfectly in the demo server
[19:45] <bschaefer> anpok, the nested serer... vs the usc server
[19:45] <bschaefer> wouldnt both need to be overriden?
[19:59] <anpok> bschaefer: well .. i thought one shoud be the cookie authority for the session?
[19:59] <bschaefer> anpok, but .. doesnt unity8 make its own server? with its own overrides and everything?
[20:00] <anpok> sure
[20:00] <bschaefer> soo unity8 will be depending on /dev/random
[20:00] <bschaefer> since we dont override that server?
[20:00] <bschaefer> (but it will be needed)
[20:00] <bschaefer> soo we cant soo yeah let me create the lazy eval
[20:01] <bschaefer> and it should fix the issue...
[20:01] <anpok> yes
[21:53] <bschaefer> ChrisTownsend, ok i have a fix
[21:54] <bschaefer> test confirmed (being able to log in with cat /dev/random going on, and while smashing the keyboard)
[21:54] <bschaefer> soo the delay in creating the secret is enough to allow for usc to start and unity8 to be so it gives it time to create the secret