[03:16] <linuxdude> hello
[03:17] <smspillaz> argh, looks like I'll just have to rebase those compiz proposals, the bzr state is just totally screwed
[07:17] <mmrazik> didrocks: uh oh.. .Can't believe that launchpad diff and bzr diff are two different things
[07:17] <mmrazik> thats a bummer
[07:18] <didrocks> mmrazik: I was surprised as well, *really* surprised
=== vibhav is now known as Guest98376
=== Guest98376 is now known as vibhav
[09:38] <davidcalle> mhr3, ping
[09:38] <davidcalle> mhr3, any idea what could be the cause of https://bugs.launchpad.net/ubuntu/+source/unity-lens-photos/+bug/1135029
[09:38] <ubot5> Launchpad bug 1135029 in unity-lens-photos (Ubuntu) "Unity-lens-photos crashes on start, photos in dash is empty" [Undecided,New]
[09:39] <davidcalle> mhr3, "Couldn't find GType of implementor of interface UnityMergeStrategy."
[09:39] <davidcalle> Dependencies are up to date (Quantal).
[09:41] <mhr3> will take a look in an hour, gtg afk now
=== mmrazik is now known as mmrazik|otp
=== mmrazik|otp is now known as mmrazik
[10:56] <mhr3> davidcalle, i guess the problem didn't disappear by itself in the last hour? :)
[10:57] <davidcalle> mhr3, maybe it did, let's ask the reporter :)
[10:58] <davidcalle> mhr3, I've not been able to reproduce it
[10:58] <mhr3> davidcalle, it's weird though, the report says it's for 12.10, but if that were the case with standard 12.10 we'd see many more such reports
[10:59] <mhr3> i wouldn't be that much surprised if this happened with 13.04, pygi and glib like to change things :P
[11:00] <davidcalle> mhr3, https://bugzilla.gnome.org/show_bug.cgi?id=688978
[11:00] <ubot5> Gnome bug 688978 in Plugins (other) "im-status plugin fails to load" [Normal,Resolved: notabug]
[11:00] <davidcalle> mhr3, just found this
[11:01] <davidcalle> let's check the gobject version, because of http://blogs.gnome.org/desrt/2012/11/05/a-warning-about-glib/ (pitti's comment)
[11:02] <mhr3> so it seems the reported has new glib
[11:02] <mhr3> but old pygobject
[11:03] <davidcalle> mhr3, that was my guess, but I wanted your input in cas it was a merge strategy related thing
[11:03] <davidcalle> case*
[11:07] <davidcalle> mhr3, thanks :)
=== _salem is now known as salem_
[12:24] <MCR_> andyrock, I found an inconsistency regarding window focus handling - do you know if focus should be allowed if inputHint AND protocols & CompWindowProtocolTakeFocusMask are true, or if  inputHint OR protocols & CompWindowProtocolTakeFocusMask are true ?
[12:25] <MCR_> andyrock, because we have both versions in the code
[12:25] <MCR_> andyrock, see PrivateWindow::allowWindowFocus and CompWindow::isFocussable () const
[12:25]  * MCR_ is scratching his head...
[12:27] <MCR_> smspillaz, if you're here ^^
[12:27] <andyrock> one moment
[12:27] <MCR_> andyrock, thanks
[12:33] <andyrock> MCR_, IMHO it should be &&
[12:33] <andyrock> so allowWindowFocus should be correct
[12:33] <andyrock> let's check with bzr annotate
[12:33] <MCR_> andyrock, so both need to be true to allow focus and return true, yes ?
[12:33] <andyrock> yep
[12:34] <MCR_> ok
[12:34] <andyrock> MCR_, but i could be wrong ;)
[12:34] <MCR_> My first thought was the other way 'round TBH ;)
[12:37] <andyrock> MCR_, well bzr annotate will help trust me...
[12:37] <andyrock> doing it right now
[12:38] <MCR_> andyrock, thanks
[12:38] <MCR_> one thing is clear -> it cannot be both ways ;)
[12:38]  * MCR_ wonders which bugs this could potentially fix...
[12:39] <MCR_> here sometimes windows do not focus on click...
=== seb128_ is now known as seb128
[12:42] <andyrock> MCR_, i found this commit http://cgit.compiz.org/compiz/core/commit/?id=5e0264e2ceed6a44b1de50d6acc36684f6ccbf67
[12:44] <andyrock> so yes maybe it's ||
[12:45] <andyrock> btw there is no inconsistency
[12:46] <andyrock>     if (!priv->inputHint &&
[12:46] <andyrock> 	!(priv->protocols & CompWindowProtocolTakeFocusMask))
[12:46] <andyrock>     {
[12:46] <andyrock> 	return false;
[12:46] <andyrock>     }
[12:46] <andyrock> equals to
[12:46] <andyrock> (!(priv->input... || priv->pto...))
[12:46] <andyrock> MCR_, ^^^
[12:48] <andyrock> makes sense?
[12:50] <MCR_> andyrock, yes. thanks. I will rethink the boolean logic.
[12:50] <andyrock> MCR_, it's for De Morgan law
[12:50] <MCR_> yes, maybe I was too fast...
[12:51] <andyrock> (not A) and (not B) = not (A or B)
[12:51] <andyrock> ;)
=== dandrader_ is now known as dandrader
=== smspilla1 is now known as smspillaz
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== mmrazik is now known as mmrazik|afk
[15:17] <mterry> cyphermox, didrocks: I'm inclined to manually publish the unity stack, despite the indicator stack failing due to ido (the indicator stack does pass tests though).  Any objections?
[15:23] <cyphermox> mterry: not from me
[15:24] <cyphermox> mterry: what about hud daily tests?
[15:24] <mterry> cyphermox, did they fail?
[15:25] <cyphermox> err, I mean ted's comment on your optional-bustle branch
[15:25] <mterry> cyphermox, I replied in the merge, but tedg hasn't re-replied
[15:26] <mterry> cyphermox, I don't *think* it's a problem, we can work around it jenkins-side by manually having jenkins add the packages hud needs
[15:26] <cyphermox> yeah
[15:27]  * tedg replies
[15:29] <didrocks> mterry: no objection from me :)
[15:29] <didrocks> (yeah, I left late for exercising)
[15:29]  * mterry publishes
[15:30] <cyphermox> oops
[15:30] <mterry> ?
[15:30]  * mterry pauses over the button
[15:30] <cyphermox> can't run valgrind on armhf virtualized :/
[15:30] <cyphermox> mterry: unrelated
[15:30] <mterry> cyphermox, don't scare me like that  :)
[15:30] <cyphermox> please go ahead with the publish ;)
=== dandrader is now known as dandrader|afk
=== mmrazik|afk is now known as mmrazik
[16:21] <tedg> mterry, I heard that you might be working some more on the greeter.
[16:22] <tedg> mterry, Has anyone talked to you about the visualization stuff?
[16:22] <mterry> tedg, no?
[16:22] <tedg> mterry, I guess, that's perhaps a question, are you dealing with that part?  :-)
[16:22] <mterry> tedg, I mean yes, I'm looking at making the phablet greeter look more like the desktop, but no about visualization
[16:23] <tedg> mterry, Like the little wheel thing with tweets on it.
[16:23] <mterry> tedg, ah, the "infographic" -- I wasn't planning on doing anything with that
[16:24] <tedg> mterry, hmm, okay.  I'm not sure who is... we need to figure that out as well.
=== salem_ is now known as _salem
=== _salem is now known as salem_
[16:40] <didrocks> mmrazik: fginther: cu2d-update-stack is broken
[16:40] <didrocks> ImportError: No module named c2dconfigutils.c2dconfigutils
[16:40] <didrocks> as the module is in the parent dir
[16:40] <mmrazik> didrocks: already mentioned this to fginther in the latest MP
[16:41] <mmrazik> fginther: I guess lets just fix this now in separate MP...
[16:42] <mmrazik> didrocks: the workaround is to call the command from the parent dir
[16:42] <didrocks> mmrazik: not sure it will work, for the template and so on
[16:42] <mmrazik> daily-release/cu2d-update-stack
[16:42] <didrocks> mmrazik: I PYTHONPATH=..
[16:42] <mmrazik> right
[16:42] <didrocks> this works :)
[16:42] <mmrazik> yeah... pythonpath is better
[16:43] <didrocks> mmrazik: well, ideally, I should try running it in another dir and support that
[16:47] <jibel> I ran autopilot against the latest gtk stack from the desktop-ppa
[16:47] <jibel> https://jenkins.qa.ubuntu.com/job/desktop-ppa-autopilot-release-testing/2/label=autopilot-intel/artifact/results/artifacts/
[16:47] <jibel> and calls to proc = Gio.DesktopAppInfo.new(desktop_file) fails with TypeError: constructor returned NULL
[16:48] <jibel> any idea what it is ?
[16:48] <fginther> didrocks, so you're ok with the pythonpath workaround. I'll have the fix in my current MP
[16:48] <didrocks> mmrazik: do you mind switch compiz upstream merger from lp:compiz to lp:compiz/raring?
[16:48] <didrocks> fginther: ^
[16:48] <didrocks> fginther: thanks :)
[16:48] <jibel> sil2100, ^?
[16:50] <fginther> didrocks, sure, Are we waiting for confirmation from sil2100 ?
[16:51] <didrocks> fginther: for switching the branch? it's not related :)
[16:52] <yarinse> hi, where konversation keeps the configurations? in which folder
[16:52] <didrocks> yarinse: I think it's a question for #kubuntu :)
[16:52] <yarinse> didrocks: ok
[16:52] <sil2100> Back, been at my car, reading up
[16:54] <fginther> didrocks, something strange perhaps. jenkins is currently building https://code.launchpad.net/~ps-jenkins/compiz/latestsnapshot/+merge/151036
[16:54] <fginther> didrocks, but launchpad shows an empty diff for that MP
[16:54] <didrocks> fginther: oh? isn't that one merged?
[16:54] <didrocks> fginther: yeah, I saw 2 MP
[16:54] <didrocks> fginther: and TBH, I don't know why
[16:55] <didrocks> fginther: safe to kill and reject that one
[16:55] <seb128> jibel, any way you can run the tests without the new gtk and see if they still run?
[16:55] <fginther> didrocks, will do
[16:56] <didrocks> thx!
[16:59] <jibel> seb128, can do
[16:59] <seb128> didrocks, who can help on those unity tests?
[16:59] <seb128> mterry, ^
[16:59] <seb128> https://jenkins.qa.ubuntu.com/job/desktop-ppa-autopilot-release-testing/2/testReport/
[16:59] <seb128> 253 failing test
[17:00] <seb128> (that's a run with gtk 3.7)
[17:00] <seb128> they seem to boil down mostly to
[17:00] <seb128>  File "/usr/lib/python2.7/dist-packages/autopilot/emulators/bamf.py", line 187, in launch_application
[17:00] <seb128>     proc = Gio.DesktopAppInfo.new(desktop_file)
[17:00] <seb128>   File "/usr/lib/python2.7/dist-packages/gi/types.py", line 137, in constructor
[17:00] <seb128>     return info.invoke(cls, *args, **kwargs)
[17:00] <seb128> TypeError: constructor returned NULL
[17:00] <seb128>  
[17:00] <seb128> which from local testing happens when the Gio.DesktopAppInfo.new() argument is an invalid .desktop
[17:00] <seb128> but the behaviour is not new, gtk 3.6 behaves the same
[17:01] <didrocks> seb128: I think sil2100 is looking at that
[17:01] <seb128> sil2100, hey
[17:02] <sil2100> seb128: yes, I'm looking on it now, had a GPU lockup just now though
[17:03] <jibel> seb128, I'll re-enable the daily ppa of unity instead just in case there is something missing in the distro for autopilot
[17:03] <seb128> jibel, ok
[17:03] <sil2100> hmm
[17:11] <sil2100> Ok, so not sure what's wrong, but it seems it cannot start the Calculator application - as if its .desktop file was invalid
[17:11] <sil2100> It's using the gcalctool.desktop file which Gio.DesktopAppInfo.new sees as invalid
[17:11] <sil2100> The terminal application is fine though
=== dandrader|afk is now known as dandrader
[17:12] <jibel> sil2100, because it's simply not there
[17:12] <jibel> there is a gnome-calculator.desktop
[17:12] <sil2100> jibel: but I saw gcalctool in dpkg-list.log
[17:12] <sil2100> Oh
[17:13] <sil2100> Ok, so that solves it - gnome-calculator.desktop is the correct one? Since I think we always used gcalctool.desktop before and it worked
[17:13] <sil2100> My current gcalctool package installs /usr/share/applications/gcalctool.desktop
[17:14] <sil2100> ii  gcalctool                                 1:3.7.90-0ubuntu1 <- and it seemed installed on the build system?
[17:14] <sil2100> Oh, wait, I have a completely different version number of gcalctool on my local system
[17:15] <sil2100> I have 6.6.2-0ubuntu1 installed here
[17:15] <sil2100> rmadison says:
[17:15] <sil2100>  gcalctool | 6.6.2-0ubuntu1 |        raring | source
[17:15] <sil2100>  gcalctool | 1:3.7.90-0ubuntu1 |        raring | all
=== jhodapp is now known as jhodapp|food
[17:20] <sil2100> jibel: so, not sure what gcalctool 1:3.7.90-0ubuntu1 is really, since 6.6.2-0ubuntu1 seems like the right package
[17:20] <jibel> sil2100, that's what I'm checking
[17:21] <jibel> sil2100, oh, it's probably from the desktop team ppa
[17:21] <jibel> which is what we were testing
[17:21] <sil2100> jibel: so, hm, is gnome-calculator.desktop the new default that we should use?
[17:23] <sil2100> Since I don't even have gnome-calculator installed here, so it's not by default installed on the desktop? I have raring here
[17:23] <seb128> sil2100, yes, that program got renamed
[17:23] <sil2100> seb128: ok, so I'll prepare a merge request switching to gnome-calculator
[17:24] <sil2100> Since gcalctool won't be correct anymore, yes?
[17:24] <jibel> sil2100, simulation of an upgrade with the PPA http://paste.ubuntu.com/5573958/
[17:24] <seb128> right
[17:24] <jibel> it installs gnome-calculator and gcalctool becomes a dummy package
[17:25] <sil2100> jibel: ok, so I'll quickly patch up autopilot to use gnome-calculator
[17:25] <sil2100> Give me amoment
[17:25] <jibel> sil2100, great, thanks
[17:26] <jibel> sil2100, note that the new gnome-calculator is not is the release yet but will land soon-ish
[17:27] <sil2100> hm
[17:27] <sil2100> jibel: how soon is the soonish you mean?
[17:27] <seb128> jibel, sil2100: it has been promoted, it will be on the iso tomorrow
[17:27] <jibel> seb128, ^
[17:28] <sil2100> seb128: ok, so that's good, since we don't want to break unity releases in the meantime
[17:28] <seb128> sil2100, well, it's already in the archive so it should be already fine
[17:28] <sil2100> \o/
[17:28] <seb128> but the first iso with gnome-calculator with be the one tomorrow
[17:30] <sil2100> https://code.launchpad.net/~sil2100/autopilot/gcalctool_rename/+merge/151059
[17:31] <sil2100> seb128, jibel: I'll have to prepare a small merge request for lp:unity as well, since 2 tests are also using the desktop file directly there
[17:31] <sil2100> But those would result in only 2 additional failures I guess
[17:36] <naee> I'm writing a Qt app with a systray and I want it to play well with Unity
=== naee is now known as eean
[17:37] <eean> should I just disable the systray when it's on Unity? I could check for $DESKTOP_SESSION
[17:37] <eean> but I wonder if there's a preferred way
[17:40] <sil2100> https://code.launchpad.net/~sil2100/unity/autopilot_gcalctool_rename/+merge/151063 <- fix for the unity part
[17:40] <sil2100> fginther: ^
[17:40] <sil2100> fginther: could you take a look at those merges?
[17:41] <sil2100> fginther: also, if you have time, could you also take a look at https://code.launchpad.net/~sil2100/unity/autopilot_more_ibus_tweaks/+merge/151021 ?
[17:42] <sil2100> thomi, veebers: ^
[17:42] <sil2100> Since IBus error messages are spamming the error logs right now ;/
[17:43] <fginther> sil2100, Yes, i can get to that after lunch
[17:44] <bschaefer> sil2100, hey, i've seen you doing a bunch of fixes to the autopilot ibus tests
[17:45] <bschaefer> sil2100, what were all the ibus problems?
=== jhodapp|food is now known as jhodapp
[17:46] <sil2100> bschaefer: hi Brandon, they're nothing serious - I've been working around the need to hard-code unicode 'result' characters for the ibus autopilot tests
[17:46] <sil2100> bschaefer: as results from most engines depend on the ibus usage history, we were getting failures most of the time in pinyin
[17:46] <bschaefer> sil2100, (also hello!). Awesome! That would be nice to get better coverage!
[17:46] <sil2100> bschaefer: so I made 'polling' ibus for the correct results
[17:47] <sil2100> bschaefer: so now, before the test we poll ibus with the input string, get the result and then compare this with what has been written in the search field
[17:47] <bschaefer> sil2100, sweet, yeah, a problem is different ibus engines use different methods :(, like ibus-anthy stores it in ~/.anthy...
[17:47] <sil2100> bschaefer: yea... we tried clearing history already, but well ;/
[17:48] <sil2100> bschaefer: this and also the problem of restarting ibus after clearing the history is needed
[17:48] <bschaefer> sil2100, but if you can poll thats a better way around it :), I was at one point thinking of cleaning up the history but could find a nice pattern :(
[17:48]  * bschaefer finds ibus to be annoying to talk with...
[17:48] <sil2100> bschaefer: same here, been trying this approach, but then decided to rage-quit and move on ;)
[17:48] <bschaefer> haha :)
[17:48] <sil2100> Yes, REALLY annoying
[17:48] <bschaefer> sil2100, ibus will slowly make you go insane :)
[17:48] <sil2100> hehe, hope not!
[17:49] <bschaefer> sil2100, just wanted to double check, as I kept seeing ibus pop up in the MPs and was like noooo another ibus problem
[17:49] <bschaefer> sil2100, thanks for looking into that though!
[17:49] <sil2100> bschaefer: well, the nux ibus support works really well, so no problems in the main unity code you made ;) The AP tests should be fine now as well
[17:50] <sil2100> If the latest merge gets in we won't even have annoying ibus error messages even (I hope)
[17:50] <bschaefer> sil2100, awesome :), yeah I think ibus has been one of the hardest AP tests to constantly pass 100% of the time...
[18:07] <cyphermox> bregma: hey
[18:07] <cyphermox> bregma: so I did more testing and nothing was really working
[18:07] <cyphermox> but this (http://paste.ubuntu.com/5574060/) seems to be good; looks fine to you?
[18:10] <bregma> cyphermox, could you try the xorg-gtest package from http://mentors.debian.net/debian/pool/main/x/xorg-gtest/xorg-gtest_0.7.1-1.dsc and see if it solves the problem (sorry, it's a source package, PPA builds are being tardy again)
[18:11] <cyphermox> sure
[18:12] <cyphermox> ahahah
[18:12] <cyphermox> yeah, I guess that would work :)
[18:12] <cyphermox> I thought of it, but I wasn't sure if there were other real intended external uses of Start () with a va_list parameter
[18:13] <cyphermox> so instead I convinced it hard to work
[18:14] <cyphermox> I still don't understand why it seems like it's consistently that one function signature that gets chosen when you pass only a command name and NULL as parameters
=== mmrazik is now known as mmrazik|afk
[18:18] <bregma> "..." has lower resolution priority over a "natural" type conversion, but that can be vague when the types are not strictly defined
=== mmrazik|afk is now known as mmrazik
[18:37] <fginther> didrocks, do you want to re-review https://code.launchpad.net/~fginther/cupstream2distro-config/cu2d-update-ci-take3/+merge/150954? it can wait till tommorrow
[18:37] <didrocks> fginther: I'm opening it on a tab :)
[18:50] <cyphermox> bregma: but that's not the one we're catching
[18:50] <cyphermox> if you pass NULL to Start() as a second parameter, it goes straight to the va_list parameter :)
[18:50] <cyphermox> bregma: regardless, should I sponsor your xorg-gtest 0.7.1-1 to Ubuntu?
[18:50] <cyphermox> if you jsut make it -0ubuntu1 instead...
[18:51] <cyphermox> you think upstream wants to drop that Start() from the public API?
[19:07] <bregma> cyphermox, I imagnie upstream doesn;t really care about the va_list overload, but it's worth discussing with them since I think it was an error to have it there in the first place
[19:07] <cyphermox> ok
[19:08] <bregma> I'll follow up on that
[19:11] <bregma> I'd just wait for merging that packagage into Ubuntu, there's at least 1 more change coming
[19:15] <cyphermox> ok then I'll upload my patch on the current package now, so as to at least fix ido for tomorrow
=== dandrader is now known as dandrader|afk
[19:15] <cyphermox> and we can push either patch upstream, depending on the original intent with that Start() va_list function
=== dandrader|afk is now known as dandrader
=== _thumper_ is now known as thumper
=== rsalveti_ is now known as rsalveti
=== salem_ is now known as _salem
=== thumper is now known as thumper-afk