[09:35] <dgadomski> hi guys, can anybody from the desktop team confirm whether this is the expected behavior or in fact a bug? https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1125442
[09:35] <ubot2> Ubuntu bug 1125442 in unity "Always Visible and On Top Windows Steal Focus on Workspace Switch" [Medium,Confirmed]
[11:42] <dgadomski> hi seb128, do you have a minute to take a look at the bug I mentioned ^^?
[11:42] <seb128> dgadomski, hey, that would be a better question for bregma or Trevinho, I saw it earlier but I'm not working on compiz
[11:43] <dgadomski> seb128: I see, thank you
[11:43]  * Trevinho checking
[11:43] <seb128> dgadomski, the current behaviour doesn't feel buggy to me
[11:44] <dgadomski> seb128: looks pretty consistent to me as well, when we switch to another workspace there is only 1 window there (the one on all workspaces) to it gets the focus, then we go back and the same window remains focused - this is how I see this
[11:45] <seb128> the fact that entering a workspace with 1 dialog gives it focus sort of make sense, even if I can see how it can be annoying to some
[11:45] <bregma> seems to be something that was fixed with alll the Switcher changes that went in since 12.04
[11:46] <seb128> bregma, that's still happening in utopic, not sure it's a bug though
[11:46] <seb128> pitti, hey, do you know if datetimed is having known issue on the device on current images?
[11:46] <seb128> pitti, bug  #1360554
[11:46] <ubot2> Launchpad bug 1360554 in ubuntu-system-settings "cannot change time zone" [High,Confirmed] https://launchpad.net/bugs/1360554
[11:47] <seb128> pitti, settings didn't change, and looking a bit a it seems the helper is correctly called but hit permissions issues
[11:54] <dgadomski> bregma: do you think this could be a regression?
[12:23] <Sweetshark> Laney: You wanted me to save Munich. Well it seems to be save for now: http://linux.slashdot.org/story/14/08/24/194208/munich-council-say-talk-of-limux-demise-is-greatly-exaggerated ;)
[12:35] <pitti> seb128: not known to me yet, but certainly sounds like some regression, yes
[12:39] <seb128> pitti, do you have a phone? does it work for you?
[12:40] <ogra_> seb128, when selecting moscow on my non-mako device i properly get 16:40 in the indicator and lock screen ... pretty instantly after changing
[12:41] <ogra_> switching back works fine too here
[12:41] <seb128> ogra_, k, on mine it doesn't work, the tz is not changed and it doesn't return from the panel
[12:41] <ogra_> (image 207)
[12:43] <pitti> seb128: yes, I do (dual-boot), and the emulator too; still busy with other stuff, but will look at it
[12:47] <pitti> seb128: works fine in the emulator at least; but that's r/w by defualt, so perhaps that's why
[12:48] <pitti> but works after remounting r/o, too
[12:49] <pitti> seb128: WFM on mako too (r/o)
[12:50] <pitti> I'll think about some debugging instrucutions and follow up on the bug
[12:50] <seb128> pitti, thanks
[13:25] <ricotz> seb128, hi :), would be great if this can be revisited https://bugs.launchpad.net/ubuntu/+source/libnotify/+bug/1223401
[13:25] <ubot2> Ubuntu bug 1223401 in libnotify "[0.7.6] the add_action api changed creating issues for clients" [High,Confirmed]
[13:25] <seb128> ricotz, we already discussed it, I'm still unsure what would be an appropriate solution, renaming the binary to indicate the abi change?
[13:27] <ricotz> seb128, the actual binary/library didnt change anything but gir/typelib
[13:28] <seb128> right
[13:28] <seb128> so the gir binary should be renamed?
[13:28] <seb128> otherwise you bug half the clients that rely on the old annotations
[13:31] <ricotz> seb128, adding a suffix to the fixed gir1.2 package would be an option to force a proper transition
[13:31] <seb128> right
[13:32] <seb128> do you know why Debian didn't do that?
[13:32] <ricotz> no, i guess they just gone through it
[13:33] <ricotz> if might effect not that much users
[13:46] <ricotz> seb128, so not changing any package name and rather adding some Breaks to an unpatched libnotify seems cleaner
[13:46] <ricotz> this way things like gnome-music and gnome-tweak-tool would be instantly fixed
[13:50] <seb128> ricotz, while things like unity8 would stop working...
[13:51] <ricotz> seb128, therefore the Breaks!
[13:52] <ricotz> not sure how unity8 works around the broken api now
[13:52] <seb128> the api is not broken right now
[13:53] <seb128> it's just "stable"
[13:53] <seb128> e.g we didn't change it to be incompatible
[13:53] <ricotz> it is! since this crashes clients using it that way
[13:53] <seb128> like upstream did
[13:53] <seb128> well
[13:53] <seb128> that's what happens when you change an api
[13:53] <seb128> or a public api rather
[13:53] <seb128> clients stop working
[13:53] <seb128> GNOME did a stupid thing there
[13:53] <ricotz> seb128, just stop and be constructive
[13:54] <ricotz> it isn't useful to keep it in this current state
[13:54] <ricotz> which unity8 package is actually using the notify-gir?
[13:56] <seb128> ricotz, how is that not being constructive? Debian usually handle those things better, I'm a bit disappointed they didn't rename the gir/do a proper transition
[13:56] <seb128> ricotz, the issue is that you don't know what packages are using the old api and are going to start bugging if you change the annotation
[13:56] <seb128> we can grep the archive, but what about third party, admin scripts, etc?
[13:57] <seb128> the minimum we should do is a proper transition, but even that is going to make working code stop working
[13:57] <ricotz> seb128, if packages using the gir then they should have it set as dependency otherwise i would call the packaging broken
[13:57] <seb128> ricotz, what about local scripts?
[13:57] <seb128> or stuff people write
[13:57] <seb128> changing public api is just not nice
[13:58] <seb128> that should have been handled by adding a new function and deprecating the old one
[13:58] <ricotz> seb128, those g-i api changes happen all the time, to actually fix things
[13:58] <seb128> you don't just change the number of a parameter of a function in a stable api
[13:58] <seb128> "fix"
[13:58] <seb128> sure we can wave hand and say we don't care, it doesn't make the reality different
[13:58] <ricotz> this is just a special case where ubuntu got hit
[13:58] <seb128> no it's not
[13:59] <seb128> if it's not us, it would be admin, users who write custom scripts, etc
[14:00] <ricotz> seb128, using scope=async in this case was wrong and actually changes the "virtual" api not matching the actual c-api
[14:01] <seb128> I didn't say the fix was not correct
[14:01] <seb128> but it doesn't make my point invalid
[14:01] <seb128> several libs live with wrong/suboptimal apis because "fixing" those would be an incompatible change and they avoid doing that because it has a cost
[14:02] <ricotz> (having this problem sit there without doing nothing is nothing better then "breaking" it again)
[14:02] <seb128> but I appreciate that g-i has no compatibility story whatsoever
[14:02] <seb128> it still doesn't make it right
[14:02] <ricotz> alright this is pretty valid, but yeah g-i is a bit special here
[14:03] <seb128> well, my suggestion by then was to rename the binary to have a proper transition
[14:03] <seb128> it's just that nobody picked that up to do it
[14:03] <ricotz> i see
[14:04] <ricotz> again which unity8 package is using this add_action part?
[14:04] <seb128> I don't know, they might not be using it anymore
[14:05] <seb128> tests/autopilot/unity8/shell/emulators/create_interactive_notification.py:        notification.add_action(
[14:05] <seb128> seems they still do
[14:05] <ricotz> as i said it cant be properly used since it crashes the second time you use the action
[14:06] <ricotz> ok, so "only" in the tests
[14:06] <seb128> yes
[15:40] <Ursinha> pitti: hey :) I have a question about autopkgtest, more specifically adt-run, that you might have the answer: when a package has no tests adt-run return code is 8, is that only to create a distinction between tests that actually ran and passed and no tests found? Or is there the intention to consider lack of tests a failure? (I'd assume no, but better ask :))
[15:43] <pitti> Ursinha: yes, we usually consider 8 a failure as way more often than not it's an unintended packaging bug
[15:45] <Ursinha> pitti: got it
[15:45] <Ursinha> pitti: thanks!
[15:46]  * pitti waves good night
[15:48] <seb128> night pitti
[16:23] <Sweetshark> dpkg versioning question: a version 1.2.3 is lower than a version 1.2.3.4, right? This appears to be the case from reading the debian policy manual, but the footnote makes me nervous.
[16:27] <seb128> Sweetshark, yes, you can use dpkg --compare-versions 1.2.3 lt 1.2.3.4; echo $?
[16:27] <lullis> Hey guys... So, I wrote a tiny python gtk application with an indicator that can interact with it. So far, so good. Now I am trying to figure out what is needed to do in order to have this indicator available on my login greeter (unity or lightdm-gtk should do).
[16:28] <lullis> I am guessing I need to write some kind of .desktop file, but that is just a guess.
[16:30] <Sweetshark> seb128: thx
[16:33] <seb128> Sweetshark, yw!
[17:13] <Laney> hey ;-)
[17:14] <larsu> hi Laney! What's going on?
[17:15] <Laney> currently meeting the tech-ctte
[17:15] <Laney> portland is quite pleasant
[17:15] <larsu> so I hear :)
[17:16] <Laney> how are you?
[17:17] <larsu> I have a cold
[17:17] <larsu> but am fine otherwise :)
[17:17]  * larsu just finished beating unitythemeiconprovider into shape
[17:53] <Laney> :( / :)
[17:54] <larsu> heh
[17:56] <seb128> hey laney, had a good trip? how is debconf?
[18:02] <Laney> hey seb128, trip was fine if a bit long
[18:02] <Laney> mostly over the jet lag now
[18:03] <seb128> Laney: no promotion this time?
[18:03] <Laney> no :(
[18:03] <Laney> debconf is good though, nice to meet people again
[18:03] <seb128> great!
[18:03] <seb128> weather is better than in the u.k as well I guess ;-)
[18:04] <Laney> http://www.bbc.com/weather/2641170 looks like it!
[18:05] <seb128> kenvandine, do we need those rtm merge requests to keep the rtm in sync with trunk?
[18:05] <Laney> you still in nl?
[18:05] <kenvandine> seb128, yes
[18:05] <seb128> Laney: guess? :p
[18:05] <Laney> I guess you have shipped your things already
[18:05] <seb128> kenvandine, that sucks, why do we need to branch if we don't add features to trunk/keep it for rtm only
[18:05] <seb128> Laney: lol
[18:06] <seb128> no
[18:06] <seb128> but still visiting people here yes ;-)
[18:06] <Laney> excellent
[18:06] <Laney> how was the poezenboot?
[18:06] <Laney> (trolling monday?)
[18:06] <kenvandine> seb128, i'm not the one to ask :)
[18:07] <seb128> Laney: didn't go there (yet)
[18:07] <kenvandine> we had to make rtm branches for everything
[18:07] <seb128> kenvandine, that's suboptimal
[18:09] <kenvandine> seb128, i think they are still working the kinks out
[18:19] <seb128> kenvandine, k
[18:20] <seb128> kenvandine, "working the kinks out" ... learnt a new expression today ;-)
[18:20] <kenvandine> ha, sorry :)
[18:20] <seb128> no worry, it's good to learn ;-)
[18:21] <seb128> is that commonly used one (the number of hints on google suggest maybe not)
[18:21] <seb128> is that like "working the details out"
[18:21] <seb128> or is there a nuance?
[18:22] <kenvandine> pretty common
[18:22] <kenvandine> more like working the bugs out
[18:22] <seb128> k
[18:22] <seb128> thanks ;-)
[22:53] <DalekSec> Hello.  So it seems you guys are the maintainers for xchat-indicator.  Hexchat seems to be "the new hip xchat", and has since had https://bugs.launchpad.net/ubuntu/+source/hexchat/+bug/1360785 reported.  Would you, since you maintain xchat-indicator, perhaps maintain hexchat-indicator?  https://code.launchpad.net/~unit193/hexchat-indicator/packaging may be a starting point...
[22:53] <ubot2> Ubuntu bug 1360785 in hexchat "HexChat does not integrate with the Ubuntu me-menu" [Undecided,New]