[08:08] <didrocks> hey Mirv, sil2100 :)
[08:08] <didrocks> how was your week-end?
[08:48] <didrocks> mmrazik: hey, how are you?
[08:48] <mmrazik> didrocks: morning
[08:48] <mmrazik> didrocks: whats up?
[08:48] <didrocks> mmrazik: do you have a minute for a quick call with jibel? We have some autopilot-env requests
[08:48] <mmrazik> sure
[08:48] <didrocks> (also, let's check if jibel is available :))
[08:53] <Mirv> didrocks: hello, pretty fine, some family visiting etc
[08:53] <Mirv> didrocks: how was yours?
[08:54] <didrocks> 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] <didrocks> 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] <didrocks> even if the videos don't reflect how beautiful and impressive this is :)
[08:56] <didrocks> Mirv: I wanted to ask you about the compiz fullsceen opengl fix, where are we with this?
[08:57] <Mirv> nice looking stuff, surely awesome seen live
[08:57] <didrocks> oh yeah, it really is :)
[08:57] <didrocks> mmrazik: starting a hangout and inviting you
[08:57] <Mirv> didrocks: about 10 minutes of giving the quantal branch to you or so, so pretty good, all tested
[08:57] <didrocks> Mirv: \o/
[08:58] <didrocks> Mirv: for precise, it will be disabled by default for now, right?
[08:58] <didrocks> for the xorg guys to look it, isn't it?
[08:58] <Mirv> we just have a habit of getting final ack from another team member, so waiting sil2100 to ack it
[08:58] <didrocks> (in quantal, it's enabled by default)
[08:58] <didrocks> great :)
[08:58] <Mirv> didrocks: yes, like that, sil2100 is probably finalizing the phase-1 of precise compiz this week
[08:58] <didrocks> Mirv: for precise, maybe we can push that to a ppa rather?
[08:59] <didrocks> rather than going to the long SRU queue
[08:59] <didrocks> what do you think?
[08:59] <didrocks> and then, the xorg team can play with it
[08:59] <Mirv> didrocks: it looks it's already there since Friday (similar to quantal that was there for good time)
[08:59] <didrocks> oh good, can you ensure you/sil2100 speaks with the xorg guys then?
[08:59] <Mirv> some arm build problem though, so needs tinkering
[08:59] <didrocks> let's only push final work
[08:59] <Mirv> didrocks: yes, will do
[08:59] <didrocks> ok :)
[08:59] <didrocks> thanks a lot!
[08:59] <Mirv> np
[09:01] <mmrazik> didrocks: is the invite out?
[09:01]  * mmrazik still doesn't have anything
[09:01] <didrocks> mmrazik: it seems you are unknown on my tablet :p
[09:02] <didrocks> I just added you to my circles…
[09:03] <didrocks> ah here you are :)
[09:25] <didrocks> 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] <didrocks> mmrazik: so that we don't bother you when the list changes
[09:26] <didrocks> and you just generate from those list, it sounds easier for you?
[09:27] <mmrazik> 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] <mmrazik> and still have e.g. different preseed for the trunk and the release job
[09:28] <didrocks> mmrazik: ok, so we'll probably need some more jobs, I'll detail everything by email :)
[09:28] <mmrazik> ok
[09:28] <mmrazik> if its more then it definitely makes the generation more urgent
[09:28] <didrocks> yeah, because I thought of one thing
[09:29] <didrocks> I'll detail your everything :)
[09:29] <mmrazik> ok
[09:29] <didrocks> in the email, it's easier
[09:49] <apw> didrocks, i have just upgraded in quantal and my unity settings were reset again
[09:51] <didrocks> apw: hum, I think you are suffering from bug #1063617, with a fix that was merged into compiz trunk 6 hours ago
[09:51] <didrocks> https://code.launchpad.net/~compiz-team/compiz/compiz.fix_1063617.8/+merge/138801
[09:51] <didrocks> but maybe you can check with duflu ^
[09:51] <apw> ok ta
[09:52] <didrocks> apw: I can only see that, I hope it's the same issue
[09:54] <freedomrun> gsettings set org.gnome.nautilus.window-state start-with-status-bar true is impossible in 13.04 ??!
[09:54] <duflu> apw, didrocks: By smspillaz' last estimate it would require 9 merge proposals to fix. Only 8 have landed so far ... !? :)
[09:54] <didrocks> duflu: oh, I didn't the count right :)
[09:54] <didrocks> isn't the last one about the migration key with integrated one?
[09:55] <duflu> didrocks: Yes, Sam said so but I don't know the details
[09:56] <didrocks> so the specific case of apw "should" be fixed (hopefully)
[09:56] <apw> didrocks, thanks ...
[10:34] <mmrazik> 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] <didrocks> 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] <mmrazik> didrocks: ok
[10:36] <didrocks> 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)
[12:25] <hyperair> so the other day i read about this newfangled unity version with fixed unredirect fullscreen windows
[12:25] <hyperair> how do you know if it's working?
[12:26] <hyperair> (also team fortress 2 doesn't redraw for ~2 minutes when trying to unredirect
[14:43] <davmor2> Hey guys the Legal notice link in the home dash should it be missing from R?
[14:44] <popey> ah, didrocks was that distropatched in?
[14:45] <didrocks> it's not distro-patched, I see it here
[14:46] <didrocks> oh indeed, no
[14:46] <didrocks> hum, interesting
[14:46] <seb128> the path changed with the version?
[14:46] <didrocks> no, the version wasn't bumped
[14:46] <didrocks> let me check
[14:46] <didrocks> I remember to bzr merge the branch
[14:46] <didrocks> maybe nobody never acked it…
[14:47] <didrocks> https://code.launchpad.net/~gordallott/unity/dash-legal-link/+merge/129235
[14:47]  * didrocks grrr
[14:47] <didrocks> thanks for the notice davmor2, we'll get it fixed :)
[14:48] <davmor2> didrocks: no probs
[14:58] <sil2100> Ah, right
[14:59] <sil2100> Since hm, it was supposed to be worked on for R I think?
[14:59] <didrocks> yep
[14:59] <didrocks> sil2100: do you have the time to get it merged?
[14:59] <didrocks> I think retaking the branch, merging trunk back and repropose/approve
[14:59] <sil2100> didrocks: ok, I'll make it mergable for trunk
[14:59] <didrocks> sil2100: thanks, please feel free to get it reviewed/approve yourself
[15:00] <sil2100> Yea, since Gord probably won't be working on it anymore ;/
[15:00] <didrocks> yep
[15:00] <didrocks> thanks sil2100 ;)
[15:39] <didrocks> hey mterry, how was your week-end?
[15:40] <mterry> didrocks, hi!  good
[15:40] <didrocks> sweet ;) Sorry to bother you on Monday but I have a tasklist to hang over to you :)
[15:41] <didrocks> 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] <didrocks> * I didn't see the nux fix .pc file -> build-dep added to the -dev package, did I miss anything?
[15:41] <didrocks> * We forgot in the stack libunity-misc: https://code.launchpad.net/~unity-team/libunity-misc/trunk
[15:42] <didrocks> so I guess this one needs bootstrap/inline, and so on… :)
[15:42] <didrocks> * 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] <didrocks> 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] <didrocks> I guess that's more than enough for a Monday :p
[15:44] <mterry> 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] <mterry> didrocks, ACK on libunity-misc
[15:44] <didrocks> mterry: not very high compared to the rest TBH, good to know that my filters still work though! ;)
[15:46] <didrocks> thanks mterry ;)
[15:46] <mterry> 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] <mterry> didrocks, did get VPN access though!  Haven't set it up, but IS did
[15:46] <didrocks> mterry: yeah, no worry at all (that's why I didn't spam you the first days ;)) and good luck on emails! :-)
[15:46] <didrocks> excellent for the VPN access!
[15:47] <didrocks> I'll probably discuss more with you on autolanding how it works later this week
[15:47] <didrocks> one a quieter time for both you and I :)
[19:06] <fginther> bregma, any idea why autolanding failed? https://code.launchpad.net/~bregma/unity/fix-standalone-shorts-startup-crash/+merge/139010
[19:06] <bschaefer> fginther, yeah, Ill have a fix in a second
[19:06] <fginther> bregma, looks like a possible compiz api change?
[19:06] <fginther> bregma, thanks
[19:06] <bschaefer> fginther, compiz pushed new changes, and unity didn't reflect it
[19:22] <bregma> 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] <fginther> bregma, jenkins will rebuild unity if compiz changes
[19:23] <fginther> it will always try to build a merge proposal if it is approved
[19:23] <bregma> did it pick up the compiz-caused unity build failure or did I miss the message?
[19:24] <fginther> bregma, let me look at the logs
[19:31] <fginther> 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] <fginther> which appears to have happened here
[19:33] <fginther> bregma, also, the jenkins jobs are not smart enough to determine that a change to compiz caused unity to failed to build.
[19:35] <bregma> 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] <bregma> 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] <fginther> 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] <bregma> mterry, could you clarify what versions need bumping to remedy all the current compiz/unity build problems?
[20:45] <mterry> bregma, I'm not familiar with the specific build problems.  Let me look at the staging PPA
[20:46] <mterry> Nope, the staging is fine.  You're talking about some jenkins failures?  Related to the compiz abi bump?
[20:46] <mterry> bregma, ^
[20:47] <bregma> yes, you made a comment in bschaefer's MP to fix it
[20:48] <mterry> bregma, ok, so you're talking about the unity package.  Let me check versions
[20:49] <bregma> 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] <mterry> bregma, such packaging changes should have been a part of the branch that bumped API
[20:50] <mterry> that changed API rather
[20:50] <mterry> 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] <bregma> mm-hmm
[20:50] <mterry> bregma, but ideally we'd actually fix compiz's version
[20:51] <mterry> and then change unity's dep to be 1:1.0.0 or something clean
[20:51] <bregma> yes
[20:52] <bregma> 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] <bregma> I figure we need to talk to duflu about details
[20:54] <mterry> 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] <mterry> bregma, did the SONAME change?
[20:54] <mterry> bregma, we broke ABI or API?
[20:54] <bregma> mterry, I don;t think the SONAME changed, either
[20:54] <bregma> it's an ABI break because symbols have disappeared
[20:55] <bregma> someone is going to get spanked
[20:55] <mterry> bregma, Oh...   that should cause a SONAME bump then, eh?
[20:55] <mterry> I thought we were just adding symbols
[20:56] <mterry> Do the symbols need to disappear?  i.e. was this an accident?
[20:57] <bregma> hmm, it looks like the SONAME may have changed, I am confused by the way compiz reinvented SONAME versioning
[20:57] <mterry> bregma, I'm surprised jenkins took it if the SONAME changed (I would expect a build failure due to packaging)
[20:58] <bregma> 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] <mterry> I see, right
[20:58]  * mterry isn't super familiar with C++
[20:59] <mterry> 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] <mterry> 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] <bregma> it definitely needs discussion with duflu
[21:00] <mterry> OK.  I'm not super familiar with IRC nicks yet.
[21:01] <bregma> 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] <bregma> it's weird
[21:02] <mterry> bregma, the SONAME isn't part of the .so file name??!
[21:02] <mterry> Seems odd
[21:02] <bregma> nope -- liek I say, they reinvented how this stuff works
[21:03] <mterry> Alright
[21:03] <bregma> if someone installed the binary deb as an upgrade they'd be in for a nasty surprise