=== _salem is now known as salem_
=== salem_ is now known as _salem
=== mmrazik is now known as mmrazik|afk
=== mmrazik|afk is now known as mmrazik
[08:28] <sil2100> smspillaz: hi!
[08:28] <sil2100> smspillaz: I noticed that CI has failed on my revert branch - you have any idea why?
[08:29] <sil2100> https://code.launchpad.net/~sil2100/compiz/revert_vb_patches/+merge/149725
[08:35] <smspillaz> sil2100: yeah, there's a broken test in CI :( it should be fixed now
[08:35] <smspillaz> BUT
[08:36] <smspillaz> I think I know whats causing this problem anyways, so I'd probably hold off on the revert for about on hour
[08:36] <sil2100> smspillaz: excellent!
[08:36] <sil2100> smspillaz: what do you think might be the root cause?
[08:37] <smspillaz> sil2100: well, I'm pretty sure that the fact that unity even started was never even meant to work
[08:37] <smspillaz> I'm just going to roll a thing to make it force-import any new profiles if you change it from, eg, outside compizconfig
[08:39] <smspillaz> sil2100: BTW, if you just build the branch without any distro patches and install it, it won't load anything
[08:39] <smspillaz> because we have a distro patch that auto-loads the ccp plugin, which bootstraps the load process
[08:41] <smspillaz> sil2100: it just took me forever to get CCSContext in a test harness, but I've got it now
[08:44] <sil2100> smspillaz: ;)
[08:45] <sil2100> smspillaz: this is one big WTF-machine it seems
[09:06] <mterry> sil2100, does your latest landed merge mean that compiz is working again?
[09:10] <sil2100> mterry: which merge?
[09:11] <sil2100> mterry: sadly, my revert didn't go in because of CI failures, but Sam anyway said to hold for a moment more
[09:11] <mterry> sil2100, https://code.launchpad.net/~sil2100/compiz/revert_vb_patches/+merge/149725  (but now I see it didn't land)
[09:12] <mterry> sil2100, OK, no worries
[09:44] <smspillaz> sil2100: I need to debuild this thing. Could take me some time, and then I have to go out for 2 hours
[09:45] <smspillaz> sil2100: what I have atm is uploaded to ~compiz-team/compiz/compiz.fix_1130679/
[10:24] <mterry> fginther, hello!  some part of the jenkins process is running make -n coverage-xml (as you can see near the bottom of https://jenkins.qa.ubuntu.com/job/hud-ci/build=pbuilder,distribution=raring,flavor=amd64/27/console )
[10:25] <mterry> fginther, and for the hud, this is not working apparently because I dropped gtester2xunit from the Build-Depends
[10:25] <mterry> fginther, is there a way you could add that package to the jenkins build manually (but not to the package itself, since we don't want gtester2xunit in main)
[10:26] <mterry> fginther, (or don't run coverage-xml, but I assume someone added that for a reason)
[10:41]  * mhr3 hides from mterry
[10:42] <mterry> mhr3, :)
[10:44] <mterry> mhr3, if keeping old symbols is too gross, option #2 isn't so bad (new library name).  You could even drop the old symbols altogether if you wanted
[10:44] <MCR_> andyrock, https://bugs.launchpad.net/ubuntu/+source/unity/+bug/748539/comments/27
[10:44] <ubot5> Launchpad bug 748539 in unity (Ubuntu) "Multi-monitor - Panel and launcher visible on top of multimonitor non-focused fullscreen apps" [High,In progress]
[10:45] <mterry> mmrazik, ^ up above, my comments to fginther apply to you
[10:45] <mhr3> mterry, i'd rather not go to decide on this right away, #2 kinda makes sense, but it primarily breaks the scopes API, and old scopes just won't work with the old api anyway
[10:45] <andyrock> MCR_, what about OSK then?
[10:46] <mhr3> mterry, anyway, we just want this in a ppa so interested developers can use it
[10:46] <mhr3> mterry, it's not merge proposed against trunk fwiw
=== mmrazik is now known as mmrazik|lunch
[10:50] <MCR_> andyrock, OSK should already be on-top as well, no ? But simply forget it as further testing shows that this solution will just work if only the fullscreened window is on-top
[10:51] <MCR_> andyrock, once you set another window to be on-top as well, the panel comes up over the fullscreened video again :)
[10:51] <MCR_> so not exactly ideal... :(
[10:56] <mterry> mhr3, well, I didn't mark the branch as fix needed.  But obviously, this needs some thinking before we do land in trunk
[10:57] <mhr3> mterry, don't worry, i'm keeping it in mind
[11:01] <mterry> mhr3, regarding old scopes not working with the old api anyway: (A) sad-face; it would be nice if there were some compatibility layer (B) there is a difference between breaking a build and breaking functionality -- one of those makes it harder to ship a security fix for a non-updated app using libunity for example
[11:04] <mhr3> mterry, unless the non-updated app can build cleanly with the latest libunity, which it will cause it's not a scope
[11:06] <mterry> mhr3, OK...  say we have a scope packaged along with something else.  Say I have a 3rd party app in the Software Center that ships a scope.  I dunno.  This is a general principle regarding libraries and maybe scopes have special considerations, but I'm leery that it's true
[11:07] <mhr3> then the scope isn't working and you should update it :)
[11:08] <mterry> mhr3, agreed.  But I'm drawing a distinction between two types of not-working and making the claim that breaking a build is worse than breaking functionality
[11:08] <mhr3> mterry, but yes, i'm aware of all of this, we might end up putting scopes in a completely separate library or something, TBD
=== mmrazik|lunch is now known as mmrazik
[11:09] <mterry> mhr3, with the caveat that breaking functionality is also something you shouldn't do.  ;)
[11:09] <mterry> mhr3, sure.  I'll stop bugging you about it.  :)  I'm sure it will all be sorted by landing
[11:10] <mmrazik> mterry: FYI -- the hud-ci job is failing because thre are no tes-results (consequence of the gtester2xunit dep). make -n coverage-xml is working just fine.
[11:10] <mmrazik> mterry: I'll take care of it
[11:10] <mmrazik> fginther: ^
[11:10] <mterry> mmrazik, ah, OK.  I read the log wrong.  Thanks!
[11:10] <mterry> mmrazik, we can fix it by adding gtester2xunit as a special jenkins-installed package?  cool
[11:10] <andyrock> MCR_, btw i've a working solution (just need to fix a corner case with multimple VPs)
[11:11] <mmrazik> mterry: yes
[11:11] <mterry> nice
[11:11] <MCR_> andyrock, that is great to hear :)
[11:11] <mhr3> mterry, let's call breaking apis an anti-virus measure, then everyone will think it's a good thing ;D
[11:12] <mterry> mmrazik, is that a separate build than the PPA then?  i.e. we build in jenkins with special package, then later push to PPA with no special packages?
[11:12] <mmrazik> mterry: yes
[11:12] <mterry> mhr3, don't imply we have a virus problem!
[11:12] <mmrazik> mterry: we are e.g. adding coverage flags too
[11:12] <mterry> mmrazik, cool
[11:12] <MCR_> andyrock, at least I've found a workaround, which should work for 12.04 and 12.10 users
[11:12] <mmrazik> so we can generate the coverage report
[11:12] <mterry> mmrazik, ah, makes sense
[11:12] <andyrock> MCR_, sure
[11:12] <andyrock> btw I think we need to SRU it
[11:13] <MCR_> andyrock, btw - onboard has a special on-top modus, but it is turned off by default...
[11:13] <mhr3> mterry, no, no, i'm implying this is why we don't :)
[11:13] <mterry> k:)
[11:13] <mterry> I mean, :)
[11:13]  * MCR_ is looking forward to your solution, andyrock :)
[11:13] <mterry> k:) make me look like I just graduated
[11:14] <mhr3> heh
[11:26] <mmrazik> fginther, mterry: btw. jenkins should be fixed now
[11:26] <mterry> mmrazik, awesome
=== dandrader is now known as dandrader|afk
[11:52] <sil2100> smspillaz: ping
=== dandrader|afk is now known as dandrader
[12:11] <mterry> mmrazik, the "Unity Merger" launchpad account is what lands things to branches, right?
[12:11] <mmrazik> mterry: nope. its the old one. the correct one is ps-jenkins@lists.canonical.com (launchpad id: ps-jenkins)
[12:15] <mterry> mmrazik, I think we're ready to enable autolanding for unity-greeter.  Can you check to make sure things are set up correctly?  (note that we don't want auto-uploading yet)
[12:19] <mmrazik> mterry: looks good
[12:20] <mmrazik> mterry: autolanding should be set-up too. fginther created the jobs yesterday (thats why I found out about the previous merge proposal -- my watchdog was complaining there is approved but not merged MP)
[12:20] <mterry> mmrazik, ah interesting
[12:20] <mterry> thanks!
[12:20]  * mterry is eager to try it out
[12:21] <mterry> mmrazik, btw, we have launchpad pushing translation updates to trunk.  I assume that autolanding will be fine with that?
[12:21] <mmrazik> mterry: you mean launchpad pushing directly to trunk and not via autolanding?
[12:21] <smspillaz> sil2100: pong
[12:21] <mmrazik> that should work. jenkins won't notice it
[12:22] <mterry> mmrazik, yeah, I guess.  Launchpad has a feature where you can have it put translations updates directly into a branch, and we have it pointing at trunk
[12:22] <mterry> mmrazik, OK, cool
[12:22] <mterry> mmrazik, you deactivated unity-team?   I thought that was how ps-jenkins got in.  But maybe it's part of pspmteam?
[12:23] <mmrazik> mterry: I've deactivated unity-team and added canonical-product-strategy (c-p-s was already part of unity-team)
[12:23] <mterry> ah
[12:23] <mmrazik> its more less the same people but I don't like these transitive memberships
[12:23] <mmrazik> it just creates mess
[12:23] <mmrazik> so c-p-s should be everywhere for a bit more transparency
=== _salem is now known as salem_
[12:51] <MCR_> andyrock, if you're in review mode: https://code.launchpad.net/~mc-return/unity/unity.merge-fix1131152-cppcheck-issues/+merge/149801
[12:52] <MCR_> :)
[12:53] <sil2100> smspillaz: ping!
[13:03] <smspillaz> sil2100: ....pong ?
[13:03] <smspillaz> sil2100: you must have a flakey connection
[13:03] <smspillaz> as for my branch .. still working on it
[13:03] <smspillaz> I noticed that the upgrade code did not quite kick in
[13:04] <smspillaz> erm, the profile thing
[13:04] <smspillaz> its difficult to test properly
[13:04] <sil2100> smspillaz: ah, since I built what you already had in the branch but the problem was still there, so I've been wondering how the upgrades are going
[13:05] <sil2100> smspillaz: yea, today I somehow get disconnected for no reason ;/
[13:07] <smspillaz> sil2100: I'm working on it. Its a total pain to test properly, unless you know of any filesystem mocking utilities
[13:07] <sil2100> smspillaz: sadly ;(
[13:08] <smspillaz> the surrounding code is very tightly coupled with the filesystem. I could break those dependencies but it would take days
[13:08] <smspillaz> so its not worth it
[13:08] <smspillaz> I've just got a small unit test in, but it obviously can't cover everything, except the decision to import from /etc/compizconfig
[13:23] <smspillaz> ccsListAppend (list, foo);
[13:23] <smspillaz> I make that bloody mistake all the time
[13:23] <smspillaz> (it requires assignment like g_list etc)
=== danilos is now known as danilos-afk
=== francisco is now known as Guest99270
=== mmrazik is now known as mmrazik|afk
=== dandrader is now known as dandrader|afk
[15:16] <fginther> mterry, I think I've caught up on the backlog. but just in case, is there anything you need from me that mmrazik didn't resolve?
[15:31] <mterry> fginther, no...  I don't think so
[15:31] <mterry> fginther, thanks  :)
=== dandrader|afk is now known as dandrader
=== danilos-afk is now known as danilos
=== mmrazik|afk is now known as mmrazik
[16:43] <smspillaz> andyrock: Trevinho: sil2100: review coming your way: https://code.launchpad.net/~compiz-team/compiz/compiz.fix_1130679/+merge/149574
[16:43] <smspillaz> I know its big, its mostly because I moved a big chunk of code from one file to antoher
[16:45] <smspillaz> bschaefer: https://code.launchpad.net/~compiz-team/compiz/compiz.fix_1130679/+merge/149574
[16:45] <sil2100> smspillaz: big thanks! Looking, test building and testing
[16:45] <bschaefer> smspillaz, cool, ill take a look
[16:45] <smspillaz> I hate the settings code
[16:45] <smspillaz> all of it
[16:45] <bschaefer> haha
[16:45] <sil2100> heh ;) So there's more of us
[16:45] <sil2100> !
[16:45] <smspillaz> every time I have to manipulate character arrays I want to stab someone I swear
[16:46]  * bschaefer enjoys char*
[16:46] <sil2100> Ok, this review is BIG
[16:46] <sil2100> ;)
[16:47] <bschaefer> though they are a large source of error
[16:47] <smspillaz> sil2100: its mostly because I moved a few big chunks out of main.c into separate files
[16:54] <bschaefer> smspillaz, looking at getenv, we should probably be using secure_getenv
[16:54] <bschaefer> so we don't actually get the real copy ...
[16:55] <bschaefer> 386	+ char *home = getenv ("HOME");
[16:55] <bschaefer> 387	+ char *override_backend = getenv ("LIBCOMPIZCONFIG_BACKEND_PATH");
[16:56] <smspillaz> bschaefer: yep, you're right
[16:56] <bschaefer> smspillaz, I was just reading the man pages for getenv :) (I didn't know that existed)
[16:57] <smspillaz> bschaefer: neither did I, although now that I've read them I don't think its applicable in this case
[16:57] <bschaefer> smspillaz, hmm well you don't modify it, possibly making the char* you assign them to a const?
[16:57] <bschaefer> to show its read only
[16:58] <smspillaz> bschaefer: you only want to use secure_getenv for setuid programs, so that you can't, eg, inject code into a setuid process through its environment
[16:58] <smspillaz> bschaefer: well, getenv returns char *, but I suppose that's a good point
[16:59] <bschaefer> smspillaz, right, yeah it just sounded nicer "secure!"
[16:59] <TheMuso> c/
[16:59] <sil2100> ;)
[16:59] <bschaefer> smspillaz, also on your if statements, could we throw in {}
[17:00] <bschaefer> 396	+
[17:00] <bschaefer> as it gets hard to read when the if statement is 2 lines already
[17:00] <bschaefer> (the asprintf ones)
[17:00]  * bschaefer just start taking notes to put on the MP
[17:01] <smspillaz> bschaefer: the without-braces is compiz style if the action falls on the next line
[17:01] <smspillaz> and its only one statement
[17:01] <bschaefer> yeah true, I try to use braces when ever my if statement is longer then 1 line
[17:01] <bschaefer> I still don't know the compiz style 100% :)
[17:03] <smspillaz> heh
[17:04] <smspillaz> launchpad diffs on .patch files are impossible to read
[17:09] <smspillaz> going to bed gnight
=== smspillaz is now known as smspilla|z
[17:13] <sil2100> Wgiii!
[17:13] <sil2100> Whooo!
[17:14] <sil2100> It works!
[17:20] <mterry> sil2100, \o/
[17:21] <bschaefer> sil2100, to make you happier 100% tests passed, 0 tests failed out of 1325
[17:21] <bschaefer> :)
[17:22] <bschaefer> im like 70% done with the review...
[17:23] <sil2100> \o\
[17:23] <sil2100> /o/
[17:32] <bschaefer> smspilla|z, https://code.launchpad.net/~compiz-team/compiz/compiz.fix_1130679/+merge/149574/comments/325644
[17:32] <bschaefer> noo hes gone
[17:32] <bschaefer> sil2100, sooo hmm most of the need fixing is more or less needing information
[17:33] <bschaefer> sil2100, should we wait until later for him to look at the comment?
=== om26er_ is now known as om26er
[17:38] <sil2100> bschaefer: hm hm, good question - the sooner we have it fixed the better
[17:39] <sil2100> bschaefer: it's in compiz-team, so we can probably fix anything that needs fixing
[17:39] <bschaefer> sil2100, very true, and there is nothing that is a red flag to me
[17:39] <bschaefer> (maybe a yellow one)
[17:42] <sil2100> bschaefer: I would probably initialize and NULL-check the two char * variables anyway
[17:42] <sil2100> As for the rest, hmm
[17:45] <sil2100> didrocks: ping
[17:45] <didrocks> sil2100: pong pong!
[17:46] <sil2100> didrocks: a quick question regarding bamf on precise - do you know if bamf landed in *precise-proposed* as well? Version 0.2.126-0ubuntu1
[17:46] <sil2100> (the one Timo was working on)
[17:46] <didrocks> sil2100: I think so, let me look at that
[17:46] <sil2100> didrocks: or was it removed from the queue before entering -proposed?
[17:47] <sil2100> didrocks: if yes, could you quickly push the -proposed version somewhere so that I can rebase Timo's branch on it ;) ? Since I'm being poked about the fix already
[17:47] <didrocks> sil2100: phrumpf, it's been uploaded (I have the .upload file), but no trace in -proposed not in unapproved
[17:48] <sil2100> uuuh
[17:48] <sil2100> hmmm
[17:48] <sil2100> ;)
[17:48] <sil2100> What should we do in this case?
[17:49] <didrocks> sil2100: do you mind contacting any SRU team member and keep me updated?
[17:49] <didrocks> sil2100: I can reupload if needed
[17:49] <didrocks> sil2100: but I don't see any reject email :/
[17:49] <sil2100> didrocks: ok! Well, we asked for it to get removed, just been wondering if it made to -proposed
[17:50] <didrocks> ah ok :)
[17:50] <sil2100> didrocks: since we wanted to release it with a cherry-pick
[17:50] <didrocks> sil2100: no, it didn't
[17:50] <sil2100> didrocks: \o/
[17:50] <sil2100> didrocks: thanks!
[17:50] <didrocks> sil2100: yw
[18:02] <bschaefer> sil2100, soo how about we pull the branch fix the uninted chars and push a  branch that depends on sams?
[18:05] <bschaefer> sil2100, actually, looking at sams branch, its ~compiz-team so we can push directly to it
[18:06] <bschaefer> sil2100, im just going to fix the uninted char* and get it approved and merged
[18:06] <sil2100> bschaefer: yes, I mentioned that earlier ^
[18:06] <bschaefer> sil2100, I didn't see that!
[18:07] <sil2100> bschaefer: that's why I proposed fixing that, since we have push permissions ;)
[18:07] <bschaefer> daang now Im reading that
[18:07] <bschaefer> haha
[18:07] <bschaefer> opps
[18:07] <sil2100> bschaefer: fix as many minor things as you feel need fixing and let's maybe approve it
[18:07] <sil2100> Since Sam will be up a bit later,  while we need to have a release this week! ;)
[18:08] <bschaefer> yup, Ill be happy to approve it with the possibility of freeing an united char* gone
[18:12] <sil2100> :)
=== jhodapp is now known as jhodapp|lunch
[18:41] <bschaefer> sil2100, i've approved of the branch
[18:41] <sil2100> bschaefer: excellent, thanks! Only those uninit fixes you made or something else?
=== jhodapp|lunch is now known as jhodapp
[18:41] <bschaefer> sil2100, yeah, I only changed the uninted problems, the other ones were super minor
[18:42] <sil2100> \o/
[18:42] <sil2100> bschaefer: big thanks!
[18:42] <bschaefer> (like casting just to reduce warnings of compiler options ever change)
[18:42] <bschaefer> np!
[18:42]  * sil2100 hopes for an unblocked Unity tomorrow
[18:42] <bschaefer> errg
[18:42] <bschaefer> yeah
[18:42] <sil2100> I mean, compiz
[18:42] <sil2100> ;)
[18:42] <sil2100> See you later then!
[18:42] <bschaefer> me too!
[18:42] <bschaefer> c ya!
=== salem_ is now known as _salem