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