[00:22] <dmj_nova1> Does anyone know exactly what widgets are supported in app indicators?
[01:12] <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)
[09:17] <tsdgeos> is there any way other than logginout+login to clear a program that obviously is not running from the launcher?
[09:19] <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:30] <Mirv> tsdgeos: possibly alt+f2 unity and/or killing/restarting bamfdaemon
[09:32] <tsdgeos> Mirv: yeah restarting unity worked, now let me see if i can reproduce how to get that ghost in there
[09:34] <tsdgeos> which obviously i can't :-/
[11:04] <tsdgeos> Mirv: what about this simple thingie? https://code.launchpad.net/~aacid/unity/initialize_using_nofilters_background/+merge/132298
[11:09] <Mirv> tsdgeos: looks good
[11:10] <Mirv> it's then read from style
[13:28] <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?
[14:00] <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:02] <fginther> mterry, thanks for checking on compiz. I wasn't sure about that one, it just looked 'different'
[14:09] <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:10] <didrocks> mterry: one sec, in a hangout, be back then :)
[14:31] <didrocks> mterry: oh just one
[14:31] <didrocks> mterry: someone need to change the big switch though
[14:32] <mterry> didrocks, OK.  I'll mark a couple build modernization branches then
[14:32] <didrocks> mterry: sure :)
[14:33] <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:36] <didrocks> hey bregma
[14:36] <bregma> hey didrocks
[14:36] <didrocks> bregma: did you see bug #132978?
[14:36] <didrocks> hum
[14:36] <didrocks> bug #1076129 rather
[14:37] <bregma> saw it, looks like some bad assumptions somewhere
[14:37] <didrocks> bregma: do you have someone working on it?
[14:37] <didrocks> either fixing the test or the code :)
[14:38] <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:39] <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:40] <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:41] <didrocks> mterry: ah…
[14:42] <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:43] <didrocks> mterry: ok, it was my bet
[14:44] <bregma> sounds like the animation code has some serious flaws, 'cos floating point results can be very different on arm vs. intel, too
[14:46] <didrocks> mterry: removed the override and pushed, that's what happen when you try different parameters to filter and nothing worked :p
[14:50] <didrocks> mterry: thanks
[14:54] <mterry> fginther, https://code.launchpad.net/~mterry/dee/modern-build/+merge/133344 seems like a recipe failure
[14:56] <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:57] <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:58] <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:59] <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
[15:00] <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:02] <didrocks> mterry: (and python3 was already as build-dep, I think you saw that changing back the status :p)
[15:03] <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:04] <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:05] <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:13] <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:14] <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:15] <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:16] <didrocks> I don't think so as well, just trying to find the eventual difference :)
[15:21] <didrocks> grrr, when you resubmit a MR, it ignores the commit message…
[15:29] <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:30] <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:31] <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:32]  * 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:33] <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:35] <seb128> didrocks, mterry: running tests under dbus-test-runner seems to work
[15:35] <seb128> you should do that
[15:36] <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:37] <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:38] <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:39] <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:40] <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:41] <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:43] <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:44] <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:45] <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:46] <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:48] <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:49] <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:50] <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:51] <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:52] <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:53] <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:54] <didrocks> mterry: yeah, basically the versionning will be:
dailydd.mm.yy(.1…)
[15:54] <didrocks> so always a new version
[15:54] <mterry> didrocks, branch updated, try now
[15:55] <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:57] <seb128> hum, I should do some sponsoring as well, I missed my shift during UDS and that would make Daniel happy
[16:02] <didrocks> mterry: built! approving :)
[16:02] <mterry> didrocks, yay!  I hope the dbus thing is just a weird seb-specific issue
[16:03] <didrocks> mterry: I guess we'll see soon :)
[16:04] <seb128> didrocks, mterry: in any case it's easy to workaroud with dbus-test-runner
[16:04] <mterry> yar
[16:08] <conscioususer> mpt: le ping
[16:27] <mterry> fginther, is https://code.launchpad.net/~mterry/libunity/enable-tests/+merge/133350 jenkins failure just a recipe not being updated?
[16:30] <fginther> mterry, yes. I fixed the job and re-approved the MP
[16:30] <mterry> thanks!
[16:42] <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
[17:04] <mterry> fginther, again with that libunity update, though a different error
[17:05] <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:06] <mterry> thanks!
[17:27] <fginther> mterry, one more time...
[17:27] <mterry> :)
[17:58] <fginther> mterry, libunty MP failed again, but this time it's a unit test failure, not a jenkins infrastructure issue
[17:59] <mterry> fginther, yay?
[17:59] <mterry> fginther, I'll look into it in a bit
[17:59] <fginther> :-P one step closer
[18:30] <conscioususer> mpt, you online?
[20:53] <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:54] <fginther> I think some CMakeLists.txt changes in rev 2884 might be the cause
[21:07] <fginther> andyrock, bschaefer, charles, thumper, anybody ^^ ?
[21:07] <thumper> morning fginther
[21:08] <fginther> good afternoon, sorry for the blast-o-gram
[21:09] <fginther> I think the unity broken-ness could be impacting all builds
[21:09]  * thumper is looking at bzr log
[21:10] <fginther> 2884 is the last merger
[21:13] <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:14] <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:15] <fginther> thumper, to lp:unity?
[21:15] <thumper> yeah
[21:16] <fginther> sure
[21:16] <thumper> fginther: alternatively you could comment out those 5 lines added to the base CMakeLists.txt
[21:18] <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:26] <andyrock> fginther, hey
[21:27] <fginther> andyrock, hello
[21:27] <fginther> thumper helped me out
[21:27] <andyrock> ok sorry i was afk
[21:30]  * bschaefer just got back from lunch
[22:03] <fginther> thumper, can you take a look please: https://code.launchpad.net/~fginther/unity/unity-revert-gtest/+merge/133576
[22:11] <bschaefer> fginther, I can approve it if you need
[22:12] <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:13] <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:14] <fginther> bschaefer, thanks!
[22:14] <bschaefer> though nux has those dependencies
[22:14] <bschaefer> shouldn't unity have those as well?
[22:15] <bschaefer> fginther, ^
[22:16] <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:17] <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:18] <bschaefer> sounds like mine
[22:18] <bschaefer> but half has long
[22:18] <thumper> :)
[22:18] <bschaefer> half as*
[22:23] <thumper> fginther: the nux branch you reapproved failed landing again
[22:31]  * fginther looks at nux branches...
[22:35] <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] <thumper> fginther: ok, ta