[08:08] hey Mirv, sil2100 :) [08:08] how was your week-end? [08:48] mmrazik: hey, how are you? [08:48] didrocks: morning [08:48] didrocks: whats up? [08:48] mmrazik: do you have a minute for a quick call with jibel? We have some autopilot-env requests [08:48] sure [08:48] (also, let's check if jibel is available :)) [08:53] didrocks: hello, pretty fine, some family visiting etc [08:53] didrocks: how was yours? [08:54] Mirv: oh nice! :) Mine was excellent! It was the "fêtes des lumières" (light festival) in Lyon, so a lot of people (4 millions approx.) on the street and a lot of walking :) [08:54] but nice shows like http://www.youtube.com/watch?v=51G-Ewf4B2M&list=UUwsuhgq2VBY54f8Lez8wGEQ&index=3 and http://www.youtube.com/watch?v=a8hboL4N4yc&list=UUwsuhgq2VBY54f8Lez8wGEQ&index=1 [08:54] even if the videos don't reflect how beautiful and impressive this is :) [08:56] Mirv: I wanted to ask you about the compiz fullsceen opengl fix, where are we with this? [08:57] nice looking stuff, surely awesome seen live [08:57] oh yeah, it really is :) [08:57] mmrazik: starting a hangout and inviting you [08:57] didrocks: about 10 minutes of giving the quantal branch to you or so, so pretty good, all tested [08:57] Mirv: \o/ [08:58] Mirv: for precise, it will be disabled by default for now, right? [08:58] for the xorg guys to look it, isn't it? [08:58] we just have a habit of getting final ack from another team member, so waiting sil2100 to ack it [08:58] (in quantal, it's enabled by default) [08:58] great :) [08:58] didrocks: yes, like that, sil2100 is probably finalizing the phase-1 of precise compiz this week [08:58] Mirv: for precise, maybe we can push that to a ppa rather? [08:59] rather than going to the long SRU queue [08:59] what do you think? [08:59] and then, the xorg team can play with it [08:59] didrocks: it looks it's already there since Friday (similar to quantal that was there for good time) [08:59] oh good, can you ensure you/sil2100 speaks with the xorg guys then? [08:59] some arm build problem though, so needs tinkering [08:59] let's only push final work [08:59] didrocks: yes, will do [08:59] ok :) [08:59] thanks a lot! [08:59] np [09:01] didrocks: is the invite out? [09:01] * mmrazik still doesn't have anything [09:01] mmrazik: it seems you are unknown on my tablet :p [09:02] I just added you to my circles… [09:03] ah here you are :) [09:25] mmrazik: won't it be more flexible that we give you dynamically a list of tests to run (with all tests for unity) and a list of packages to install from the ppa? [09:25] mmrazik: so that we don't bother you when the list changes [09:26] and you just generate from those list, it sounds easier for you? [09:27] didrocks: it probably would but I'm not sure how exactly to do it. This is all controlled by UTAH so its in utah config. Thomi/Chris started to write some scripts that generate it but I just checked and they don't use it yet. [09:27] and still have e.g. different preseed for the trunk and the release job [09:28] mmrazik: ok, so we'll probably need some more jobs, I'll detail everything by email :) [09:28] ok [09:28] if its more then it definitely makes the generation more urgent [09:28] yeah, because I thought of one thing [09:29] I'll detail your everything :) [09:29] ok [09:29] in the email, it's easier [09:49] didrocks, i have just upgraded in quantal and my unity settings were reset again [09:51] apw: hum, I think you are suffering from bug #1063617, with a fix that was merged into compiz trunk 6 hours ago [09:51] Launchpad bug 1063617 in compiz (Ubuntu) "1:0.9.8+bzr3319-0ubuntu1 regression: keeps setting gsettings keys to wrong values" [High,In progress] https://launchpad.net/bugs/1063617 [09:51] https://code.launchpad.net/~compiz-team/compiz/compiz.fix_1063617.8/+merge/138801 [09:51] but maybe you can check with duflu ^ [09:51] ok ta [09:52] apw: I can only see that, I hope it's the same issue [09:54] gsettings set org.gnome.nautilus.window-state start-with-status-bar true is impossible in 13.04 ??! [09:54] apw, didrocks: By smspillaz' last estimate it would require 9 merge proposals to fix. Only 8 have landed so far ... !? :) [09:54] duflu: oh, I didn't the count right :) [09:54] isn't the last one about the migration key with integrated one? [09:55] didrocks: Yes, Sam said so but I don't know the details [09:56] so the specific case of apw "should" be fixed (hopefully) [09:56] didrocks, thanks ... === Jens is now known as Guest36172 === Zhenech_ is now known as Zhenech [10:34] didrocks: I assume "unity.tests.test_hud.HudAlternativeKeybindingTests.test_super_h" is not interesting for indicators and it is only in the list because "bindings" have the "indi" substring... [10:35] mmrazik: no, it's more because it has the HUD in it (and the hud is part of the indicator stack), but I thought it would be easier to include them all than doing one after another [10:36] didrocks: ok [10:36] mmrazik: this also enables to ensure that by default, the hud backend doesn't give back wrong result making the frontend crashing (we never know what can happen) === mmrazik is now known as mmrazik|lunch === Guest36172 is now known as jbache === _salem is now known as salem_ === mardy_ is now known as mardy [12:25] so the other day i read about this newfangled unity version with fixed unredirect fullscreen windows [12:25] how do you know if it's working? [12:26] (also team fortress 2 doesn't redraw for ~2 minutes when trying to unredirect === mmrazik|lunch is now known as mmrazik === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === dandrader is now known as dandrader|lunch [14:43] Hey guys the Legal notice link in the home dash should it be missing from R? [14:44] ah, didrocks was that distropatched in? [14:45] it's not distro-patched, I see it here [14:46] oh indeed, no [14:46] hum, interesting [14:46] the path changed with the version? [14:46] no, the version wasn't bumped [14:46] let me check [14:46] I remember to bzr merge the branch [14:46] maybe nobody never acked it… [14:47] https://code.launchpad.net/~gordallott/unity/dash-legal-link/+merge/129235 [14:47] * didrocks grrr [14:47] thanks for the notice davmor2, we'll get it fixed :) [14:48] didrocks: no probs [14:58] Ah, right [14:59] Since hm, it was supposed to be worked on for R I think? [14:59] yep [14:59] sil2100: do you have the time to get it merged? [14:59] I think retaking the branch, merging trunk back and repropose/approve [14:59] didrocks: ok, I'll make it mergable for trunk [14:59] sil2100: thanks, please feel free to get it reviewed/approve yourself [15:00] Yea, since Gord probably won't be working on it anymore ;/ [15:00] yep [15:00] thanks sil2100 ;) === dandrader|lunch is now known as dandrader|afk [15:39] hey mterry, how was your week-end? [15:40] didrocks, hi! good [15:40] sweet ;) Sorry to bother you on Monday but I have a tasklist to hang over to you :) [15:41] FYI I asked sil2100 to take care of https://code.launchpad.net/~gordallott/unity/dash-legal-link/+merge/129235 so that it's finally merged into trunk (we lost the legal notice with latest release) [15:41] * I didn't see the nux fix .pc file -> build-dep added to the -dev package, did I miss anything? [15:41] * We forgot in the stack libunity-misc: https://code.launchpad.net/~unity-team/libunity-misc/trunk [15:42] so I guess this one needs bootstrap/inline, and so on… :) [15:42] * finally, I guess that the new hud package (already inlined by ted) would be great to have a double check that it's similar to our packaging standard + bootstrap :) [15:43] I think cyphermox is still fighting on the test for the 4 packages that are failing on tests for the indicator stack, not sure how busy you are, but maybe you can give a hand [15:43] I guess that's more than enough for a Monday :p [15:44] didrocks, no you didn't miss the nux fix. I just didn't put it high on my todo, I can get to it today [15:44] didrocks, ACK on libunity-misc [15:44] mterry: not very high compared to the rest TBH, good to know that my filters still work though! ;) [15:46] thanks mterry ;) [15:46] didrocks, I came back from vacation for a few days last week and then had another day off. Having these short days on, short days off means it's hard to recover from email [15:46] didrocks, did get VPN access though! Haven't set it up, but IS did [15:46] mterry: yeah, no worry at all (that's why I didn't spam you the first days ;)) and good luck on emails! :-) [15:46] excellent for the VPN access! [15:47] I'll probably discuss more with you on autolanding how it works later this week [15:47] one a quieter time for both you and I :) === mmrazik is now known as mmrazik|otp === mmrazik|otp is now known as mmrazik === gatox is now known as gatox_lunch === dandrader|afk is now known as dandrader === gatox_lunch is now known as gatox === gatox is now known as gatox1 === gatox1 is now known as gatox === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [19:06] bregma, any idea why autolanding failed? https://code.launchpad.net/~bregma/unity/fix-standalone-shorts-startup-crash/+merge/139010 [19:06] fginther, yeah, Ill have a fix in a second [19:06] bregma, looks like a possible compiz api change? [19:06] bregma, thanks [19:06] fginther, compiz pushed new changes, and unity didn't reflect it [19:22] fginther, is Jenkins not supposed to try to build Unity of Compiz changes, or is that a later-stage Jenkins that does that? [19:23] bregma, jenkins will rebuild unity if compiz changes [19:23] it will always try to build a merge proposal if it is approved [19:23] did it pick up the compiz-caused unity build failure or did I miss the message? [19:24] bregma, let me look at the logs [19:31] bregma, jenkins didn't catch this one on the unity rebuild. There is an optimization to not rebuild unity if another merge proposal is pending. [19:31] which appears to have happened here [19:33] bregma, also, the jenkins jobs are not smart enough to determine that a change to compiz caused unity to failed to build. [19:35] sure, but a rebuild of unity that was kicked off by a changed dependency like compiz failed, the person looking at the logs would know [19:36] then, if there was some way to delay pending builds until that was resolved, we'd have fewer manual remarking merges as approved, but I don't think it's worth the effort to make that work [19:38] bregma, yes, that is correct. We're lacking builders and other resources to make this work, but hopefully we'll get there this cycle. [20:44] mterry, could you clarify what versions need bumping to remedy all the current compiz/unity build problems? [20:45] bregma, I'm not familiar with the specific build problems. Let me look at the staging PPA [20:46] Nope, the staging is fine. You're talking about some jenkins failures? Related to the compiz abi bump? [20:46] bregma, ^ [20:47] yes, you made a comment in bschaefer's MP to fix it [20:48] bregma, ok, so you're talking about the unity package. Let me check versions [20:49] well, I'd like to see the compiz version bumped because of the non-backwards-compatible API change that cause all this breakage, but it's unclear how that happens with this continuous packaging stuff [20:50] bregma, such packaging changes should have been a part of the branch that bumped API [20:50] that changed API rather [20:50] bregma, so since we didn't bump the compiz version, unity needs to add a build dep in debian/control on something hideous like 1:0.9.9~daily12.12.05bzr3521pkg0raring0 [20:50] mm-hmm [20:50] bregma, but ideally we'd actually fix compiz's version [20:51] and then change unity's dep to be 1:1.0.0 or something clean [20:51] yes [20:52] so I approved bschaefer's MP so we can get build backlog cleared on the premise we could work out the version bumps [20:52] I figure we need to talk to duflu about details [20:54] bregma, so I don't know what the proper compiz version should be. 1.0.0 or 0.9.10. But either way, do a normal everyday version bump in the code and add a debian/changelog entry with the new version [20:54] bregma, did the SONAME change? [20:54] bregma, we broke ABI or API? [20:54] mterry, I don;t think the SONAME changed, either [20:54] it's an ABI break because symbols have disappeared [20:55] someone is going to get spanked [20:55] bregma, Oh... that should cause a SONAME bump then, eh? [20:55] I thought we were just adding symbols [20:56] Do the symbols need to disappear? i.e. was this an accident? [20:57] hmm, it looks like the SONAME may have changed, I am confused by the way compiz reinvented SONAME versioning [20:57] bregma, I'm surprised jenkins took it if the SONAME changed (I would expect a build failure due to packaging) [20:58] there was a change that made some functions const -- that causes the symbols to change their mangled names, so in effect they've disappeared and now ones have appeared [20:58] I see, right [20:58] * mterry isn't super familiar with C++ [20:59] bregma, OK, so that was presumably an expected change and we have to do the whole soname bumping dance. Which involves changing the package name in debian/control and all that [20:59] bregma, how much help do you need with that? i.e. do you want me to do a branch or do you just want a review from me? [21:00] it definitely needs discussion with duflu [21:00] OK. I'm not super familiar with IRC nicks yet. [21:01] the packaging would never break woth compiz due to a SONAME change because the SONAME isn;t tracked by the .so file name or any of the other stuff the packaging knows about [21:02] it's weird [21:02] bregma, the SONAME isn't part of the .so file name??! [21:02] Seems odd [21:02] nope -- liek I say, they reinvented how this stuff works [21:03] Alright [21:03] if someone installed the binary deb as an upgrade they'd be in for a nasty surprise === salem_ is now known as _salem === jasoncwarner_ is now known as jasoncwarner