[08:26] <didrocks> hey sil2100, how are you?
[08:37] <sil2100> didrocks: hello, I'm fine - how was your holiday? ;)
[08:38] <didrocks> sil2100: really nice! even if the weather wasn't optimal, I could at least taste all kind of snow state :)
[08:38] <didrocks> also, nothing broken apparently :)
[08:38] <didrocks> and you? how was your week?
[08:40] <sil2100> didrocks: awesome to know you're not broken in any way ;) The week was a bit busy
[08:40] <didrocks> sil2100: I saw that you fought some new refactoring breaking more tests, right? :/
[08:40] <sil2100> didrocks: since there was an ABI break we had to fix, switcher tests got broken again due to refactoring, some daily failures as always popped up and eh eh
[08:41] <didrocks> sil2100: TBH, I would go with reverting in the future, you can't be alone fixing refactoring issues
[08:41] <sil2100> But we managed to somehow fix things, although 'sometimes' indicator tests still fail, due to some strange mini-regressions I think
[08:41] <didrocks> sil2100: speaking of tests, I think you are still seeing the high number of failures, do you know why?
[08:41] <didrocks> it's read, not even yellow even
[08:42] <popey> Welcome back didrocks
[08:42] <didrocks> hey popey! Thanks! How are you? :)
[08:42] <popey> Need moar coffee.
[08:42] <sil2100> didrocks: I'll look at the list in a moment and comment ;)
[08:42] <popey> Other than that, fine ☺
[08:42] <didrocks> popey: heh, first life problem! :)
[08:42] <popey> ☺
[08:42] <didrocks> sil2100: thanks! 623 issues apparently :/
[09:13] <sil2100> didrocks: huh, ok, looking into all those failures now, but we didn't have those last week - it seems the reason for them are the autopilot refactorizations by thomi in lp:unity
[09:13] <sil2100> didrocks: for new autopilot
[09:14] <didrocks> sil2100: hum, so the refactorization is wrong?
[09:15] <sil2100> didrocks: not sure - what autopilot is jenkins using?
[09:15] <sil2100> didrocks: since we need to use the most recent revision, 125, which didn't get released yet
[09:15] <didrocks> sil2100: the one from the ppa, but I guess it's adding another ppa, isn't it mmrazik?
[09:16] <mmrazik> didrocks: mhm... might be still the case. Let me check
[09:17] <sil2100> didrocks: since once we have certainity that we're using latest autopilot and latest lp:unity trunk, we can then check if there are still errors, since I'm not sure if all thomi's changes were in when the jenkins test job was started
[09:17] <mmrazik> didrocks, sil2100: yes,  1.2daily13.01.28-0ubuntu1+bzr125pkg0raring1 is installed
[09:17] <sil2100> didrocks: some things changed in how introspection is handled from what I see, so it can cause failures when all tests are not fixed
[09:18] <didrocks> sil2100: ^
[09:18] <didrocks> sil2100: sholdn't we revert autopilot and unity changes then?
[09:18] <sil2100> mmrazik: thanks - could you check also what package version of unity was used exactly?
[09:18] <mmrazik> sil2100: are we talking about build #70?
[09:18] <mmrazik> just to make sure...
[09:18] <sil2100> mmrazik: yes
[09:19] <sil2100> thomi: are you still around?
[09:19] <sil2100> (sometimes thomi is still not sleeping at this hour ;) )
[09:19] <mmrazik> sil2100: 6.12.0daily13.02.04-0ubuntu1
[09:19] <mmrazik> sil2100: FYI: https://jenkins.qa.ubuntu.com/job/ps-unity-autopilot-release-testing/70/label=autopilot-ati/artifact/results/artifacts/machine-config/dpkg-list.log/*view*/
[09:19] <sil2100> Ah, ok, thanks!
[09:19]  * sil2100 writes that down
[09:20] <sil2100> Let me check what was in that
[09:20] <mmrazik> sil2100: I assume I can just disable the additional PPA. We used it because it has pythohn-testapp but that should be in raring already.
[09:21] <sil2100> didrocks: ok, so it seems we were testing revision 3112, while thomi was still pushing his changes
[09:22] <sil2100> didrocks: let's try re-running the tests on the latest revision 3116 maybe to see if he fixed everything
[09:23] <mmrazik> sil2100, didrocks: I just disabled the autopilot ppa
[09:23] <sil2100> mmrazik: let's use the autopilot ppa for now
[09:23] <mmrazik> ok
[09:23] <mmrazik> then reverting :)
[09:24] <sil2100> mmrazik: since I just want to make sure thomi fixed everything - becaue *maybe* with lp:unity trunk all will be ok
[09:24] <sil2100> *maybe* ;) Thanks, and sorry for the trouble
[09:24] <mmrazik> lets see
[09:24] <didrocks> sil2100: so, the change in the ppa?
[09:24] <didrocks> mmrazik: I can rerun the full stack
[09:24] <sil2100> didrocks: I think we would have to use unity staging for this test run ;/
[09:25] <sil2100> Or wait
[09:25] <didrocks> yeah?
[09:25] <sil2100> Staging staging... wait
[09:25] <sil2100> Shiiit ;/
[09:25] <didrocks> shiiiit good, shit bad? :)
[09:25] <sil2100> Since thomi was pushing changes *directly* to trunk without merge-requests, staging is based on 3102 still
[09:26] <sil2100> So we have to build trunk somewhere first then
[09:26] <didrocks> we are interested in rev 3116?
[09:26] <sil2100> Yes, since that one seems final with the AP changes
[09:26] <mmrazik> I wonder how that happened an why would he push to trunk
[09:27] <mmrazik> sounds like some pilot error
[09:27] <sil2100> Then we can decide on a revert finally
[09:27] <didrocks> latest autopilot is 1.2daily13.01.28-0ubuntu1
[09:27] <sil2100> mmrazik: not sure, maybe he wanted to push them quickly... but still, it's not wise to push without review ;/
[09:27] <didrocks>   * Automatic snapshot from revision 123
[09:28] <sil2100> didrocks: I think for everything to work, we need  1.2daily13.01.28-0ubuntu1+bzr125pkg0raring1  from ppa:autopilot/ppa
[09:28] <didrocks> sil2100: I can rebuild latest trunk if needed
[09:28] <didrocks> Thomi pushed things half backed :/
[09:29] <sil2100> He could have at least sent an e-mail to the ML! ;p
[09:29] <mmrazik> this must be some error. Doesn't make any sense to me to push this sort of stuff in a rush
[09:29] <didrocks> sil2100: yep :/
[09:29] <didrocks> sil2100: so, do you mean directly pushing to trunk a revert in autopilot and unity?
[09:30] <didrocks> and tell to have them merged in synced before a 00 UTC or after 6 UTC
[09:31] <sil2100> didrocks: I wonder what to do now... since it would be best if thomi could comment on why he pushed directly, without a MR - maybe he did that by mistake?
[09:31] <sil2100> Since I don't see any rationale
[09:31] <didrocks> sil2100: as you wish, I can redo a daily with latest autopilot
[09:31] <didrocks> or reverting
[09:31] <didrocks> just want to unblock :)
[09:32] <didrocks> sil2100: are we sure everything will pass with latest autopilot?
[09:32] <didrocks> your pick :)
[09:32] <sil2100> hmmm ;p
[09:33]  * mmrazik votes for revert in lp:unity
[09:33] <mmrazik> lp:autopilot stuff seemed to go through review/autolanding
[09:33] <sil2100> Yes, I think so too - since even if we revert, thomi can re-send all the changes in one big MR anyway
[09:33] <sil2100> And we'll get it all nice and tidy
[09:33] <sil2100> So it might be done by mistake these direct changes
[09:34] <sil2100> mmrazik: you will have to disable ppa:autopilot/ppa then... ;) (sorry that you have to keep enabling and disabling it all the time)
[09:34] <mmrazik> sil2100: the changes in r125 of lp:autopilot will break the tests in lp:unity ?
[09:34] <mmrazik> I mean, in the cleaned lp:unity
[09:34] <sil2100> mmrazik: yes, since it modifies some methods in autopilot, so those will fail on being called without thomi's lp:unity modifications
[09:35] <sil2100> So we need to use an earlier autopilot, the last one released is fine
[09:35] <sil2100> Since there's one commit that changes AP
[09:35] <mmrazik> ok.. so we just need to make sure the autopilot stuff doesn't land in raring sooner than the unity stuff
[09:36] <mmrazik> sil2100: the autopilot ppa is gone
[09:37] <sil2100> I'll try maybe creating a big merge request for thomi, I'll put it up in ~unity-team so that thomi can edit it if anything
[09:39] <didrocks> mmrazik: sil2100: hum, we need to revert both or none
[09:39] <didrocks> mmrazik: sil2100: they need to land in sync
[09:39] <mmrazik> didrocks: and I wonder how that can be done
[09:39] <didrocks> or this will be broken again in the next daily
[09:39] <mmrazik> didrocks: but then unity will just need to wait for its fixes
[09:39] <didrocks> mmrazik: well, there is 24 hours in a day to ensure they are merged before noon :)
[09:40] <didrocks> mmrazik: unity won't be releasable without the fixes
[09:40] <mmrazik> yes. which sounds like a reasonable workflow...
[09:40] <mmrazik> first release the new autopilot
[09:40] <mmrazik> and then unity
[09:40] <didrocks> mmrazik: I would say yes, but one of the rule is to land coherent stuff within a day
[09:40] <didrocks> which wasn't the case here
[09:40] <didrocks> mmrazik: and I would say yes if we don't have constant test breaking and just skip one daily
[09:40] <mmrazik> didrocks: and which is kind of tricky in situations like this one
[09:41] <didrocks> mmrazik: I don't want we block unity for another week
[09:41] <didrocks> mmrazik: retrocompability? :p
[09:41] <didrocks> if we want to be serious about developping apps, that's something needed
[09:41]  * sil2100 wonders why every week has to start out with ~400 tests being broken
[09:41] <mmrazik> we actually said at UDS that we might break autopilot during a development release
[09:42] <sil2100> It's like, damn, that's the third week that happens
[09:42] <mmrazik> but anyway... it looks like reverting both is the way to go
[09:42] <didrocks> sil2100: agreed, we need to have this stopped
[09:42] <didrocks> sil2100: reverting both then?
[09:42] <sil2100> didrocks: ok, let's do so - we'll be at least sure that nothing will be broken tomorrow at least
[09:43] <didrocks> yep, thanks :)
[09:43] <sil2100> didrocks: should I prepare a revert MR for autopilot?
[09:43] <didrocks> sil2100: can you email tomy?
[09:43] <didrocks> sil2100: no direct push is fine
[09:43] <sil2100> Will do!
[09:43] <sil2100> Ok :)
[09:43] <didrocks> sil2100: tell me once both are done, while you write thomi an email, I'll trigger daily tests again
[09:43] <sil2100> didrocks: direct push to lp:unity as well?
[09:44] <didrocks> sil2100: yep :)
[09:44]  * sil2100 really doesn't like direct pushes
[09:44] <sil2100> I have a trauma ;p
[09:44] <didrocks> for a revert, no need to go by a merge… :)
[09:44] <didrocks> heh
[09:44] <sil2100> Ok, will give a sign, doing it now
[09:44] <didrocks> thanks!
[09:49] <sil2100> btw. didrocks if we do direct pushes to lp:unity, what version will you use for the daily tests? Since staging will not have trunk, you'll have to build it somewhere yourself, right?
[09:49] <didrocks> sil2100: it's already building somewhere else :)
[09:50] <sil2100> \o/
[09:50] <didrocks> https://launchpad.net/~ubuntu-unity/+archive/daily-build
[09:50] <didrocks> sil2100: mmrazik is supposed to remove staging ASAP
[09:50] <didrocks> use daily-build rather ;)
[09:50]  * mmrazik makes a remark to check with fginther. I think we can get rid of it right now.
[09:51] <didrocks> mmrazik: \o/
[09:56] <sil2100> didrocks: direct pushes with reverts done
[09:56] <didrocks> sil2100: sweet! let me rebuild unity then :)
[09:57] <sil2100> didrocks: we probably didn't have to do it this way, but at least now we will be 100% sure nothing breaks
[09:57] <sil2100> I'll write an e-mail to thomi, he'll probably not be too happy ;p
[09:57] <sil2100> (just as we were in the morning seeing those failures, ha)
[09:58] <didrocks> sil2100: indeed, as we were, put me in CC :)
[09:58] <didrocks> sil2100: and tell him both changes needs to be done in synced, and landing before 00 UTC
[09:58] <didrocks> landed*
[10:11] <sil2100> didrocks: e-mail sent
[10:11] <didrocks> sil2100: sweet! build in progress, let's see
[10:11] <didrocks> and cross fingers
[10:11] <didrocks> more and more :)
[10:15] <MCR1> JohnLea: Hi :) If you are running Raring, you now should already be able to use the Ctrl+Alt+Down shortcut to restore maximized and minimize restored/normal windows...
[10:16] <didrocks> MCR1: hey, please read https://code.launchpad.net/~mc-return/unity/unity.merge-fix966099-shortcut-fails-to-minimize-just-restores/+merge/145474/comments/317424
[10:17] <MCR1> didrocks: Hi
[10:19] <didrocks> MCR1: hey
[10:19] <MCR1> didrocks: There is no need for key strategy migration, as those who have changed the shortcut, will still have their changed shortcut, as unmaximize_or_minimize_window_key is a completely new key, that was not available before...
[10:19] <didrocks> MCR1: ok, can you fix the gconf migration though?
[10:19] <MCR1> didrocks: You are right, I forgot the gconf-key
[10:20] <didrocks> MCR1: also, what about the xml for g-c-c? do you set the new key here now?
[10:20] <didrocks> (I didn't read yet the compiz side ;))
[10:20] <MCR1> yes
[10:20] <didrocks> excellent, so only the gconf key change needs to be taken into acount :)
[10:20] <didrocks> account*
[10:20] <MCR1> I added a new function to Compiz + new key
[10:20] <didrocks> exported in g-c-c?
[10:20] <MCR1> Default for Compiz has not changed
[10:22] <MCR1> and the quilt patch patches the Ubuntu version to use unmaximize_or_minimize_window_key instead of unmaximize_window_key
[10:22] <MCR1> didrocks: Please explain what is missing in g-c-c, as I am not sure now... :-[
[10:23] <didrocks> MCR1: in gnome-control-center, you have the shortcuts exposed for some keys
[10:23] <didrocks> MCR1: instead of unmaximize_window_key, I think we should expose unmaximize_or_minimize_window_key
[10:23] <MCR1> ah, yes
[10:23] <MCR1> yes, sure - all those different configs - urgh
[10:23] <didrocks> so this is exposed?
[10:23] <MCR1> now I understand
[10:24] <MCR1> No, I have patched just 3 things for this new shortcut (yet)
[10:24] <MCR1> but the Unity Help Overlay should already show the right key and combination
[10:25] <didrocks> MCR1: right, but you can't change it with the default tools
[10:25] <MCR1> What do I need to patch for that, g-c-c ?
[10:25] <didrocks> MCR1: can you please work on that? It should have been something as part of the first merge request
[10:25] <didrocks> MCR1: no, it's in compiz, smspillaz would know more what's needed, I just did it once, a long time ago :)
[10:26] <MCR1> Ok, I'll find it and will work on it this evening.
[10:27] <didrocks> thanks MCR1 :)
[10:28] <MCR1> np - sorry if I did not get everything right immediately...
[10:28] <didrocks> no worry, waiting for your 2 new MP :)
[10:29]  * MCR1 is still learning and quilt was a fight already ;)
[10:32] <MCR1> didrocks: Found it. It is in ccs_gnome_integration_constants.c
[10:32] <didrocks> yep :)
[10:41] <MCR1> bug 1115128
[10:58] <didrocks> sil2100: excellent email btw :)
[11:04] <sil2100> didrocks: thanks ;p
[11:15] <didrocks> sil2100: see run 71 :/
[11:15] <didrocks> sil2100: exactly the same, did I miss anything?
[11:16] <didrocks> sil2100: the package is 6.12.0daily13.02.04.1-0ubuntu1 from the daily ppa
[11:17] <MCR1> didrocks: Done: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix1115128-expose-unmaximize_or_minimize_key-in-g-c-c/+merge/146384
[11:19] <didrocks> MCR1: see my comment
[11:19] <didrocks> you did the same error than in unity (which needs a MP as well ;))
[11:19] <didrocks> MCR1: also, you probably will have to change some xml that we ship for g-c-c
[11:20] <didrocks> MCR1: please test this with openining g-c-c with your branch
[11:22] <sil2100> hmm
[11:22] <sil2100> I'll look into it in a moment
[11:23] <sil2100> didrocks: ah ha!
[11:24] <sil2100> didrocks: it's still using autopilot from the autopilot PPA ;/
[11:24] <didrocks> mmrazik|lunch: ^
[11:24] <sil2100> 1.2daily13.01.28-0ubuntu1+bzr125pkg0raring1
[11:28] <didrocks> sil2100: I think I've found the right preseed, mmrazik|lunch should have edited the wrong one
[11:28] <didrocks> let me try
[11:28] <MCR1> didrocks: I am not sure I understand. Unity does not need changes, as the key and function are new. So if someone already configured another key to unmaximize a window, it will still work, just will not show up in the help overlay, while the new key will - and for those who are using default, the default shortcut will now trigger the new key and function (unmaximize_or_minimize_window_key)...
[11:29] <MCR1> didrocks: Is something wrong with my logic here ?
[11:29] <didrocks> MCR1: the gconf -> gsettings transition, see my first comment
[11:29] <didrocks> MCR1: you are using a gconf key that never existed, you still need the old one
[11:29] <didrocks> for precise -> next LTS upgrade
[11:29] <didrocks> sil2100: relaunched! nice catch, let's see
[11:38] <didrocks> sil2100: seems that there is a pull needed on the other side, mmrazik|lunch knows what do to, pushing doesn't seem to be enough (still same issue)
[11:40] <didrocks> sil2100: ah, in fact, it's yet another version: python-autopilot                          1.2daily13.01.28-0ubuntu1+bzr124pkg0raring1
[11:40] <didrocks> rev 124
[11:40] <didrocks> so before the refactoring?
[11:40] <MCR1> didrocks: TBH, I did not think that and how this would be backported, but I think we should not mix up unmaximize and unmaximize_or_minimize as those are different keys and they have different functionality. It would create a mess if unmaximize_window in gconf would trigger unmaximize_or_minimize_window_key, no ?
[11:40] <didrocks> not sure what's the source
[11:41] <didrocks> MCR1: isn't unmaximize_window old key mapped now to unmaximize_or_minimize_window_key?
[11:41] <didrocks> MCR1: in any case, you need either to keep the old binding for gconf transition either map the old one to the new key
[11:41] <didrocks> but not removing the old key transition for sure
[11:42] <sil2100> didrocks: yes, I think 124 was the release commit
[11:42] <sil2100> didrocks: so 124 is cool
[11:42] <didrocks> sil2100: well, still the same number of failure
[11:42] <didrocks> see rev 72
[11:42] <didrocks> I don't get why we have this version though, this doesn't come from any well known ppa
[11:43] <sil2100> hmmm
[11:43] <MCR1> didrocks, ok - I'll have to rethink that stuff in the evening - most probably you are right...
[11:43] <sil2100> didrocks: I still see autopilot 125 though
[11:43] <sil2100> https://jenkins.qa.ubuntu.com/job/ps-unity-autopilot-release-testing/72/label=autopilot-ati/artifact/results/artifacts/machine-config/dpkg-list.log/*view*/
[11:43] <sil2100> ii  python-autopilot                          1.2daily13.01.28-0ubuntu1+bzr125pkg0raring1
[11:45] <didrocks> sil2100: urgh, I was on the "last successful build"
[11:45] <mmrazik> didrocks: AFAICS the release job is using resources/preseed.cfg
[11:45] <mmrazik> not sure where is trunk-preseed.cfg used
[11:45] <didrocks> mmrazik: well doesn't seem so, look at ^
[11:45] <didrocks> mmrazik: do you need to pull somewhere?
[11:46] <mmrazik> didrocks: https://jenkins.qa.ubuntu.com/job/ps-unity-autopilot-release-testing/label=autopilot-ati/72/console
[11:46] <mmrazik> I see resources/preseed.cfg in the utah command
[11:46] <mmrazik> didrocks: not sure what you mean by pull
[11:46] <didrocks> mmrazik: ok, but still, it seems to install the wrong version
[11:47] <didrocks> mmrazik: see sil2100's comment above and the artefacts
[11:47] <didrocks> mmrazik: I meant, do you need to bzr pull on some machine for the change to apply?
[11:47] <mmrazik> you shouldn't need to
[11:47] <didrocks> it's installing 1.2daily13.01.28-0ubuntu1+bzr125pkg0raring1 though
[11:48] <mmrazik> btw. the results seem to be some old stuff to me. the run_utah_tests.py command failed with stack trace
[11:48] <sil2100> hmmm
[11:48] <mmrazik> build #72 seem to be bogus
[11:48] <mmrazik> trying to find out why it failed
[11:48] <didrocks> mmrazik: the old artefacts are not cleaned?
[11:49] <mmrazik> didrocks: they are... by the fact that machine gets reinstalled
[11:49] <didrocks> mmrazik: oh, I think it's because of the # you added
[11:49] <didrocks> mmrazik: as we have \ in the end of line
[11:49] <didrocks> everything is one line
[11:49] <didrocks> so the command doesn't finish?
[11:49] <mmrazik> didrocks: veebers was actually fixing this issue but I guess he didn't touch the release jobs
[11:49] <mmrazik> didrocks: yeah.. probably
[11:49] <didrocks> ok, let me try to remove them
[11:49] <mmrazik> didrocks: let me revert your change to trunk-preseed
[11:49] <mmrazik> and I remove it
[11:50] <didrocks> mmrazik: ok, same for your change
[11:50] <didrocks> mmrazik: do it for all preseeds
[11:50] <mmrazik> what?
[11:50] <didrocks> mmrazik: remove the ppa
[11:50] <mmrazik> there might be a legitimate reason to use the ppa
[11:50] <didrocks> mmrazik: not for the daily release
[11:50] <didrocks> as everything should be in the "misc" stack
[11:51] <mmrazik> didrocks: yes and that job is using preseed.cfg
[11:52] <mmrazik> sil2100, didrocks: the new preseed.cfg should be in the repo
[11:52] <didrocks> mmrazik: right, and other jobs are using the custom preseed file
[11:52] <didrocks> mmrazik: when we only install one stack from the ppa
[11:52] <didrocks> and not everything
[11:52] <mmrazik> somebody is probably using the trunk-preseed.cfg as well (I guess veebers for the trunk testing with jenkins local unity staging repo)
[11:53] <mmrazik> bu yeah... the release jobs are either using preseed.cfg or the customized
[11:53] <didrocks> mmrazik: can you remove it from the customized as well then?
[11:53] <mmrazik> didrocks: its not there
[11:53] <mmrazik> oh... maybe the jobs are explicitely asking for it
[11:53] <mmrazik> let me check
[11:54] <mmrazik> didrocks: yup. its in the job configuration. Removing it and keeping only daily
[11:55] <didrocks> mmrazik: ok, you need that for the indicator and the oif ones as well
[11:55] <mmrazik> didrocks: yes. changed that two already
[11:55] <mmrazik> and unity is using preseed.cfg
[11:55] <mmrazik> so it should be gone for all the release jobs
[11:55] <didrocks> mmrazik: ok, launching it :)
[11:56] <mmrazik> veebers: can you please check the release jobs running on magners and make sure we are not reporting old results in case an installation fails?
[11:56] <mmrazik> veebers: ps-unity-autopilot-release-testing, ps-oif-autopilot-release-testing, ps-indicators-autopilot-release-testing
[12:11] <sil2100> Phew
[13:02] <ricotz> Cimi, hi :)
[13:03] <Cimi> hi
[13:03] <ricotz> did you had a look at gtk 3.7/3.8 yet, in regard of light-theme?
[13:03] <Cimi> no
[13:03] <Cimi> I don't think I will
[13:04] <ricotz> hmm, i see
[13:04] <ricotz> why?
[13:04] <Cimi> did they break yet again?
[13:04] <seb128> ricotz, oh, is the new gtk breaking themes?
[13:04] <Cimi> I am working on the ubuntu phone
[13:04] <seb128> I was going to look at updating :-(
[13:04] <ricotz> Cimi, is isnt really usable
[13:05] <seb128> ricotz, what did they break?
[13:05] <ricotz> so it would be nice to get it fixed, despite that fact it wont land in raring
[13:05] <ricotz> seb128, hi
[13:05] <ricotz> seb128, not sure about the specifics
[13:06] <Cimi> ricotz, what is broken?
[13:07] <ricotz> Cimi, i will try to do a screenshot
[13:13] <ricotz> Cimi, ok, i should have tested it before, it isnt that bad that i was told -- http://people.ubuntu.com/~ricotz/gtk/
[13:13] <ricotz> seb128, ^
[13:14] <Cimi> menubar seems
[13:15] <ricotz> added an Adwaita reference screenshot too
[13:17] <seb128> ricotz, ok
[13:17] <seb128> seems like it could be easy to fix issues
[13:18] <Cimi> patches accepted :D
[13:28] <MCR1> didrocks: I added a detailed description with links to the merges that already happened to https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix1115128-expose-unmaximize_or_minimize_key-in-g-c-c/+merge/146384 and have added Sam to the reviewers, so he can also check it again... I think it should be correct that way, but maybe I misunderstand (probably) some of the complicated mechanics going on... Hope you are ok with that solution 
[13:35] <didrocks> sil2100: saner number of failure, do you have some time to look at them? (~20 on nvidia and intel)
[13:35] <didrocks> on each, I meant!
[13:37] <didrocks> MCR1: yeah, thanks for the description, you can already do the two changes for the gconf key
[13:38] <MCR1> didrocks: I know you know best, so although I do not understand that part I'll do it - One MP for Unity as well ?
[13:41]  * MCR1 also found another unrelated typo and mistake in compiz-profile-active-Default.convert and compiz-profile-active-Default.convert
[13:42] <MCR1> they are referring to refres_rate and detect_refres_rate, which is definitely wrong as well...
[13:45] <didrocks> MCR1: yeah, one for unity and an additional commit on compiz to change /apps/compizconfig-1/profiles/Default/plugins/core/screen0/options/unmaximize_or_minimize_window_key to /apps/compizconfig-1/profiles/Default/plugins/core/screen0/options/unmaximize_window_key would be awesome!
[13:46] <MCR1> didrocks: Sure. Will do.
[13:46] <didrocks> thanks :)
[13:47]  * MCR1 simply closes his eyes and lets didrocks guide him through the gconf labyrinth of Ubuntu...
[13:47]  * MCR1 will fix bug 1115243 as well
[13:49] <didrocks> sweet :)
[14:16] <MCR1> didrocks: https://code.launchpad.net/~mc-return/unity/unity.merge-fix1115128-gconf-problems/+merge/146419 and https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix1115128-expose-unmaximize_or_minimize_key-in-g-c-c/+merge/146384 are (hopefully) ready
[14:17] <sil2100> didrocks: looking ;)
[14:17] <sil2100> didrocks: ah, now it's much better - we've been looking at some of them, now resolving some python problems
[14:21] <didrocks> sil2100: thanks!
[14:21] <didrocks> waiting for mterry for doing the actual publication
[14:21] <didrocks> MCR1: let's wait for sam's review on compiz side, I think you miss some xml changes for g-c-c
[14:22] <didrocks> MCR1: approved the unity side
[14:22] <MCR1> didrocks: yes, I think that is a good idea
[14:24] <MCR1> didrocks: Here is the other fix and MP: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix1115243-refresh-typos/+merge/146421
[14:41] <mterry> didrocks, how was your vacation?
[14:49] <mterry> er, holiday I guess for you
[14:55] <MCR1> If someone's in Compiz review mode:
[14:55] <MCR1> Michail Bitzes ported Splash to GL|ES: https://code.launchpad.net/~bitzesmichail/compiz/splash-gles/+merge/146391
[14:56] <MCR1> I fixed Cube Gears compilation: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix1020822-gears-plugin-does-not-build-anymore/+merge/146285
[14:56] <MCR1> This is the second part for thumbnail (this time xml.in upgrade only): https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix1099100-thumbnail-title-text-issues.1/+merge/145043
[14:57] <MCR1> Here some static code analyzer warnings/errors fixed: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix1114525-cppcheck-reveals-true-positives/+merge/146315
[14:57] <sil2100> Holy moly, that's a lot of merge requests
[14:58] <MCR1> well
[14:58] <MCR1> :-D
[15:00] <MCR1> sil2100: Please do not look @ the WIP MPs for Compiz then... ;)
[15:01] <mpt> andyrock, hi, are you still making progress with bug 974480?
[15:02] <andyrock> mpt, hi, nope but I can finish it by the end of this week if needed
[15:03] <mpt> andyrock, it isn't urgent, but I think it's the sort of thing that's best done well before a release
[15:04] <mpt> to give us time to discover apps that it breaks :-)
[15:07] <MCR1> Trevinho: About bug 1103742 - maybe it is best I do not mess with it if you are in the process of restructuring that part of the code anyway @ the moment... So I'll leave that one open, no MP from me...
[15:07] <andyrock> mpt, sure will be done
[15:07] <mpt> cool, thanks
[15:07] <andyrock> np
[15:08] <Trevinho> MCR1: as you prefer
[15:08] <Trevinho> MCR1: is that only related to textures?
[15:08] <MCR1> Trevinho: I'll wait ;)
[15:09] <MCR1> Trevinho: I am not 100% sure, have not yet investigated - you told me that it was a WIP branch that was accidentially committed...
[15:09] <Trevinho> MCR1: not that accidentally, but yeah.. more or less
[15:10] <MCR1> Trevinho: But judging from the diff, the commented out textures might very well have caused this problem...
[15:15] <didrocks> mterry: hey, sorry, I was in a hangout
[15:16] <didrocks> mterry: the holidays were really good, a lot of different weather within a week with fresh snow :)
[15:16] <didrocks> some days with less ideal snow, but mostly great
[15:16] <didrocks> and nothing broken :)
[15:16] <didrocks> how was your week?
[15:16] <mterry> didrocks, always good
[15:16] <mterry> didrocks, fine personally.  From a unity perspective, we were fighting random test issues most of the week and didn't make a release, as you may have noticed.  But I just restarted a task, after approving the packaging changes, so we may have one shortly
[15:17] <mterry> didrocks, webapps is failing to build, but I'm told we just committed a fix, so I restarted that too
[15:17] <didrocks> mterry: oh, what do you started? latest run was working fine
[15:17] <mterry> didrocks, we may be all green soon
[15:17] <mterry> didrocks, unity-head.  Last build was fine, but there was packaging changes waiting for approval
[15:17] <mterry> didrocks, so I manually published
[15:17] <didrocks> mterry: hum, I see the check is running
[15:17] <didrocks> so you didn't manually publish ;)
[15:18] <didrocks> what did you run exactly?
[15:18] <mterry> didrocks, well, here's what I want to know
[15:18] <didrocks> so, let's see
[15:18] <didrocks> you did rerun something
[15:18] <mterry> didrocks, after I run ./cu2d-run -P unity, it seems to make the publishing job green, but doesn't actually publish them?  So I thought I had to start a fresh build against the existing PPA to make it work work
[15:18] <didrocks> mterry: it does publish them
[15:18] <didrocks> well, normally :)
[15:18] <mterry> didrocks, oh OK.  Well...   So I reran it for no purpose.  oh well
[15:19] <didrocks> yep, it did
[15:19] <mterry> didrocks, no biggie.  Rerunning will make the giant blob green though  :)
[15:19] <didrocks> mterry: right ;)
[15:19]  * mterry likes green lights
[15:19] <didrocks> mterry: it does rerun in this mode the tests though
[15:19] <didrocks> blocking the real hardware
[15:19] <didrocks> but not a biggie for now :)
[15:20] <didrocks> mterry: ok, so you aquired the magic of manual publishing
[15:20] <mterry> didrocks, fair.  I won't do it in the future just for the green light.  :)  I was just doing that process until I could confirm with you that -P unity does everything itself
[15:20] <didrocks> mterry: right, this is exactly what you needed :)
[15:20] <didrocks> -r <release> when we have multiple releases
[15:20] <didrocks> (head) for now
[15:20] <mterry> didrocks, yeah, just needed the magic stuff for ~/.cup2d.cfg or whatever
[15:20] <didrocks> kenvandine: cyphermox: this is for interest for you as well ^
[15:21] <didrocks> mterry: sweet! :-)
[15:21] <mterry> didrocks, wait...  what is difference between -r and -P again?
[15:21] <didrocks> mterry: so, in fact, what happened is that autopilot was broken (a change in autopilot pushed to late and direct commit to unity for changing the tests)
[15:21] <didrocks> mterry: sil2100 reverted both
[15:21] <cyphermox> thanks!
[15:21] <didrocks> that's why the first runs had 600 failures
[15:22] <didrocks> mterry: so, libunity-webapps, yeah, I pinged upstream this morning about it
[15:22]  * kenvandine reads back
[15:22] <didrocks> and then, connect them to the MP
[15:22] <didrocks> kenvandine: btw, it's failing since the 29th, please look at your stack ^ ;)
[15:22] <mterry> didrocks, yeah I asked last week about it too
[15:22] <didrocks> mterry: oh nice!
[15:23] <didrocks> mterry: so I had to point them to the MP to get it approved, let's cross fingers, it will
[15:23] <didrocks> mterry: do you know which commands is needed to only rebuild libunity-webapps?
[15:23] <mterry> didrocks, alex said it was approved this morning, and I see a new commit, so I assumed that was it
[15:23] <didrocks> from the webapps stack
[15:23] <didrocks> yep, I pinged vrruiz to get it done
[15:24] <mterry> didrocks, I did it from the web UI this time.
[15:24] <mterry> didrocks, but I imagine it's ./cu2d-run webapps libunity-webapps
[15:24] <didrocks> ah, this is where the trap is :)
[15:24] <didrocks> -R for "run"
[15:24] <didrocks> but yeah, that's it
[15:24] <mterry> right
[15:24] <didrocks> mterry: so, you just add libunity-webapps in the textbox?
[15:24] <mterry> didrocks, you can specify a particular project in the web UI too.  I think I did it right
[15:24] <mterry> didrocks, yeah
[15:24] <didrocks> perfecto :)
[15:25] <didrocks> yeah, that's the option that is passed by cu2d-run
[15:26] <didrocks> kenvandine: cyphermox: did you got your credentials btw? does this make sense to you? ^
[15:26] <didrocks> mterry: I wonder how to proceed, do you think every one should just handle its own stack for publishing if things need to unblock or should we roll?
[15:26] <didrocks> mterry: btw, it was just not packaging change, it was stuck as well due to the webapps stack failing
[15:27] <didrocks> (in case you didn't notice)
[15:27] <cyphermox> didrocks: know how to get the creds, haven't done it yet
[15:27] <didrocks> cyphermox: please configure :)
[15:27] <mterry> didrocks, I did, but since I knew the webapps failure wasn't somethign that would affect unity, I figured it was safe to manually publish
[15:27] <kenvandine> didrocks, i have my account, but i haven't pinged larry yet to grant the perms
[15:27] <kenvandine> i'll do that now
[15:27] <didrocks> kenvandine: thanks :)
[15:27] <didrocks> mterry: seems you are on top of the art!
[15:28] <mterry> didrocks, "every one handle its own stack for publishing" -- you mean have each team member monitor it?  seems reasonable
[15:28] <didrocks> mterry: yeah, as each one is looking of what was merged in their stack :)
[15:28] <didrocks> if we are blocked by another and don't know the impact, just talking would work?
[15:28] <mterry> didrocks, of course, it's easy to poke as well
[15:28] <didrocks> good :)
[15:29] <mterry> didrocks, yeah, last week I was doing a lot of looking just because credentials for others weren't sorted and they were doing mobile sprint stuff
[15:29] <didrocks> kenvandine: so please, look at the jobs, libunity-webapps was failing, thanksfully, mterry handled it
[15:29] <kenvandine> mterry, thanks!
[15:29] <didrocks> mterry: sounds good to me :)
[15:29]  * kenvandine needs to check those jobs daily :)
[15:29] <didrocks> kenvandine: how are you btw? I heard that friends is just around the corner?
[15:30] <didrocks> and you had nice memory consumption reduction in rewriting the dee part in vala?
[15:30] <kenvandine> yup, we plan to land it all this week in raring
[15:30] <kenvandine> yeah... i am trying to finish that up now
[15:30] <kenvandine> didrocks, we refactored friends-service so it exits after all threads finish
[15:31] <kenvandine> so no more long running python process :)
[15:31] <kenvandine> and the memory consumption for the service written in vala is MUCH lower
[15:32] <didrocks> kenvandine: sweet!
[15:32] <didrocks> kenvandine: then, can you focus back on getting upstream having integration tests (on webcreds first)?
[15:32] <didrocks> kenvandine: they were supposed to have it done by this week, but robru told me this morning that the progress weren't that great?
[15:33] <kenvandine> robru is up already?
[15:33] <didrocks> kenvandine: no, he wasn't in bed rather :p
[15:33] <kenvandine> hehe
[15:34] <didrocks> kenvandine: so, no more news as far as you know?
[15:34] <mterry> didrocks, btw, we made some improvements in artifacts and crashes
[15:34] <kenvandine> no
[15:34] <didrocks> mterry: oh right, I read about this! It's awesome that now everything fails when we have a failure :)
[15:34] <mterry> didrocks, so now we collect the .crash files and fail the check step if there are compiz/X crashes
[15:34] <kenvandine> didrocks, i'll get signon-ui enabled for autolanding
[15:34] <kenvandine> it's ready
[15:34] <didrocks> kenvandine: great! we do have integration tests for it then?
[15:34] <mterry> didrocks, unfortunately, I only had experience with nvidia crashes, which didn't give us good stack traces
[15:35] <kenvandine> good unit test coverage
[15:35] <kenvandine> but not really integration tests
[15:35] <mterry> didrocks, we now install some -dbg packages that may be helpful and run apport-retrace on the crash file.  But again, it wasn't much help on nvidia
[15:35] <kenvandine> didrocks,  how was fosdem?
[15:35] <didrocks> mterry: at least, stopping when we should stop is a good first part ;)
[15:35] <didrocks> mterry: ok, let's cross fingers than next time, we'll get better results
[15:35] <mterry> didrocks, so for nvidia, because we felt like the crashes were graphics related, we decided to not stop the build for such crashes (but still do for ati and intel)
[15:35] <didrocks> (on non nvidia)
[15:35] <didrocks> mterry: makes sense, sounds good to me
[15:35] <kenvandine> didrocks, or did you not make fosdem...
[15:36] <didrocks> kenvandine: no, I was skiing, so no fosdem this year :)
[15:36] <didrocks> I would have love to, but muscles were too painful after a week anyway
[15:36] <mterry> didrocks, further improvement would be to run "ubuntu-bug XXX.crash --save=logfile".  But right now, that needs to be interactive.  So if we want such an improvement, we need to add a non-interactive mode to ubuntu-bug
[15:37] <mterry> didrocks, I think fginther looked into that briefly, but didn't start working on anything
[15:37] <didrocks> mterry: maybe let's see how often we have those issues and decide from then, wdyt?
[15:37] <didrocks> oh btw, hey fginther!
[15:37] <mterry> didrocks, sure.  But I bet such logs would be helpful if we do hit such crashes in the future.  It's hard to work from just a crash file
[15:37] <mterry> didrocks, but yeah, not an urgent task
[15:38] <didrocks> fginther: it seems that you only enabled the "latestsnapshot" fast track (like in resort parks) only for unity/compiz/nux? can you enable that for all autolanding jobs and be part of the standard configuration?
[15:38] <didrocks> mterry: agreed :)
[15:38] <mterry> didrocks, fginther and sil2100 were a bunch of help last week, as you might expect
[15:38] <didrocks> they rock! :-)
[15:38] <didrocks> and sil2100 told me that he's still continuing on getting the number of autopilot tests failing down
[15:39] <didrocks> kenvandine: oh, another task once "friends" is done, the webapps split up to get all those autolanding in the future :)
[15:41] <kenvandine> i asked for an update on that this morning
[15:42] <didrocks> excellent!
[15:49] <fginther> didrocks, morning!
[15:49] <didrocks> hey fginther :)
[15:51] <fginther> didrocks, I can hopefully get the fast track changes fully enabled today. jenkins is a big PITA, so I'll need to work it around a restart of server
[15:52] <didrocks> fginther: sweet! :)
[16:11] <smspillaz> bregma: hey, let me know when we can discuss the preferred the switcher controller design. I think there's been some misunderstanding as I mentioned in my email
[16:11]  * smspillaz goes to bed for now
[16:11] <luv> oh guys, came back to work from fosdem today and the lack of social interaction - just sitting at the computer and coding - is killing me
[16:12] <smspillaz> luv: go for a walk then
[16:13] <luv> i will try to work on getting my branch mergable to cheer me up ... but yeah that's a probably better idea :-)
[16:18] <sil2100> smspillaz: +1 for the switcher dicussion
[16:18] <sil2100> smspillaz: goodnight!
[16:31] <didrocks> kenvandine: mterry: cyphermox: btw, I asked you to note if you have any remaining questions on the daily release process, do you have any then?
[16:31] <didrocks> I'll write tomorrow morning the FAQ
[16:31] <mterry> didrocks, no...  i don
[16:31] <mterry> i don't think so
[16:32] <mterry> didrocks, fginther: gnome-control-center-unity, indicator-sync, and indicator-bluetooth need to be added to autolanding process
[16:32] <didrocks> mterry: indicator-sync is already
[16:32] <mterry> ah good
[16:32] <didrocks> mterry: yeah for the 2 others
[16:32] <didrocks> mterry: g-c-c-u, part of another stack?
[16:32] <mterry> didrocks, I think we talked about it earlier as "misc" material
[16:32] <mterry> since it has no tests etc
[16:33] <didrocks> mterry: that's fine for me, maybe at some point, we'll move them from misc to something else :)
[16:34] <didrocks> fginther: can you ensure you have jenkins merger for those? ^
[16:34] <fginther> didrocks, mterry g-c-c-u has an autolanding job, hmmmm
[16:34] <didrocks> mterry: are you going to do the bootstrap + inline packaging changes if needed for g-c-c-u and indicator-bluetooth?
[16:34] <didrocks> fginther: indicator-bluetooth as well?
[16:34] <fginther> didrocks, checking...
[16:36] <fginther> didrocks, mterry, no autolanding job for indicator-bluetooth.  will get one added
[16:36] <didrocks> thanks fginther :)
[16:36] <didrocks> mterry: oh, also you did some checking on https://launchpad.net/testapp, isn't it?
[16:36] <didrocks> telling them it's a bad name, did we get any progress?
[16:36] <mterry> didrocks, I did the bluetooth inlining already
[16:36] <mterry> didrocks, MR in progress
[16:37] <mterry> didrocks, I thought gccu had it already?
[16:37] <didrocks> mterry: great! :) needing review for anything? (bootstrapping?)
[16:37] <mterry> didrocks, bootstrapping isn't done yet, because inline branch hasn't landed
[16:37] <mterry> didrocks, https://code.launchpad.net/~mterry/indicator-bluetooth/inline/+merge/145924
[16:38] <alesage> ping didrocks, can I help with Jenkins jobs for indicator-bluetooth?
[16:38] <didrocks> ah, let's wait for cyphermox to finish the review then, hopefully, we can then have it all ready tomorrow ^
[16:38] <didrocks> alesage: hey, yeah, that would be lovely :)
[16:38] <alesage> didrocks, ok will set to work on in a bit and report
[16:38] <didrocks> alesage: thanks a lot!
[16:39] <didrocks> mterry: and for testapp? I'm not sure anymore I asked you to look at it
[16:40] <didrocks> I think I did and we discussed the naming
[16:40] <mterry> didrocks, hmm
[16:40] <mterry> didrocks, testapp...  I remember doing something with it, but what did you ask me to do?
[16:41] <didrocks> mterry: I think it was the inlining, bootstrapping, usual stuff :)
[16:41] <mterry> didrocks, I think I was semi-blocking on bug 1089561
[16:41] <didrocks> mterry: did you email thomi about it?
[16:41] <mterry> Before we started using that name in all our config scripts
[16:42] <mterry> didrocks, I think, in a group thread way back.   But I can poke again
[16:42] <didrocks> mterry: if you can, that would be great :)
[16:42] <didrocks> mterry: autopilot is dep on it
[16:42] <didrocks> I had to copy it to the ppa
[16:47] <didrocks> mterry: https://code.launchpad.net/~didrocks/gnome-control-center-unity/bootstrap/+merge/146464
[16:47] <didrocks> mterry: once merged, we'll add it together to the stack of packages
[16:51] <mterry> didrocks, approved
[16:52] <didrocks> thanks :)
[17:10] <didrocks> fginther: are you sure that the g-c-c-u jobs are running? it's been more than 15 minutes that a merge is approved and I don't see any of those jobs running
[17:10] <fginther> didrocks, looking
[17:14] <mterry> sil2100, enough unity tests are failing that we can't pass autopilot.  We're right up against the line (62, 60, 60) which is just too much.
[17:16] <didrocks> mterry: we had a crash again on nvidia it seems, isn't it?
[17:16] <luv> should I mark lp: #738288 a duplicate of lp: #1107866 ?
[17:17] <fginther> mterry, it's a compiz crash
[17:17] <mterry> didrocks, yes.  But that actually shouldn't stop the build (though I realize it did here).  But I also thought it was 180+ test failures to stop the build
[17:17] <mterry> fginther, I thought we were allowing nvidia compiz crashes
[17:17] <fginther> the 'ignore compiz crash on nvidia' hack didn't work :-(
[17:18] <didrocks> mterry: are you sure we have 60*3?
[17:18] <mterry> didrocks, 240+ rather.  I can do 60*3  :)
[17:18] <didrocks> mterry: isn't it 60 in total?
[17:18] <mterry> didrocks, man, I'm drunk
[17:18] <mterry> didrocks, right!  20 each
[17:18] <didrocks> mterry: on a monday morning? shame on you! :)
[17:18] <mterry> didrocks, math is hard
[17:18] <didrocks> heh
[17:18] <didrocks> yeah, the ui can be confusing
[17:19] <didrocks> but right, the hack for ignoring nvidia needs tweaking still
[17:19] <didrocks> fginther: I had some connexion issue, didn't see if you answered on g-c-c-u
[17:19] <mterry> didrocks, do you happen to know the number that causes failure?  Is it 60?
[17:20] <mterry> or rather, 61
[17:20] <didrocks> mterry: the number will never cause a red on this job, but on the -check one
[17:20] <didrocks> mterry: this job will be red if:
[17:20] <mterry> didrocks, fair
[17:20] <didrocks> - the installation failed
[17:20] <didrocks> - there is a crash
[17:20] <didrocks> and this is propagated to the -check one if so
[17:20] <mterry> didrocks, but I am curious.  I realize this red-job is due to the nvidia crash
[17:21] <didrocks> so you want to know the exact number of a failure on -check?
[17:21] <didrocks> (if all children jobs are passing)
[17:21] <mterry> didrocks, it's some percent check in the -check job.  I guess I'm curious what that is these days
[17:21] <didrocks> ah :)
[17:21] <mterry> didrocks, so I know if we'll pass once we fix the nvidia check
[17:21] <didrocks> mterry: jenkins/etc/autopilot.rc
[17:21] <didrocks> this is the default
[17:22] <didrocks> so 8% per config, we should put it down
[17:22] <fginther> didrocks, I'm debugging the issue with g-c-c-u.
[17:22] <didrocks> fginther: thanks :)
[17:24] <mterry> didrocks, as sil2100 improves them, we should ratchet it down 1 by 1  :)
[17:25] <didrocks> mterry: agreed! :)
[17:26] <didrocks> mterry: so, FYI, this is the default value
[17:26] <didrocks> there is an override on the file system in the jenkins cu2d directory
[17:26] <didrocks> like indicators.autopilotrc
[17:26] <didrocks> based after stack name
[17:27] <didrocks> (this one is 2%)
[17:27] <didrocks> and oif.autopilotrc is 0%
[17:36] <fginther> didrocks, I can't say why g-c-c-u did not trigger automatically, but it is building now
[17:37] <didrocks> fginther: you think that next merge will trigger automatically?
[17:37] <didrocks> fginther: you can add the fast track for latestsnapshot to it too btw ;)
[17:38]  * sil2100 is fighting a strange glib signal issue
[17:39] <fginther> didrocks, perhaps the next one will be automatic, jenkins has been difficult to work with lately
[17:39] <didrocks> fginther: I'm hoping so :)
[17:40] <didrocks> sil2100: did you see that one of your MP against unity is still pending?
[17:40] <sil2100> didrocks: oh, let me see
[17:43] <fginther> mterry, I found the issue with the compiz crash/nvidia failure. The fix is in place for the next run
[17:45]  * mterry hugs fginther 
[17:51] <didrocks> mterry: got a minute to add g-c-c-u to the daily stack?
[17:51] <mterry> didrocks, I'm running to lunch now
[17:52] <didrocks> want me to add it and comment here though?
[17:52] <mterry> didrocks, can add when I get back (you mean edit cupstream2distro bzr in jenkins/etc?)
[17:52] <mterry> didrocks, then poke fginther to update it on the other side ?  :)
[17:52] <didrocks> mterry: right, but you need an archive admin as well :)
[17:52] <didrocks> mterry: there is no "other side" :)
[17:52] <mterry> didrocks, well, to have jenkins bzr pull
[17:53] <didrocks> mterry: not needed ;)
[17:53] <mterry> didrocks, oh!  ok
[17:53] <mterry> didrocks, so what does the archive admin do?
[17:53] <didrocks> mterry: the archive admin has to bzr pull, but on lillypilly
[17:53] <didrocks> not something that has to do with jenkins :)
[17:53] <didrocks> basically, this is taking 2 minutes to do, I can do with comment if you want
[17:54] <mterry> didrocks, I just updated bzr
[17:54] <mterry> oh shoot
[17:54] <mterry> OK, now I've updated bzr
[17:54] <didrocks> mterry: did you push your change?
[17:54] <mterry> didrocks, so you're an archive admin, eh?  Poke
[17:54] <didrocks> yep :)
[17:55] <fginther> didrocks, g-c-c-u finally merged
[17:55] <didrocks> fginther: yeah, we are discussing next step, thanks! :)
[17:55]  * mterry goes to eat
[17:55] <didrocks> mterry: ok, I'm doing the change and pushing then
[17:58] <robru> didrocks, hi
[17:58] <didrocks> ah, you just pushed mterry :)
[17:58] <didrocks> hey robru
[17:59] <didrocks> ok, so your rev 199 is good, adding the component to jenkins/etc/misc-head.cfg as we want it to be part on the "misc" stack
[17:59] <didrocks> then, something important
[17:59] <didrocks> being sure that no misc stack build is running
[17:59] <didrocks> as reconfiguring to add the new component is stopping the current jobs
[17:59] <didrocks> we are good, so launching reconfigure
[18:00] <didrocks> cd jenkins/
[18:00] <didrocks> ./cu2d-update-stack -U ./etc/misc-head.cfg
[18:00] <didrocks> -> this is reconfiguring all the branches from the misc-head stack
[18:01] <didrocks> (setting the right target)
[18:01] <didrocks> as well as creating the new jenkins jobs and updating the existing ones
[18:02] <didrocks> then, you can see the new job in /view/cu2d/view/Misc.%20Head/
[18:02] <didrocks> (which never ran)
[18:02] <didrocks> it will be part of next release
[18:02] <didrocks> finally, as explained in "Copy to distro" in http://blog.didrocks.fr/post/Unity%3A-release-early%2C-release-often%E2%80%A6-release-daily%21-%28part-3%29, we have a special filters for components
[18:02] <didrocks> on the distro side
[18:03] <didrocks> for that, we need to ping an archive admin
[18:03] <didrocks> (doing that right now)
[18:03] <didrocks> who will just cd cu2d
[18:03] <didrocks> and bzr pull trunk
[18:03] <didrocks> to get the latest list of components that are allowed to be published daily
[18:03] <didrocks> (the pull is done manually by an archive admin for security concerns)
[18:04] <didrocks> and done
[18:04] <didrocks> so tomorrow, gnome-control-center-unity will be part of the daily release (even if it has nothing to release right now)
[18:04] <didrocks> argh, no mterry
[18:04] <didrocks> kenvandine: cyphermox: robru: ^^
[18:04] <robru> mterry just went to lunch
[18:04] <didrocks> kenvandine: also, once mterry is back, can you please pastebin him that?
[18:05] <didrocks> robru: if you are around when he's back :)
[18:05] <didrocks> thanks!
[18:46] <arges> hi. I have a question about bug 968855. it says it is 'Fix Committed' in precise, but I cannot locate which -proposed package, or bzr commit this ended up in. thanks
[18:52] <seb128> arges, I think it's not fixed in raring
[18:53] <seb128> arges, the fix is http://bazaar.launchpad.net/~unity-greeter-team/unity-greeter/0.2/revision/402
[18:53] <arges> seb128: ok looking...
[18:55] <arges> seb128: ok looks like reporter is having additional issues even with this update, i'll make sure those get updated.
[18:57] <seb128> arges, what update?
[22:06] <luv> xgettext: warning: file `plugins/networkarearegion/networkarearegion.xml.in' extension `xml' is unknown; will try C
[22:06] <luv> anyone got this before?
[22:06] <luv> (trunk unity, installed using apt-src and this is result of second run of dpkg-buildpackage in the src package directory, first run goes fine)
[23:13] <luv> right, the problem is that dpkg-buildpackage deleted po/unity.po