=== 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 | ||
didrocks | hey sil2100, how are you? | 08:26 |
---|---|---|
sil2100 | didrocks: hello, I'm fine - how was your holiday? ;) | 08:37 |
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:38 |
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:40 |
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:41 |
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 :/ | 08:42 |
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:13 |
didrocks | sil2100: hum, so the refactorization is wrong? | 09:14 |
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:15 |
mmrazik | didrocks: mhm... might be still the case. Let me check | 09:16 |
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:17 |
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:18 |
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:19 | |
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:20 |
sil2100 | didrocks: ok, so it seems we were testing revision 3112, while thomi was still pushing his changes | 09:21 |
sil2100 | didrocks: let's try re-running the tests on the latest revision 3116 maybe to see if he fixed everything | 09:22 |
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:23 |
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:24 |
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:25 |
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:26 |
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:27 |
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:28 |
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:29 |
didrocks | and tell to have them merged in synced before a 00 UTC or after 6 UTC | 09:30 |
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:31 |
didrocks | sil2100: are we sure everything will pass with latest autopilot? | 09:32 |
didrocks | your pick :) | 09:32 |
sil2100 | hmmm ;p | 09:32 |
* 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:33 |
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:34 |
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:35 |
mmrazik | sil2100: the autopilot ppa is gone | 09:36 |
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:37 |
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:39 |
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:40 |
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:41 |
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:42 |
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:43 |
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:44 |
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:49 |
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:50 | |
didrocks | mmrazik: \o/ | 09:51 |
sil2100 | didrocks: direct pushes with reverts done | 09:56 |
didrocks | sil2100: sweet! let me rebuild unity then :) | 09:56 |
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:57 |
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* | 09:58 |
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:11 |
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:15 |
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:16 |
MCR1 | didrocks: Hi | 10:17 |
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:19 |
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:20 |
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:22 |
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:23 |
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:24 |
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:25 |
MCR1 | Ok, I'll find it and will work on it this evening. | 10:26 |
didrocks | thanks MCR1 :) | 10:27 |
MCR1 | np - sorry if I did not get everything right immediately... | 10:28 |
didrocks | no worry, waiting for your 2 new MP :) | 10:28 |
* MCR1 is still learning and quilt was a fight already ;) | 10:29 | |
MCR1 | didrocks: Found it. It is in ccs_gnome_integration_constants.c | 10:32 |
didrocks | yep :) | 10:32 |
MCR1 | bug 1115128 | 10:41 |
ubot5 | 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:41 |
didrocks | sil2100: excellent email btw :) | 10:58 |
sil2100 | didrocks: thanks ;p | 11:04 |
didrocks | sil2100: see run 71 :/ | 11:15 |
didrocks | sil2100: exactly the same, did I miss anything? | 11:15 |
didrocks | sil2100: the package is 6.12.0daily13.02.04.1-0ubuntu1 from the daily ppa | 11:16 |
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:17 |
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:19 |
didrocks | MCR1: please test this with openining g-c-c with your branch | 11:20 |
sil2100 | hmm | 11:22 |
=== mmrazik is now known as mmrazik|lunch | ||
sil2100 | I'll look into it in a moment | 11:22 |
sil2100 | didrocks: ah ha! | 11:23 |
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:24 |
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:28 |
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:29 |
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:38 |
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:40 |
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:41 |
=== mmrazik|lunch is now known as mmrazik | ||
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:42 |
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:43 |
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:45 |
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:46 |
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:47 |
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:48 |
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:49 |
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:50 |
mmrazik | didrocks: yes and that job is using preseed.cfg | 11:51 |
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:52 |
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:53 |
mmrazik | didrocks: yup. its in the job configuration. Removing it and keeping only daily | 11:54 |
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:55 |
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 | 11:56 |
sil2100 | Phew | 12:11 |
=== MacSlow is now known as MacSlow|lunch | ||
=== _salem is now known as salem_ | ||
ricotz | Cimi, hi :) | 13:02 |
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:03 |
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:04 |
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:05 |
Cimi | ricotz, what is broken? | 13:06 |
ricotz | Cimi, i will try to do a screenshot | 13:07 |
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:13 |
Cimi | menubar seems | 13:14 |
ricotz | added an Adwaita reference screenshot too | 13:15 |
seb128 | ricotz, ok | 13:17 |
seb128 | seems like it could be easy to fix issues | 13:17 |
=== salem_ is now known as _salem | ||
Cimi | patches accepted :D | 13:18 |
=== _salem is now known as salem_ | ||
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:28 |
=== rsalveti_ is now known as rsalveti | ||
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:35 |
didrocks | MCR1: yeah, thanks for the description, you can already do the two changes for the gconf key | 13:37 |
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:38 |
* MCR1 also found another unrelated typo and mistake in compiz-profile-active-Default.convert and compiz-profile-active-Default.convert | 13:41 | |
MCR1 | they are referring to refres_rate and detect_refres_rate, which is definitely wrong as well... | 13:42 |
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:45 |
MCR1 | didrocks: Sure. Will do. | 13:46 |
didrocks | thanks :) | 13:46 |
* 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 | |
ubot5 | 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:47 |
didrocks | sweet :) | 13:49 |
=== MacSlow|lunch is now known as MacSlow | ||
=== chiluk_away is now known as chiluk | ||
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:16 |
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:17 |
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:21 |
didrocks | MCR1: approved the unity side | 14:22 |
MCR1 | didrocks: yes, I think that is a good idea | 14:22 |
MCR1 | didrocks: Here is the other fix and MP: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix1115243-refresh-typos/+merge/146421 | 14:24 |
mterry | didrocks, how was your vacation? | 14:41 |
mterry | er, holiday I guess for you | 14:49 |
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:55 |
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:56 |
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:57 |
MCR1 | well | 14:58 |
MCR1 | :-D | 14:58 |
MCR1 | sil2100: Please do not look @ the WIP MPs for Compiz then... ;) | 15:00 |
mpt | andyrock, hi, are you still making progress with bug 974480? | 15:01 |
ubot5 | bug 974480 in unity (Ubuntu) "Menu Bar - Remove Notification area whitelist in 12.10" [High,In progress] https://launchpad.net/bugs/974480 | 15:01 |
andyrock | mpt, hi, nope but I can finish it by the end of this week if needed | 15:02 |
mpt | andyrock, it isn't urgent, but I think it's the sort of thing that's best done well before a release | 15:03 |
mpt | to give us time to discover apps that it breaks :-) | 15:04 |
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 |
ubot5 | bug 1103742 in unity (Ubuntu) "Launcher: Icon Backlight Mode "Edge Illumination Toggles" broken (regression)" [Low,In progress] https://launchpad.net/bugs/1103742 | 15:07 |
andyrock | mpt, sure will be done | 15:07 |
mpt | cool, thanks | 15:07 |
andyrock | np | 15:07 |
Trevinho | MCR1: as you prefer | 15:08 |
Trevinho | MCR1: is that only related to textures? | 15:08 |
MCR1 | Trevinho: I'll wait ;) | 15:08 |
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:09 |
MCR1 | Trevinho: But judging from the diff, the commented out textures might very well have caused this problem... | 15:10 |
didrocks | mterry: hey, sorry, I was in a hangout | 15:15 |
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:16 |
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:17 |
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:18 |
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:19 |
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:20 |
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:21 |
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:22 |
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:23 |
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:24 |
didrocks | yeah, that's the option that is passed by cu2d-run | 15:25 |
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:26 |
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:27 |
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:28 |
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:29 |
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:30 |
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:31 |
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:32 |
kenvandine | robru is up already? | 15:33 |
didrocks | kenvandine: no, he wasn't in bed rather :p | 15:33 |
kenvandine | hehe | 15:33 |
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:34 |
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:35 |
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:36 |
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:37 |
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:38 |
didrocks | kenvandine: oh, another task once "friends" is done, the webapps split up to get all those autolanding in the future :) | 15:39 |
kenvandine | i asked for an update on that this morning | 15:41 |
didrocks | excellent! | 15:42 |
fginther | didrocks, morning! | 15:49 |
didrocks | hey fginther :) | 15:49 |
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:51 |
didrocks | fginther: sweet! :) | 15:52 |
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:11 |
smspillaz | luv: go for a walk then | 16:12 |
luv | i will try to work on getting my branch mergable to cheer me up ... but yeah that's a probably better idea :-) | 16:13 |
sil2100 | smspillaz: +1 for the switcher dicussion | 16:18 |
sil2100 | smspillaz: goodnight! | 16:18 |
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:31 |
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:32 |
didrocks | mterry: that's fine for me, maybe at some point, we'll move them from misc to something else :) | 16:33 |
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:34 |
=== dandrader is now known as dandrader|afk | ||
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:36 |
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:37 |
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:38 |
didrocks | mterry: and for testapp? I'm not sure anymore I asked you to look at it | 16:39 |
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:40 |
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 |
ubot5 | bug 1089561 in testapp "testapp is a bad name" [Undecided,New] https://launchpad.net/bugs/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:41 |
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:42 |
=== davidcalle_ is now known as davidcalle | ||
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:47 |
mterry | didrocks, approved | 16:51 |
didrocks | thanks :) | 16:52 |
=== dandrader|afk is now known as dandrader | ||
=== francisco is now known as Guest86767 | ||
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:10 |
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:14 |
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:16 |
ubot5 | Launchpad bug 738288 in unity (Ubuntu) "Add window list to Launcher icon menu" [Undecided,Incomplete] https://launchpad.net/bugs/738288 | 17:16 |
ubot5 | 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:16 |
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:17 |
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:18 |
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:19 |
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:20 |
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:21 |
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:22 |
mterry | didrocks, as sil2100 improves them, we should ratchet it down 1 by 1 :) | 17:24 |
didrocks | mterry: agreed! :) | 17:25 |
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:26 |
didrocks | (this one is 2%) | 17:27 |
didrocks | and oif.autopilotrc is 0% | 17:27 |
fginther | didrocks, I can't say why g-c-c-u did not trigger automatically, but it is building now | 17:36 |
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:37 |
* sil2100 is fighting a strange glib signal issue | 17:38 | |
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:39 |
didrocks | sil2100: did you see that one of your MP against unity is still pending? | 17:40 |
sil2100 | didrocks: oh, let me see | 17:40 |
fginther | mterry, I found the issue with the compiz crash/nvidia failure. The fix is in place for the next run | 17:43 |
* mterry hugs fginther | 17:45 | |
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:51 |
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:52 |
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:53 |
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:54 |
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:55 |
robru | didrocks, hi | 17:58 |
didrocks | ah, you just pushed mterry :) | 17:58 |
didrocks | hey robru | 17:58 |
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 | 17:59 |
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:00 |
didrocks | (setting the right target) | 18:01 |
didrocks | as well as creating the new jenkins jobs and updating the existing ones | 18:01 |
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:02 |
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:03 |
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:04 |
didrocks | robru: if you are around when he's back :) | 18:05 |
didrocks | thanks! | 18:05 |
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:46 |
ubot5 | 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 | 18:46 |
=== dandrader is now known as dandrader|afk | ||
seb128 | arges, I think it's not fixed in raring | 18:52 |
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:53 |
arges | seb128: ok looks like reporter is having additional issues even with this update, i'll make sure those get updated. | 18:55 |
seb128 | arges, what update? | 18:57 |
=== 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 | ||
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) | 22:06 |
=== salem_ is now known as _salem | ||
luv | right, the problem is that dpkg-buildpackage deleted po/unity.po | 23:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!