| dmj_nova1 | Does anyone know exactly what widgets are supported in app indicators? | 00:22 |
|---|---|---|
| thumper | dmj_nova1: charles may be able to help there | 01:12 |
| thumper | dmj_nova1: but past his EOD I think | 01:12 |
| thumper | dmj_nova1: depending on your TZ, lars could help when he gets up (europe time) | 01:12 |
| tsdgeos | is there any way other than logginout+login to clear a program that obviously is not running from the launcher? | 09:17 |
| dmj_nova1 | larsu: Do you know exactly what widgets are supported in app indicators? | 09:19 |
| larsu | dmj_nova1, no, sorry, I don't | 09:19 |
| Mirv | tsdgeos: possibly alt+f2 unity and/or killing/restarting bamfdaemon | 09:30 |
| tsdgeos | Mirv: yeah restarting unity worked, now let me see if i can reproduce how to get that ghost in there | 09:32 |
| tsdgeos | which obviously i can't :-/ | 09:34 |
| === dbarth__ is now known as dbarth | ||
| === mike_ is now known as Guest69661 | ||
| === mike is now known as Guest50749 | ||
| tsdgeos | Mirv: what about this simple thingie? https://code.launchpad.net/~aacid/unity/initialize_using_nofilters_background/+merge/132298 | 11:04 |
| Mirv | tsdgeos: looks good | 11:09 |
| Mirv | it's then read from style | 11:10 |
| === _salem is now known as salem_ | ||
| === mmrazik is now known as mmrazik|lunch | ||
| === mmrazik|lunch is now known as mmrazik | ||
| === MacSlow is now known as MacSlow|lunch | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === mpt_ is now known as mpt | ||
| ppd | hi, quick question: Is the current shortcut behaviour of unity desired? I can't define shortcuts as a single keypress. I always need a modifier too. So is this by design or just a bug? | 13:28 |
| === MacSlow|lunch is now known as MacSlow | ||
| mterry | fginther, hello! So about the PPA upload issues: you were right about unity-lens-applications having out-of-date packaging, and I have a merge out there for that. But compiz looks up to date to me | 14:00 |
| fginther | mterry, thanks for checking on compiz. I wasn't sure about that one, it just looked 'different' | 14:02 |
| mterry | didrocks, what's the protocol for reviews? How many approvals before the branch can be marked as approved? (And does that happen automatically by a bot or manually?) | 14:09 |
| didrocks | mterry: one sec, in a hangout, be back then :) | 14:10 |
| didrocks | mterry: oh just one | 14:31 |
| didrocks | mterry: someone need to change the big switch though | 14:31 |
| mterry | didrocks, OK. I'll mark a couple build modernization branches then | 14:32 |
| didrocks | mterry: sure :) | 14:32 |
| mterry | didrocks, and once the big switch is pulled, the bot takes over, right? | 14:33 |
| didrocks | mterry: I didn't push them for all as I wasn't sure that after the first merge, everything was all right on jenkins side | 14:33 |
| didrocks | mterry: yep :) | 14:33 |
| didrocks | mterry: btw, reproposed: https://code.launchpad.net/~didrocks/dee/add_python_3/+merge/133491 | 14:33 |
| didrocks | hey bregma | 14:36 |
| bregma | hey didrocks | 14:36 |
| didrocks | bregma: did you see bug #132978? | 14:36 |
| ubot5 | Launchpad bug 132978 in Open Library "timestamp is missing the tdb.log" [Critical,Fix released] https://launchpad.net/bugs/132978 | 14:36 |
| didrocks | hum | 14:36 |
| didrocks | bug #1076129 rather | 14:36 |
| ubot5 | Launchpad bug 1076129 in Nux "nux autolanding builds encounter make check-headless failures on i386 builds" [Undecided,New] https://launchpad.net/bugs/1076129 | 14:36 |
| bregma | saw it, looks like some bad assumptions somewhere | 14:37 |
| === dandrader is now known as dandrader|lunch | ||
| didrocks | bregma: do you have someone working on it? | 14:37 |
| didrocks | either fixing the test or the code :) | 14:37 |
| didrocks | mterry: looking at libunity again, one sec | 14:38 |
| bregma | my team is studiously avoiding touching nux except where necessary to fix our bugs | 14:38 |
| bregma | so we don't tread on other people's toes | 14:38 |
| bregma | so no, I don;t have anoyone looking at that issue | 14:39 |
| mterry | didrocks, bregma: I looked at that, it's a floating point rounding error | 14:39 |
| mterry | Not sure how to fix yet | 14:39 |
| didrocks | bregma: didn't we assign someone to nux in your team? is anyone looking at it? | 14:40 |
| didrocks | mterry: at STR_EQUAL? comparaison? | 14:40 |
| didrocks | bregma: I'm concerned that nobody in the 13.04 team isn't actively looking at nux | 14:40 |
| bregma | didrocks, nobody is on nux in my team because of INFORMATION REDACTED | 14:40 |
| mterry | didrocks, the rounding isn't happening in the test code, but rather in (for at least one of the failures) AnimateValue. | 14:40 |
| didrocks | mterry: ah… | 14:41 |
| bregma | bugs in nux need to go to Tim's team right now | 14:42 |
| mterry | didrocks, so it's not as simple as switching EQ to FLOAT_EQ or whatever. And it happens in template-based code so it's hard to specifically say "round from float to int" | 14:42 |
| didrocks | mterry: ok, it was my bet | 14:43 |
| bregma | sounds like the animation code has some serious flaws, 'cos floating point results can be very different on arm vs. intel, too | 14:44 |
| didrocks | mterry: removed the override and pushed, that's what happen when you try different parameters to filter and nothing worked :p | 14:46 |
| didrocks | mterry: thanks | 14:50 |
| mterry | fginther, https://code.launchpad.net/~mterry/dee/modern-build/+merge/133344 seems like a recipe failure | 14:54 |
| fginther | mterry, you are correct. It should be fixed now and re-approved. | 14:56 |
| didrocks | mterry: so failure on libunity here | 14:56 |
| mterry | didrocks, :( | 14:56 |
| didrocks | mterry: oh, I build with -j… | 14:57 |
| didrocks | let me look at the exec first | 14:57 |
| didrocks | (shouldn't impact tests though) | 14:57 |
| didrocks | ls -l ./test/python/bug-1062331.py | 14:58 |
| didrocks | -rw-rw-r-- 1 pbuilder pbuilder 263 Nov 8 14:40 ./test/python/bug-1062331.py | 14:58 |
| didrocks | mterry: ^ | 14:58 |
| didrocks | so definitively not executable in my pbuilder | 14:58 |
| mterry | hm | 14:58 |
| mterry | because I think it tries to exec them directly | 14:58 |
| mterry | yeah it does | 14:58 |
| didrocks | yeTESTS = bug-1062331.py extras.py | 14:59 |
| didrocks | so yeah, that's what should happen | 14:59 |
| mterry | didrocks, so if they aren't executable, that's your problem. Are they executable outside the pbuilder? | 14:59 |
| didrocks | hum, they are | 14:59 |
| didrocks | in the branch I took from you | 15:00 |
| didrocks | but not when I bzr bd --builder pdebuild | 15:00 |
| didrocks | how do you use pbuilder? you don't have that issue? | 15:00 |
| didrocks | mterry: (and python3 was already as build-dep, I think you saw that changing back the status :p) | 15:02 |
| mterry | didrocks, yeah I think I commented too | 15:03 |
| mterry | didrocks, sorry, brain fair | 15:03 |
| mterry | brain fart even | 15:03 |
| didrocks | mterry: still relying on email and launchpad is slower on that :) | 15:03 |
| didrocks | mterry: no worry! you did some amazing job with all those MR! :) | 15:03 |
| mterry | didrocks, thanks. Not done yet though! :) | 15:04 |
| didrocks | a lot done :) | 15:04 |
| mterry | didrocks, about libunity, I use my pbuilder-scripts, which call pbuilder directly without bzr bd | 15:04 |
| didrocks | mterry: ah, maybe that's the difference, let me try | 15:04 |
| didrocks | ah, doesn't work so well with split mode though :p | 15:05 |
| didrocks | mterry: I'm afraid the same will happen on the merger then | 15:05 |
| didrocks | mterry: same with plain pdebuild for me, do you know of anything that can strip those? I looked again at my .devscript and .pbuilderrc but don't see anything | 15:13 |
| mterry | didrocks, no. it's in the upstream tarball which normally (like, via 'make dist' style) keeps them | 15:14 |
| mterry | didrocks, I mean, "in the upstream source" | 15:14 |
| mterry | didrocks, wait, I use pdebuild too | 15:14 |
| didrocks | yeah, I wonder why I'm seeing something different here… | 15:14 |
| didrocks | mterry: you pbuilder are created with the buildd environment, right? | 15:15 |
| mterry | yes. but that shouldn't affect this I shouldn't think | 15:15 |
| didrocks | I don't think so as well, just trying to find the eventual difference :) | 15:16 |
| === dandrader|lunch is now known as dandrader | ||
| didrocks | grrr, when you resubmit a MR, it ignores the commit message… | 15:21 |
| didrocks | mterry: seems seb128 has the same issue with pdebuild. Do you have time to look at why? (I can look, but surely not today, maybe tomorrow morning) | 15:29 |
| seb128 | just for the record I didn't use pdebuild | 15:30 |
| seb128 | but I logged into pbuilder and did a debuild manually there (like to do that because it doesn't wipe my env when the build ends) | 15:30 |
| didrocks | seb128: brz bd --builder pdebuild isn't the command I gave you? | 15:30 |
| mterry | didrocks, I can try... I have to do sponsoring today and I'm out tomorrow, so might not get to it, but no biggie. Just the libunity merge is held up by it | 15:30 |
| didrocks | ah ok :) | 15:30 |
| seb128 | didrocks, well, I assumed you wanted a build in pbuilder rather than the exact command ;-) | 15:30 |
| seb128 | didrocks, so I sticked to my usual workflow ;-) | 15:30 |
| didrocks | mterry: no worry, just drop me an email if you can't do it today, so that I remind to do that tomorrow :) | 15:31 |
| didrocks | seb128: well, I think that's close enough to pdebuild anyway | 15:31 |
| seb128 | yeah | 15:31 |
| * didrocks goes back to the automation/jenkins/launchpad party | 15:32 | |
| mterry | didrocks, well no... pbuilder won't magically destroy the executable bit, but when pdebuild bundles up the source, it might very well | 15:32 |
| mterry | didrocks, seb128: so those two very well might give different results | 15:32 |
| mterry | (I mean, logging into pbuilder won't destroy the executable bit) | 15:32 |
| seb128 | # ./test-vala | 15:33 |
| seb128 | ... | 15:33 |
| mterry | unless you only have +x for your user/group and not root? | 15:33 |
| seb128 | Error spawning command line `dbus-launch --autolaunch=59e939bd4642e27890eb8f84509bcf30 --binary-syntax --close-stderr': Child process exited with code 1 (g-spawn-exit-error-quark, 1) | 15:33 |
| seb128 | unity-launcher.c: line 1250 | 15:33 |
| seb128 | didrocks, mterry: running tests under dbus-test-runner seems to work | 15:35 |
| seb128 | you should do that | 15:35 |
| mterry | oh... so your error wasn't related to the executable bit? | 15:36 |
| seb128 | mterry, no, mine it's "Unable to connect to session bus: Could not connect: Connection refused" | 15:36 |
| mterry | Three people, three different results. :) | 15:36 |
| seb128 | mterry, indicator-sync already use dbus-test-runner if you want an example | 15:37 |
| seb128 | override_dh_auto_test: | 15:37 |
| seb128 | dbus-test-runner -m 300 -t dh_auto_test | 15:37 |
| seb128 | basically | 15:37 |
| mterry | sure... I don't see that error so I didn't think it was needed... | 15:37 |
| seb128 | mterry, do you have a session bus in your pbuilder? | 15:37 |
| mterry | seb128, I don't know why I would | 15:38 |
| seb128 | mterry, it's weird that the tests work without one for you | 15:38 |
| mterry | seb128, agreed (I didn't notice they needed dbus so I didn't ask questions). I'll look at the branch again later | 15:39 |
| seb128 | didrocks, mterry: vala tests success for me with | 15:40 |
| seb128 | override_dh_auto_test: | 15:40 |
| seb128 | dbus-test-runner -t dh_auto_test | 15:40 |
| seb128 | but then the python ones fail | 15:40 |
| seb128 | /bin/bash: line 9: ./bug-1062331.py: Permission denied | 15:40 |
| seb128 | task-0: FAIL: bug-1062331.py | 15:40 |
| dmj_nova1 | charles: Do you know what widgets can be put in app indicators? | 15:40 |
| seb128 | same for extras.py | 15:40 |
| mterry | seb128, aha! that was the permissions issue that we were looking into | 15:40 |
| mterry | seb128, it seems that the executable bit is lost for some reason | 15:41 |
| seb128 | you shouldn't rely on it, just call python test.py...? | 15:41 |
| seb128 | mterry, didrocks: well "the executable bit is lost for some reason" is an obvious reason | 15:43 |
| seb128 | mterry, didrocks: you have those files in the diff.gz and diff doesn't handle permissions | 15:43 |
| seb128 | dpkg-source: warning: executable mode 0775 of 'test/python/bug-1062331.py' will not be represented in diff | 15:43 |
| mterry | seb128, why are they in diff.gz? they should be in orig.tar.gz | 15:43 |
| mterry | seb128, does split mode put everything in a diff? | 15:43 |
| seb128 | mterry, because | 15:44 |
| seb128 | $ tar tzf libunity_6.10.0.orig.tar.gz | grep test | grep python | 15:44 |
| seb128 | $ | 15:44 |
| seb128 | mterry, where do you got your tarball? | 15:44 |
| seb128 | the archive one doesn't have python tests | 15:44 |
| mterry | seb128, I just run pdebuild | 15:44 |
| mterry | seb128, on a bzr checkout | 15:45 |
| seb128 | did you get* | 15:45 |
| seb128 | mterry, I guess it's building the pristine tarball from the 6.10.0 tag | 15:45 |
| seb128 | or getting it from the archive | 15:45 |
| seb128 | mterry, in any case 6.10.0 doesn't contain those files, that's why they are in the diff | 15:45 |
| mterry | seb128, I bet it's recreating it from scratch, because I don't have the 6.10.0 orig tarball hanging around | 15:45 |
| mterry | seb128, OK. So executable thing is a non-issue then. didrocks ^ | 15:46 |
| mterry | seb128, which doesn't explain why you got dbus issues while didrocks and I did not | 15:46 |
| seb128 | mterry, it should be just fine once you do a release with those in the tar | 15:46 |
| mterry | seb128, yeah, and for the moment, we're concerned about automated tests from trunk, where it also won't be an issue | 15:46 |
| seb128 | mterry, | 15:48 |
| seb128 | Program received signal SIGTRAP, Trace/breakpoint trap. | 15:48 |
| seb128 | 0xb7ca53fd in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0 | 15:48 |
| seb128 | (gdb) bt | 15:48 |
| seb128 | #0 0xb7ca53fd in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0 | 15:48 |
| seb128 | #1 0xb7ca5583 in g_log () from /lib/i386-linux-gnu/libglib-2.0.so.0 | 15:48 |
| seb128 | #2 0xb7f7f0f3 in unity_launcher_entry_constructor (type=134653544, | 15:48 |
| seb128 | n_construct_properties=1, construct_properties=0x806f9b0) | 15:48 |
| seb128 | at unity-launcher.c:1250 | 15:48 |
| mterry | seb128, that's from the dbus failure? | 15:49 |
| seb128 | yes | 15:49 |
| seb128 | can you run "dbus-monitor --session" from your pbuilder? | 15:49 |
| didrocks | seb128: urgh, I didn't see that even if I modify the versioning to 6.12 to discare that case, it did bring 6.12 from an old test release I've done locally so was in the diff.gz again… :/ | 15:49 |
| didrocks | so I thought about it, but was trapped by a local tarball and didn't notice it was still in the diff :/ | 15:50 |
| seb128 | didrocks, no worry, glad we sorted it out ;-) | 15:50 |
| mterry | seb128, no, because dbus-monitor isn't installed by default (will install now and check). Though I do notice that DISPLAY=:0 | 15:50 |
| didrocks | yeah, thanks for noticing it :) | 15:50 |
| didrocks | mterry: so just bump to 6.11 the changelog and we'll be fine for this one | 15:50 |
| seb128 | mterry, same here... well dunno why dbus is working for you, it shouldn't in a pbuilder | 15:50 |
| seb128 | mterry, but anyway, if the tests work no worry, if they don't just add dbus-test-runner | 15:51 |
| mterry | seb128, well, dbus-x11 is a build-dep, so it should be pulled in and started if needed? | 15:51 |
| seb128 | unity-launcher.c: line 1250: unexpected error: Error spawning command line `dbus-launch --autolaunch=59e939bd4642e27890eb8f84509bcf30 --binary-syntax --close-stderr': Child process exited with code 1 (g-spawn-exit-error-quark, 1) | 15:52 |
| seb128 | 15:52 | |
| mterry | didrocks, why bump the changelog? Won't the auto-builders always use a fresh tarball? | 15:52 |
| seb128 | not sure why the autospawning doesn't work | 15:52 |
| didrocks | mterry: no, it will reconstruct the tarball for already published version | 15:52 |
| seb128 | mterry, though | 15:53 |
| seb128 | # dbus-launch --autolaunch=59e939bd4642e27890eb8f84509bcf30 --binary-syntax --close-stderr nano | 15:53 |
| mterry | didrocks, how will we handle auto-built versioning in future? We were going to have automatic changelog entries and such right? | 15:53 |
| seb128 | No protocol specified | 15:53 |
| seb128 | Autolaunch error: X11 initialization failed. | 15:53 |
| seb128 | # | 15:53 |
| seb128 | mterry, here | 15:53 |
| didrocks | mterry: yeah, basically the versionning will be: | 15:54 |
| didrocks | <major_upstream>dailydd.mm.yy(.1…) | 15:54 |
| didrocks | so always a new version | 15:54 |
| mterry | didrocks, branch updated, try now | 15:54 |
| seb128 | mterry, "xvfb-run dbus-launch ./test-vala" works | 15:55 |
| seb128 | well anyway, letting you guys continue on that, if you are interested by extra debug infos let me know | 15:55 |
| mterry | seb128, I will look at it later, I really should do my sponsoring shift or fear the wrath of dholbach | 15:55 |
| seb128 | hum, I should do some sponsoring as well, I missed my shift during UDS and that would make Daniel happy | 15:57 |
| didrocks | mterry: built! approving :) | 16:02 |
| mterry | didrocks, yay! I hope the dbus thing is just a weird seb-specific issue | 16:02 |
| didrocks | mterry: I guess we'll see soon :) | 16:03 |
| seb128 | didrocks, mterry: in any case it's easy to workaroud with dbus-test-runner | 16:04 |
| mterry | yar | 16:04 |
| conscioususer | mpt: le ping | 16:08 |
| === gatox is now known as gatox_lunch | ||
| mterry | fginther, is https://code.launchpad.net/~mterry/libunity/enable-tests/+merge/133350 jenkins failure just a recipe not being updated? | 16:27 |
| fginther | mterry, yes. I fixed the job and re-approved the MP | 16:30 |
| mterry | thanks! | 16:30 |
| tsdgeos_ | Mirv: there's also the 6.0 branch if we are interested https://code.launchpad.net/~aacid/unity/initialize_using_nofilters_background_6.0/+merge/132297 | 16:42 |
| mterry | fginther, again with that libunity update, though a different error | 17:04 |
| fginther | mterry, yep, I saw it also. I patched the scripts to resolve the issue. Hopefully it will go through now | 17:05 |
| fginther | I'll continue to watch it | 17:05 |
| mterry | thanks! | 17:06 |
| === gatox_lunch is now known as gatox | ||
| === dandrader is now known as dandrader|afk | ||
| fginther | mterry, one more time... | 17:27 |
| mterry | :) | 17:27 |
| === dandrader|afk is now known as dandrader | ||
| fginther | mterry, libunty MP failed again, but this time it's a unit test failure, not a jenkins infrastructure issue | 17:58 |
| mterry | fginther, yay? | 17:59 |
| mterry | fginther, I'll look into it in a bit | 17:59 |
| fginther | :-P one step closer | 17:59 |
| conscioususer | mpt, you online? | 18:30 |
| fginther | Hello, unity-team/staging is broken. Can someone help me figure out why? | 20:53 |
| fginther | log is here: https://launchpadlibrarian.net/122383545/buildlog_ubuntu-quantal-amd64.unity_6.10.0bzr2884pkg0quantal0_FAILEDTOBUILD.txt.gz | 20:53 |
| fginther | I think some CMakeLists.txt changes in rev 2884 might be the cause | 20:54 |
| === salem_ is now known as _salem | ||
| fginther | andyrock, bschaefer, charles, thumper, anybody ^^ ? | 21:07 |
| thumper | morning fginther | 21:07 |
| fginther | good afternoon, sorry for the blast-o-gram | 21:08 |
| fginther | I think the unity broken-ness could be impacting all builds | 21:09 |
| * thumper is looking at bzr log | 21:09 | |
| fginther | 2884 is the last merger | 21:10 |
| thumper | fginther: is libgtest-dev listed as a build dep? | 21:13 |
| fginther | thumper, no | 21:13 |
| thumper | fginther: it looks like what changed was something that was looked for with a test include now has a default value | 21:13 |
| thumper | fginther: so the search after doesn't find gtest and falls back to the default | 21:14 |
| thumper | then it tries to include a src dir which doesn't exist | 21:14 |
| thumper | hence the boom | 21:14 |
| thumper | fginther: can you add libgtest-dev and google-mock as build deps? | 21:14 |
| fginther | thumper, to lp:unity? | 21:15 |
| thumper | yeah | 21:15 |
| fginther | sure | 21:16 |
| thumper | fginther: alternatively you could comment out those 5 lines added to the base CMakeLists.txt | 21:16 |
| fginther | thumper, that sounds like a better alternative for now | 21:18 |
| thumper | fginther: that should get things working again | 21:18 |
| thumper | and we can add the build depends after | 21:18 |
| andyrock | fginther, hey | 21:26 |
| fginther | andyrock, hello | 21:27 |
| fginther | thumper helped me out | 21:27 |
| andyrock | ok sorry i was afk | 21:27 |
| * bschaefer just got back from lunch | 21:30 | |
| fginther | thumper, can you take a look please: https://code.launchpad.net/~fginther/unity/unity-revert-gtest/+merge/133576 | 22:03 |
| bschaefer | fginther, I can approve it if you need | 22:11 |
| fginther | bschaefer, thanks | 22:12 |
| bschaefer | fginther, that is fixing the issue? | 22:12 |
| fginther | I consider it a workaround. a better fix is needed (I'm creating a bug now) | 22:12 |
| fginther | but yes, the build proceeds past the point it was failing | 22:13 |
| bschaefer | fginther, hmm alright, ill confirm everything compiles and Ill merge it | 22:13 |
| fginther | bschaefer, thanks! | 22:14 |
| bschaefer | though nux has those dependencies | 22:14 |
| bschaefer | shouldn't unity have those as well? | 22:14 |
| bschaefer | fginther, ^ | 22:15 |
| fginther | bschaefer, are you sure nux has libgtest-dev and google-mock as build deps? I don't see it in lp:nux | 22:16 |
| bschaefer | hmm I know I use to have to manually install those | 22:16 |
| bschaefer | and a fresh install otherwise nux wont compile its tests | 22:16 |
| bschaefer | and I know nux uses google=mock for its tests... | 22:16 |
| fginther | bschaefer, that makes sense. most packages I'm familar with don't have dependencies on libs that are purely fur executing tests | 22:17 |
| bschaefer | oo that would explain that then | 22:17 |
| thumper | fginther: approved | 22:17 |
| TheMuso | What is the best list to send mail to if I want to discuss something about unity technically? | 22:17 |
| TheMuso | As in the technical workings of unity | 22:17 |
| thumper | fginther: nux should have them as build deps | 22:17 |
| thumper | fginther: they are needed for running the tests in make check | 22:17 |
| bschaefer | thumper, I was about to! | 22:17 |
| thumper | bschaefer: bet you to it | 22:17 |
| bschaefer | thumper, also how was your flight? | 22:17 |
| thumper | long and uneventful | 22:17 |
| bschaefer | sounds like mine | 22:18 |
| bschaefer | but half has long | 22:18 |
| thumper | :) | 22:18 |
| bschaefer | half as* | 22:18 |
| thumper | fginther: the nux branch you reapproved failed landing again | 22:23 |
| * fginther looks at nux branches... | 22:31 | |
| fginther | thumper, nux is failing due to https://bugs.launchpad.net/nux/+bug/1076129. I'm working with Jay to reproduce outside of jenkins | 22:35 |
| ubot5 | Ubuntu bug 1076129 in Nux "nux autolanding builds encounter make check-headless failures on i386 builds" [Critical,Triaged] | 22:35 |
| thumper | fginther: ok, ta | 22:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!