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