[09:40] <didrocks> free karma:
[09:40] <didrocks> https://code.launchpad.net/~didrocks/libindicator/bootstrap/+merge/136117
[09:40] <didrocks> https://code.launchpad.net/~didrocks/appmenu-gtk/bootstrap/+merge/136119
[09:40] <didrocks> larsu: ^
[09:41] <larsu> didrocks, first is done, waiting for the diff on the other one
[09:41] <didrocks> larsu: sure :) thanks!
[09:41] <larsu> yellow bar of death!
[09:41] <didrocks> heh
[09:42] <didrocks> sil2100: hey, what's the status on the test failing on armhf for unity?
[09:44] <popey> didrocks, sil2100 I believe Trevinho was working on a fix for that
[09:44] <popey> sil2100, ?
[09:44] <didrocks> popey: oh? I thought and saw some work from sil2100 on it
[09:45] <popey> yeah, sil2100 was looking at it too.. will get update
[09:45]  * popey gets in before larsu on 136119
[09:45] <didrocks> thanks :)
[09:45] <didrocks> popey: so sneaky!
[09:45] <popey> it's all about the karma, baby
[09:46] <popey> oh, and quality.
[09:46]  * larsu shakes fist at popey
[09:53] <sil2100> didrocks1: I was working on 3 tests failing from that suite and submitted a merge request for those
[09:54] <sil2100> The ones related to Animator were supposed to be fixed by Trevinho
[09:54] <didrocks> sil2100: ok, thanks for the update :)
[09:54] <sil2100> If Trevinho won't find time for those, I'll simply do a similar fix for them today as I did for the glib ones ;p
[09:55] <didrocks> sil2100: can you ping him and keep me in touch?
[09:55] <sil2100> Aye sir!
[09:55] <sil2100> Trevinho: PIIING
[09:56] <sil2100> ;p
[09:56] <didrocks> thanks :)
[10:16] <didrocks> popey: https://code.launchpad.net/~didrocks/appmenu-qt/bootstrap/+merge/136126 :)
[10:17] <popey> :)
[11:00] <mvo> Trevinho: hello! can I nag you about https://code.launchpad.net/~mvo/unity/sc-launcher-integration-fixes/+merge/134931 again? I hit a small wall and would appreciate if you could help me and tell me what direction  you suggest
[12:52] <Trevinho> sil2100: pong
[12:52] <Trevinho> sil2100: about the animator, I've started the work, but it's used quite a lot in the code, so I'm removing it...
[12:52] <sil2100> Trevinho: thanks
[12:52] <sil2100> Trevinho: any ETA for that work to go in?
[12:55] <Trevinho> sil2100: working on it now, I got some blockers last Friday.. so need to continue... Probably in one day I can do it, until I've no blockers -_-
[13:08] <sil2100> Trevinho: thanks :) Would be awesome!
[13:08] <sil2100> Trevinho: could you later also look at https://code.launchpad.net/~sil2100/unity/tests_glib_timeout_modifications/+merge/135883 ?
[13:08] <sil2100> To see if these proposed modifications look ok to you
[14:44] <didrocks> hey, fginther, how was thanksgiving?
[14:44] <fginther> didrocks, it was good, thank you for asking
[14:46] <didrocks> fginther: hoping, you are not under of ton of email, just when you'll have more time, the OIF stack seems to never have been under jenkins, I can give you the list of projects (as there are autolanding branch ready) for them
[14:48] <fginther> didrocks, I can get this going. Please send me the list so that I don't miss any.
[14:48] <fginther> didrocks, also, I saw a discussion on irc regarding the lp-propose --approve merge requests...
[14:48] <didrocks> fginther: grail, evemu, frame, utouch-compiz, libgrip, geis, ginn
[14:48] <didrocks> fginther: yeah, I've fixed in the lp-propose side
[14:49] <didrocks> fginther: like, it's setting a revision number right now
[14:49] <didrocks> fginther: I think it's still a nice optimization to not run a full build if there is only a debian/changelog change
[14:49] <didrocks> but it's not that urgent anymore :)
[14:49] <didrocks> bregma: oh, I see there we don't have inline packaging branch proposed for ginn, interested? :)
[14:50] <fginther> didrocks, ahh, I see.
[14:50] <bregma> I see no point, the project is not really maintained any more
[14:50] <didrocks> bregma: should we remove it from ubuntu as well?
[14:51] <didrocks> fginther: so ignore ginn from the list right now :)
[14:51] <bregma> I think it's OK as unseeded for this cycle, we may end up picking it up again (but that's unlikely)
[14:51] <didrocks> bregma: ok, let's keep it like that then
[14:51] <sil2100> Trevinho: how's the progress with the Animator replacement?
[14:51] <bregma> to tell you the truth, I'm uncomfortable with the oif stack having inline packaging
[14:52] <fginther> bregma, didrocks is utouch-compiz maintained? It wasn't transitioned to the new naming scheme
[14:52] <didrocks> fginther: I'm unsure TBH, I wrote on the MR to check with bregma
[14:53] <didrocks> oh bregma!
[14:53] <didrocks> :)
[14:53] <bregma> utouch-compiz is dead
[14:53] <didrocks> bregma: why so?
[14:53] <bregma> didrocks, there are very few contributors to oif and very few changes so there is no big advantage to inline packaging, and it makes a lot more work for downstream peaople
[14:54] <bregma> like me, when I packaging it for other distros
[14:54] <didrocks> bregma: a lot more work?
[14:54] <didrocks> how does it impact other downstreams?
[14:54] <didrocks> they are all working from tarballs
[14:54] <didrocks> and the packaging is not shipped into the tarball
[14:55] <bregma> with inline packaging and autolanding in Ubuntu without upstream releases, there's no point in doing upstream releaes, so any non-Ubuntu downstream becomes a second-class citizen
[14:56] <didrocks> bregma: still, nothing is preventing you of doing upstream releases
[14:56] <didrocks> bregma: as nothing was preventing notify-osd to not have a release for 3 cycles and only distro-patch :/
[14:56] <didrocks> (especially when it's under low maintenance)
[14:57] <bregma> what's the point?
[14:57] <didrocks> bregma: as you tell, being nice with other downstreams?
[14:57] <didrocks> but the answer here is not "force us, by ubuntu, to have tarballs"
[14:58] <didrocks> and I thought you gave your agreement during UDS? Now that all the work is done, it's a little bit sad that we start this discussion now :/
[14:58] <bregma> anyway, I won't reject any inline packaging merges, since it wouldn't be the first project that has to pull from a VCS instead of using a tarball release
[14:59] <bregma> I'm just voicing my discomfort with it
[14:59] <didrocks> let's see how it goes :) but I guess that at the end of the cycle, when we release an ubuntu release, you have all the incentive to do an upstream release to stamp a version
[15:14] <didrocks> mterry: do you have some time today to finish some work robru started? (he's moving this week)
[15:15] <mterry> didrocks, sure
[15:15] <didrocks> mterry: https://code.launchpad.net/~robru/notify-osd/inline-packaging/+merge/135778, see my comment
[15:15] <didrocks> and https://code.launchpad.net/~robru/sni-qt/inline-packaging/+merge/135763
[15:16] <didrocks> btw, if you spot any integration tests we should be running once the package installed, do not hesitate to tell me, we can have an "autopilot-like" job for those when autolanding
[15:16] <didrocks> also, robru used "raring" in the changelog instead of UNRELEASED :)
[15:16] <mterry> didrocks, OK.
[15:16] <didrocks> mterry: thanks a lot :)
[15:17] <mterry> didrocks, hey, how do I see how many of the autopilot tests for unity are working?  I see a lot of branches to fix various ap tests, but I don't know where we're at
[15:18] <didrocks> mterry: it's still not settled down, until the fail rate is good enough to have daily landing of unity
[15:18] <didrocks> mterry: let me show you the still temporary url
[15:19] <didrocks> https://jenkins.qa.ubuntu.com/job/dx-autopilot-run/
[15:19] <didrocks> one is intel, the other ati
[15:19] <didrocks> https://jenkins.qa.ubuntu.com/job/ps-unity-autopilot-trunk/
[15:19] <didrocks> mterry: p
[15:21] <mterry> didrocks, dx-autopilot-run has a bunch
[15:21] <mterry> (of failures)
[15:21] <didrocks> mterry: both, but -trunk is the real one
[15:21] <didrocks> mterry: the issue is that it goes from 30 to 100+
[15:21] <didrocks> per config
[15:22] <didrocks> mmrazik is investigating it for the last couple of weeks
[15:23] <mmrazik> mterry: the dx-autopilot-run is something legacy. It probably should be deleted.
[15:23] <mterry> mmrazik, k
[15:24] <mmrazik> didrocks, mterry: I just talked with Francis. He will put the staging PPA for raring into a shape and then I'll ask veebers to do some raring testing later today. I hope we will have some reasonable numbers by tomorrow morning CET
[15:24] <didrocks> mmrazik: thanks!
[15:24] <mmrazik> well.. thank you for patience :-P
[15:25] <mterry> didrocks, I haven't switched to staging-ppa on my dev machine, but I suppose I ought to, eh?
[15:26] <mmrazik> mterry: for unity?
[15:26] <mmrazik> mterry: please wait for the first tests. I don't think it is in good shape for raring now.
[15:27] <didrocks> mmrazik: no need
[15:27] <didrocks> oupss
[15:27] <didrocks> mterry: ^
[15:27] <didrocks> mterry: as soon as we have daily landing :p
[15:27] <mmrazik> It was supposed to be updated after every commit but it is not for some reason. fginther is investigating.
[15:27] <didrocks> so I would say, keep raring for now
[15:28]  * mterry wants bleeding edge!
[15:38] <seb128> mterry, hey, stopped segfaulting on ping? ;-)
[15:38] <mterry> seb128, yeah, that got fixed in the indicator
[15:38] <mterry> :)
[15:38] <seb128> mterry, ;-)
[15:40] <larsu> mterry, sorry about that :P
[15:46] <didrocks> mterry: I was really thinking you started to ignore me on purpose!
[15:46] <mterry> didrocks, why can't it be both?  :)
[15:47] <didrocks> mterry: you're right… if you continue with that tone, I'll revert larsu's fix and ping you like mad! :)
[15:48] <larsu> lol
[15:49] <didrocks> mterry: oh btw: https://code.launchpad.net/~cimi/notify-osd/color-tweaks/+merge/100406
[15:49] <didrocks> https://code.launchpad.net/~mterry/notify-osd/no-border/+merge/121956
[15:49] <didrocks> those are in the distro
[15:49] <didrocks> but were never merged upstream
[15:49] <didrocks> so I guess we had enough testing for them :)
[15:49] <mterry> didrocks, yeah I saw that you approved the no-border one, but it failed autolanding because of no debian/changelog
[15:49] <didrocks> however, I guess fginther doesn't handle this case of no-packaging -> packaging branch
[15:49] <didrocks> mterry: so once the packaging is merged, you can bzr merge back to those branch
[15:50] <didrocks> or maybe merge manually? we know they build fine…
[15:50] <mterry> didrocks, yeah OK
[15:50] <didrocks> as you prefer :)
[15:50] <mterry> didrocks, eh, let's do things the shiny new way
[15:50] <didrocks> sure \o/
[15:59] <fginther> alesage, can you investigate the notify-osd failure?
[15:59] <fginther> alesage, ^^
[15:59] <alesage> fginther yessir
[16:00] <alesage> fginther I see a few failures--do you mean autolanding two MPs?  (possibly mterry-originated?)
[16:00] <alesage> or fginther, do you mean for fixing inlining, getting tests to pass under xvfb
[16:00] <fginther> alesage, yes
[16:00] <alesage> ok fginther the first :)
[16:01] <fginther> alesage, mterry mentioned an autolanding problem, I'm missing the context of this project to give a useful response
[16:01] <alesage> fginther, you're fine--I'll fix mterry's builds
[16:01] <mterry> fginther, alesage: the autolanding failed because my branch lacked a debian/changelog.  Probably an inline-debian teething problem
[16:02] <alesage> ya I switched jobs to inline anticipating inlining landing, will revert to land your branches
[17:25] <Velmont> Hey, I have a small pygtk2 testapp, and the menus are showing up in the global menu, but they're not in the HUD. Why? what do I need to do?
[17:26] <Velmont> Guess maybe ubuntu-app-devel might be more fitting :-) (but if anyone knows, I'll be idling).
[17:29] <thumper> Velmont: well, for my understanding technically they should be there :)
[17:29] <thumper> Velmont: ted or desrt may know
[17:34] <Velmont> http://dpaste.com/hold/836998/ < Here's my test that I would've expected to work, btw.
[17:35] <alesage> tedg ^^
[17:37] <tedg> Hmm, I'd expect that to work.
[17:37] <tedg> You can see what it's sending with dbusmenu-dumper
[17:37] <tedg> It's in libdbusmenu-tools
[17:39] <Velmont> I'm on Quantal, btw. -- libdbusmenu-tools is installed, but dbusmenu-dumper doesn't seem to be in my path.
[17:39] <Velmont> /usr/lib/libdbusmenu/dbusmenu-dumper < there ;]
[17:43] <Velmont> Seems to send the same stuff as others. http://dpaste.com/837023/