[00:00] RAOF: You just need to switch the scheduling policy on your brain. [00:00] Of course, that could bring down the whole system so it's not allowed under the controlled substances act... [00:03] RAOF: got a second? [00:10] thomi: Sure. [00:10] RAOF: just writing this autopilot test for u-s-c, what's the best way of determining the graphics chipset in use? [00:10] RAOF: also, Didier's email seemed to say that we should only be running u-s-c on intel chipsets? [00:10] How specific are we about "in use"? [00:11] ie: hybrid graphics, what should we report? [00:11] RAOF: I don't know... I guess you'd know better than me [00:11] the test is to determine whether we're actually running u-s-c on supported hardware [00:13] glxinfo | grep renderer (in XMir) is not-terrible [00:13] RAOF: I guess IO could do something like run "lshw -class display" and parse the output [00:14] RAOF: OK, so under what situations should we be running u-s-c? [00:14] Everywhere that isn't proprietary driver. [00:14] Oh, and not on virtual hw, or crazy old stuff like SiS. [00:15] RAOF: so, how do I determine "not on proprietary driver"? [00:15] or "not on virtual hardware"? [00:15] I'm wondering if it's better to whitelist suppoorted hardware, or to blacklist unsupported hardware [00:15] If i915.ko, radeon.ko, or nouveau.ko are loaded. [00:15] ahh, ok, that's much easier [00:16] thanks! [00:16] Acutally, that'll miss some hybrid systems. [00:17] You actually want to make sure that each VGA device in lspci | grep VGA has its associated driver loaded. [00:17] So, if there's an nvidia device in lspci | grep VGA, then nouveau.ko is loaded, itc. [00:17] etc. [00:18] hmmmm, that sounds harder to do exhaustively [00:19] lspci -vvv, parse it out, check that "Kernel driver in use: " is the right thing. [00:20] RAOF: OK, but presumably there's edge cases when matching device -> driver? or do we really only care about those three cases: intel, nvidia & ati? [00:21] Only those three cases. [00:21] ok, sweet [00:22] If there's an intel VGA device (identifiable by 8088 pci id), then it must have i915 loaded; if there's an nvidia device, it must have nouveau loaded, likewise ati. [00:22] awesome, thanks for your help. [00:22] Going to lunch now, will get this finished when I get back. === thomi is now known as thomi|lunch [00:24] Arse. This kernel is built with debug symbols, making it 700 MB, or significantly larger than my boot partition. Poot. [00:45] ... chain-load?! [00:46] boot of usb?! =) [00:48] RAOF: Sounds like the second reason today to switch to FreeBSD [01:15] Surely GNU/Hurd! === thomi|lunch is now known as thomi [02:01] I don't suppose anyone here has a machine with a radeon graphics chipset? [02:02] RAOF: perhaps you have one? [02:02] thomi: I do. [02:03] What can I do for yoU? [02:03] RAOF: any chance you could send me the output of 'lspci -vvv' on that machine please? [02:03] or maybe just the section for the VGA device [02:10] http://paste.ubuntu.com/5886137/ (and with -n, which you should probably use so you can match on PCIID ) [02:11] http://paste.ubuntu.com/5886140/ [02:12] thomi: ^^^ [02:14] RAOF: thanks [02:14] You'll notice this is a hybrid system, so a good test :) [02:53] RAOF: what's the best way to determine if xmir is running? simply "pgrep unity-system-compositor" ? [02:54] or is there some better way that you can think of? [02:57] Two options; pgrep unity-system-compositor or grep xmir /var/log/Xorg.$(echo $DISPLAY | sed s/://g).log [02:58] RAOF: I don't like the log file apprach, it seems a bit fragile to me... but I'm having trouble getting pgrep to do what I want :( [02:58] ahh yes, I remember [02:58] pgrep cuts process names [02:58] so "pgrep unity-system" works, "pgrep unity-system-compositor" will never return anything :( [02:59] You could also check the args used to spawn /usr/bin/X; if they contain “-mir ”, then it's XMir. [03:03] robert_ancell: What's you're preferred medium? :) [03:03] Oh [03:22] robert_ancell: got a second? [03:25] thomi, otp [03:26] thomi, sure [03:26] thomi, are you checking from inside X or outside it? [03:26] robert_ancell: https://code.launchpad.net/~thomir/unity-system-compositor/add-autopilot-test/+merge/175444 [03:27] robert_ancell: I'm hoping we can get didier to do the packaging for us? [03:27] thomi, what packaging is required? [03:27] robert_ancell: autopilot tests are usually packaged into -autopilot [03:27] package [03:28] so in this case, unity-system-compositor-autopilot [03:28] thomi, and that's part of the u-s-c source package? I can do that [03:28] yes [03:28] awesome - I can package python modules, but packages where it's half Cmake, half python build systems confuse me [03:29] thomi, what is an existing package I can look at? [03:29] robert_ancell: lp:unity8 has one [03:30] as does lp:unity, and any of the phone apps [03:30] usually I'd point dh at the setup.py file in tests/autopilot, but I'm not sure how you do that in a mixed package? [03:31] thomi, because it's all python we just make a debian/unity-system-compositor-autopilot.install file and update debian/control. I'm doing a merge now [03:31] awesome, thanks [03:33] I thought it was more complicateed than that, but OK :) [03:38] thomi, was there a reason for unity_system_compositor over unity-system-compositor? [03:38] robert_ancell: yes, you can't have '-' in module names [03:44] thomi, https://code.launchpad.net/~robert-ancell/unity-system-compositor/add-autopilot-test-packaging/+merge/175446 [03:45] will merge now [03:47] robert_ancell: OK, those changes are now in my branch. Will email the list so didrocks reviews it [04:26] kdub, still here? [04:42] thomi, did you want didrocks to specifically review https://code.launchpad.net/~thomir/unity-system-compositor/add-autopilot-test/+merge/175444? [04:42] robert_ancell: yes [04:43] robert_ancell: Standard procedure is that his team review any packaging changes for stuff that's being daily-released [04:43] thomi, oh, I forgot to say, you probably want to add something to the Depends line in debian/control for the test [04:43] robert_ancell: otherwise it's too easy to release broken packages into distro [04:43] I'm not sure which packages it needs [04:43] robert_ancell: oh, good point, thanks :) [04:43] thomi, can you add a specific review request for him? Otherwise when I review it it will not be pending on him [04:44] sure [04:44] (and then I'll forget and just approve it) [04:45] done and done [04:59] I hope this doesn't hit the thermal trip point... [05:03] good morning :) [05:04] Good morning [05:05] * RAOF wonders if packaging thermald would be a useful way of attempting to make this laptop less likely to emergency-shutdown due to hitting the thermal trip point. [05:28] RAOF: What? Ubuntu doesn't already come with sane sensors monitoring? [05:31] thomi: hey, still around? [05:31] didrocks: yo yo [05:31] thomi: just looking at MP ;) So I think we need another tests: if we are not on a open source driver, ensuring unity-system-compositor doesn't run [05:32] thomi: of installing autopilot tests, I prefer having a setup.py and some hack in debian/rules, do you want me to propose a branch with that? [05:32] didrocks: sure, that's trivial, one second [05:32] thomi: something similar than unity8 if you want to do it (setup.py in the autopilot directory) and in debian/rules, see my call to setup.py [05:33] then dh --with python2 and build-dep on python [05:33] didrocks: ugh, I had that initially, and robert_ancell removed it [05:33] didrocks: can I ask you to do the packaging for me? Pretty please? [05:33] thomi: sure sure, incoming! [05:33] I'll buy you a beer next time we meet :) [05:33] heh, \o/ [05:35] didrocks, for the armhf test hangs ... [05:35] did you see Stephen's mail? [05:35] tvoss_: hey, yeah, read it [05:36] didrocks, so one way would be for us to come up with a custom TEST macro (TEST_WITH_REQUIREMENTS) that checks if android runtime is present and disables the test if not automatically [05:37] didrocks, what do you think? [05:38] tvoss_: sounds the right way to me, do you have any way to tests that we are running with android? like detecting a file is present? [05:38] didrocks, we could try to resolve symbols from the platform api [05:38] didrocks: actually, I'll make this test case test both scenarios [05:38] thomi: that's fine as well, just change the name then :) [05:39] didrocks, essentially taking the cause of the error as check [05:39] thomi: platform-api will tell "not on android"? [05:39] tvoss_: because platform-api will be installed, right, so platform-api symbols will be there [05:40] didrocks, fair point ... hmmm, we need a way to force the backend instantiation and report an error if something is missing ... [05:41] tvoss_: couldn't platform-api have this check? [05:41] like a platform-run call to know where we are running on? [05:41] (just a silly proposal :p) [05:42] didrocks, hmmm ... let me think about it for a bit [05:44] thomi: ok, the longer was to readd the ppa to install libmirserver-dev ;) here we are, do you want a MP against your branch? (it's just one commit): lp:~didrocks/unity-system-compositor/autopilot-packaging-fixes [05:45] didrocks: nah, I'll just merge it in, thanks! [05:45] thomi: yw ;) [05:45] didrocks: just finished the test as well [05:45] great :) [05:45] RAOF: hey, did you see that xorg-server is lower than distro? are you planning on updating it? [05:45] RAOF: I thin I can't run the autopilot tests because of that, right? [05:46] sec [05:47] https://launchpad.net/~mir-team/+archive/staging/+copy-packages still times out :/ [05:47] didrocks: your changes have been merged in, and the new test is pushed. [05:47] thomi: excellent! looking at the testing part, you want a second review from robert_ancell I guess as well? [05:48] didrocks: if he's still here [05:48] didrocks: otherwise I think we're good to merge [05:48] what could possibly go wrong!? :P [05:48] thomi: heh, indeed! ;) [05:48] RAOF: pushed [05:49] thomi: sounds perfect to me with those changes, +1 ;) [05:49] I'm now adding it to the tests to run [05:51] done [06:10] didrocks, https://github.com/ros-infrastructure/buildfarm/issues/87 [06:11] tvoss_: but, the buildds (not the virtualized builders) are now running with qmenu? Not sure of the latest, but from last news I got, they were still running on bare metal [06:12] didrocks, hmmm, good question ... checking with #is [06:13] didrocks: Yes, I was planning to update xorg-server. Just after mlankhorst pushes 1.14.2-0ubuntu1 to git :) [06:14] duflu: Ubuntu *does* have sane sensors monitoring, but thermald does intel-specific tricks. [06:15] it's all you now, stop hiding behind me :P [06:15] RAOF: Cool. In fact cooler the better [06:15] mlankhorst: Ta [06:15] RAOF: I can't copy package to the daily-build-next and next ppas :/ [06:16] didrocks: I'm updating now. [06:16] RAOF: I can't add the staging ppa, because different version of Mir and unity-system-compositor (with versions higher than daily-build-next/next) [06:16] RAOF: do you think I should just reupload to daily-build-next them? [06:16] mesa + xorg* [06:18] I'm not sure what you're asking. [06:18] RAOF: basically, I need mesa + xorg* copied in daily-build-next ppa [06:18] (I can't add staging because of mir/unity-system-compositor version mistmatch) [06:18] Right. And for that we need an xserver that's newer than the archive. [06:18] RAOF: I wanted to binary copy your packages, but https://launchpad.net/~mir-team/+archive/staging/+copy-packages times out constantly for me [06:19] Really? I've been happily copying packages from staging for a while. [06:19] RAOF: is it timeouting for you? [06:19] How many packages are you trying to copy? [06:19] RAOF: well, I can't even display https://launchpad.net/~mir-team/+archive/staging/+copy-packages [06:20] didrocks: Yes. [06:20] I can happily load that page . [06:20] urgh, not me, not yesterday, no today :/ [06:20] RAOF: hum, do you mind copying that yourself to daily-build-next? [06:20] Odd. [06:20] RAOF: I can add you to the team [06:20] Yeah, sure. [06:20] thanks a bunch :) [06:20] Just mesa + the X packages that you need, right? [06:21] RAOF: exactly! to https://launchpad.net/~ubuntu-unity/+archive/daily-build-next [06:22] And once Mir has landed in Universe I can just add the xmir patch to our regular xserver git, and all will be well. [06:22] RAOF: you need Mir to be landed in Universe? xmir depends on Mir? [06:22] not the other way around? [06:23] RAOF: no [06:23] RAOF: mir needs to be in main for that depends [06:23] mlankhorst: Oh, yeah, quite true. [06:23] didrocks: Yes, indeed. XMir depends on libmirclient. [06:23] ok, which is the stable API part :) [06:24] Correct. [06:24] RAOF: I think Mir entering main isn't an issue, I know an archive admin who as well reviewed and fixed the packaging for Main :p [06:36] Faster, laptop, faster! [06:40] RAOF: Are you sure you want to push your thermally challenged laptop so hard? ;) [06:41] I've chocked it up, and the kernel build has finished. It's only 65℃ now :) [06:44] ffs, why does swithcing to a guest session fix the input lag issue? [06:44] s/input lag/output lag [06:45] Hm. Does that suggest a Mir platform? [06:46] RAOF, ? [06:46] Because that's switching surface focus. [06:46] RAOF, it does ... let me check something [06:47] Notably, it *doesn't* stop X from rendering, unless Mir blocks it. [06:49] RAOF, yup [06:50] Does u-s-c block mir_surface_swap_buffers block when a surface isn't focused? [06:50] RAOF, checking exactly that [06:51] robert_ancell, ping [07:06] RAOF: It shouldn't block for obvious compositing reasons, but it does due to https://bugs.launchpad.net/mir/+bug/1188486 [07:06] Launchpad bug 1188486 in Mir "Unfocused apps are never visible on screen" [Medium,Triaged] [07:12] RAOF, might that be the reason that a switch to the guest session "aligns" things again? [07:12] Plausibly. [07:13] * RAOF wanders through the code while Mesa builds. [07:14] ... it's a general problem Mir has with unfocused clients getting paused. They shouldn't get paused, obviously [07:15] At least not by default [07:16] duflu, agreed, it should be a policy [07:18] good morning [07:22] woot, no more second cursor :) [07:27] tvoss_: So now just try to VT switch to tell if you're in Mir ;) [07:27] duflu, fair :) but htop tells me I'm in mir [07:28] wow, only one cursor ... this is so mainstream [07:30] It's so 20th century [07:33] duflu, exactly [07:33] duflu, my mind feels bored now ... [07:33] morning guys! [07:34] I just tried running mir in a VM [07:34] and it doesn't seem to start [07:34] is this expected for the moment? [07:35] pete-woods, yup [07:35] pete-woods, what vm are you trying? [07:36] tvoss_: it's parallels - it has a fantastic pass-through GLX driver [07:36] obviously I've uninstalled that for trying out Mir [07:37] so I was expecting it to run with fbdev/llvmpipe like X11 does [07:37] pete-woods, we need a driver capable of gbm/drm/kms [07:37] pete-woods: It is planned, but not implemented yet [07:38] tvoss_, duflu: no worries guys, is this something we'd be trying to have ready for 13.10? [07:39] pete-woods: We will be trying yes, but I don't believe it's on the critical list [07:39] pete-woods, exactly what duflu said. The easiest way for us would be if the vm offers the required driver functionality and an XMir integration [07:39] duflu: that's fair enough - I'm really just a very interested party here [07:40] pete-woods: https://bugs.launchpad.net/mir/+bug/1118903 [07:40] Launchpad bug 1118903 in Mir "Mir lacks a software rendering backend" [High,Triaged] [07:43] Oooooh. [07:43] Hm. [07:43] RAOF, ? [07:44] So, because threading and X is a world of pain, we push events through a pipe. [07:45] * tvoss_ listens excitedly to RAOF [07:45] Which obviously happens asynchronously. [07:46] But that's ok, because we register the pipe as a general socket, and have a wakeup handler. [07:48] So, what happens is we receive the buffer on a thread. We push this through the pipe, which wakes up the server if it's not already busy... [07:49] So what I should check is whether we should *also* be registering a BlockHandler to check the pipe before the server goes into select. [07:49] Although my understanding is that it should just immediately wake up. [07:50] But first, Zoë bath.\ [07:53] didrocks, ah, I was looking at an out-of-date version of unity8 which didn't have setup.py [07:53] tvoss_, hellp [07:54] hello [07:54] robert_ancell: be on the edge! (yeah, it's something I fixed) :-) === alan_g|EOD is now known as alan_g [08:10] robert_ancell, you running in XMir? [08:10] tvoss_, not this very second [08:10] robert_ancell, I've got a patched libmirserver package that disables input for the usc and the second cursor [08:11] robert_ancell, need some mileage to make sure that the lag does not show up anymore [08:11] tvoss_, I never remember noticing the lag [08:11] robert_ancell, weird [08:14] robert_ancell, still, some mileage would be great :) [08:15] tvoss_, email me the link [08:15] robert_ancell, the package :) [08:16] tvoss_, just send the branch, it will be easier to compile here [08:16] robert_ancell, not a branch yet, patched the src package from the system compositor testing ppa [08:16] tvoss_, don't you build from the branch? [08:17] robert_ancell, nope, I did an apt-get source libmirserver0 and patched the package, it's really a hack right now, would need to be handled in usc and shouldn't go into mir at all [08:18] tvoss_, so can't you just do a bzr branch, make the change, commit and push somewhere? [08:23] robert_ancell, https://code.launchpad.net/~thomas-voss/mir/disable-input-by-default [08:23] * tvoss_ notes that this is hacky and should be cleanly done in the unity-system-compositor server configuration [08:33] brb [08:37] RAOF: do you mind telling me once everything is copied so that I can run the tests? [08:37] didrocks: Sure [08:37] thanks! [08:39] Hm. Where did my xorg-server upload disappear to? [08:42] RAOF: never heard about the launchpad black hole? ;) [08:42] Ah. sacuy ≠ saucy :( [08:42] RAOF, :) [08:42] RAOF: so close, should have worked! :-) [09:11] tvoss_: ping [09:11] alan_g, grabbing coffee :) mind opening a hangout and inviting me, would like to use the ipad [09:12] tvoss_: ack [09:15] alan_g, can you call again please? [09:16] tvoss_, I'm still seeing a similar delay [09:16] robert_ancell, hmmm, is that a new issue for you? you said you haven't seen it before, right? [09:17] tvoss_, now I try it I do remember it [09:17] but I tried both, and I'm not seeing any major difference [09:18] didrocks: Everything's in the PPA now; enjoy. [09:18] RAOF: \o/ I'll for sure, thanks! [10:46] \o/ networking and cursor now working again on my laptop [10:49] tvoss_, ping [10:55] katie, pong [10:56] tvoss_, hi. are we having our meeting in 5 mins? [10:56] katie, if you want to, yes. I still owe you a review, though. Anything urgent to discuss? [10:57] tvoss_, i do have a couple of general questions, so yes, would still like a quick chat [10:57] sure [10:57] can you invite me to the hangout then? [10:57] sure, thanks === greyback is now known as greyback|lunch [11:28] alf_: are you happy to top approve move-graphicsplatform-dependencies-to-graphics-less-contentious? [11:29] alan_g: sure, [11:30] alan_g: do you want me to do it? [11:33] alf_: that would make me happy too [11:35] Oh! /o\ only *wireless* and g3 networking is working. Laptop still doesn't do wired networking. === greyback|lunch is now known as greyback [11:42] alan_g: (done) [11:45] * duflu wanders off dazed [11:46] duflu was still up?! No wonder he's dazed [11:59] alf_: just looking at gl_pixel_buffer.cpp and see a runtime test "is_big_endian()" - shouldn't that be detected at compile time? === alan_g is now known as alan_g|lunch [12:07] alan_g: We could, although ARM CPUs are bi-endian, but I am not sure if this is a scenario we have to care about. === Guest70312 is now known as Debolaz [13:13] kgunn: hey, around? === alan_g|lunch is now known as alan_g [13:34] didrocks: yeah [13:35] kgunn: so, I have a good news and a bad news :) [13:35] kgunn: good news is that the tests failing were finally flacky tests it seems [13:35] the bad news is that with thomi's script, we have the confirmation that mir isn't running [13:36] https://jenkins.qa.ubuntu.com/job/autopilot-saucy-daily_release/501/ [13:37] can be a config issue, but would be better to debug with someone knowing how lightdm runs unity-system-compositor [13:49] kgunn, hi [13:49] ahem [13:49] mterry: hey...your here :) [13:50] * kgunn suffering irc ping-tsunami [13:51] mterry: so didrocks having u-s-c/mir failing to start on his autopilot daily release testing [13:52] wondered if you've tinkered enough to have a look [13:52] https://jenkins.qa.ubuntu.com/job/autopilot-saucy-daily_release/501/ [13:52] couldn't hurt... [13:52] didrocks: how to get the log files off that machined? [13:53] didrocks: we'd need the usual suspects in /var/log/lightdm [13:53] kgunn: we have them [13:53] mterry: hey hey! :) [13:53] mterry: one sec, just grabbing my coffee ;) [13:54] didrocks: please don't scare mterry :)) [13:54] * mterry runs into the brush [13:54] kgunn: I've scared hum for many years now you know :p [13:54] first on the OEM side, he was taking unity from my packaging [13:54] I think he was scared from that date :p [13:55] s/hum/him/ === jono is now known as Guest30113 [13:56] didrocks: actually i should ask...have you simply done a subsequent reboot on that machine ? [13:57] bschaefer & robotfuel were seeing yesterday that [13:57] on a few machines xmir wouldn't come up after initial dist-upgrade [13:57] but then after second reboot it would [13:57] and then it was fine thereafter [13:57] didrocks, so I see two failures, test_running_hardware_check and a 'unity_system_compositor' test [13:58] Oh, maybe those are the same [13:58] mterry: they are, on the 2 configs :) [13:59] kgunn: in fact, we install the packages before lightdm starts [13:59] didrocks, but I don't see the /var/log/lightdm stuff in the archive.zip file [13:59] mterry: ok, so in the log, you can see http://10.97.4.139/otto/saucy-i386-20130718-1122 [13:59] mterry: I: Archive of the container to run this test available for download from: [13:59] oh man, ok [14:00] mterry: we can collect lightdm logs in the next run if needed [14:00] mterry: this is simple config file [14:00] kgunn: can you tell, I'll be 5 minutes late? [14:00] mterry: here, you have in archive/ all the delta from the base image [14:00] (it's an overlayfs) [14:01] as in the logs: [14:01] I: Run archived as ubuntu_13.10_saucy_salamander_alpha_i386_20130718.1374153658.otto [14:01] mterry: so you want http://10.97.4.139/otto/saucy-i386-20130718-1122/archive/ubuntu_13.10_saucy_salamander_alpha_i386_20130718.1374153658.otto I guess [14:01] mterry: this is just a tar, untar it (for some reason, file-roller doesn't like that it's ending up with .otto) [14:01] didrocks, .otto is weird, yah :) [14:01] and you should have all the delta from the base image [14:02] didrocks: ack [14:02] mterry: because the archive can be use to rerun the same tests on your machine [14:02] :) [14:02] it has some metatada ;) [14:03] we are using lightdm from distro FYI [14:03] which is enough from what robert told [14:05] didrocks: lightdm from distro...yeah [14:05] it better be :) that's what his instructions say [14:26] didrocks, well, I downloaded/unpacked the logs and the error we get from u-s-c is: [14:26] ERROR: /build/buildd/mir-0.0.7+13.10.20130718ubuntu.unity.next/src/server/graphics/gbm/gbm_display_helpers.cpp(284): Throw in function int mir::graphics::gbm::helpers::DRMHelper::open_drm_device(const mir::graphics::gbm::helpers::UdevHelper&) [14:26] Dynamic exception type: boost::exception_detail::clone_impl > [14:26] std::exception::what: Error opening DRM device [14:26] [boost::errinfo_errno_*] = -13, "Unknown error -13" [14:26] So... didrocks, looks like you have an unknown error. [14:26] * mterry goes home [14:27] mterry: thanks! that's helpful :) [14:28] didrocks, more seriously, I haven't run into an error opening DRM device before [14:28] jibel: do you think it's linked to lxc? ^ [14:28] racarr, ^ is that error familiar to you? [14:29] mterry: we are running in a lxc container with otto, it's working fine with acceleration for compiz & others [14:29] mterry: but maybe this has influence [14:30] didrocks, maybe a permission error on some udev device in the container? [14:30] didrocks, it is possible, it is what I reported to thomi last week [14:30] mterry: yeah, if you use more than what is used [14:30] mterry: any idea what's under used? [14:30] use* [14:30] didrocks, I didn't parse that [14:31] mterry: do you know exactly which udev device you need? [14:33] didrocks, not exactly... something inside /dev/drm/card[0-9] or some such, looking at code [14:33] jibel: do you think we should get stgraber as well to help? [14:34] mterry, which job did you get this message from? [14:35] jibel: 501 [14:35] /var/log/lightdm [14:35] (from the archive) [14:43] kdub, do you know more about the above error message? ^ [14:45] mterry: is is that hidden in the code? [14:47] :) [14:47] * didrocks tries to branch mir to look as well [14:49] didrocks, well, it just enumerates some devices and errors out if problems [14:49] didrocks, so hard to see what's the exact issue by looking at code [14:49] mterry: yeah, I wonder how we can debug that, I'm sure it's lxc/udev in lxc which doesn't authorize the right dev/ [14:50] didrocks, build a version with better debugging? strace it? [14:50] mterry: do you want debug symbols? :) [14:50] I can have that for you! [14:51] didrocks, not symbols but just printfs saying what it is doing [14:51] but stracing would likely be easier [14:51] just insert that into the jenkins job [14:51] mterry: you can get access to the machine if needed [14:51] by ssh [14:51] and running inside the container [14:51]