[01:50] <smspilla|z> bschaefer: thanks for making those changes
[01:50] <smspilla|z> I figured something like that had happened
[01:51] <bschaefer> smspilla|z, np! Hopefully it merges soon...
[01:51] <bschaefer> smspilla|z, thanks for pushing it to ~compiz-team :)
[01:51] <smspilla|z> thats why I do that :)
[01:52] <smspilla|z> so that if I submit something, have to be away for a few hours and its minor, someone else can just fix it instead of blocking forevere
[01:52] <smspilla|z> huh
[01:52] <smspilla|z> what does "UNSTABLE" in the context of jenkins mean?
[01:53] <bregma> sounds like it describes Jenkins to me
[01:53] <bschaefer> haha...
[01:53] <smspilla|z> heh
[01:53] <bregma> I believe it means there have been failures lately
[01:53] <smspilla|z> so why is it marking a 100% passing branch as "needs fixing"
[01:53] <bschaefer> i use to suggest offering a sacrifice for jenkins each MP, but that was turned down
[01:54] <smspilla|z> feels like that sometimes
[01:54] <smspilla|z> bregma: I wonder what it would have been like if we used CDash
[01:55] <bregma> is that another alternative to jenkins?
[01:55] <smspilla|z> bregma: yeah, its built by Kitware and designed specifically for CMake/CTest
[01:57] <smspilla|z> bregma: they don't do a very good job of marketing it
[01:57] <smspilla|z> the impression I get from their website is that it either doesn't do anything, or they just don't want to say what it does
[07:07] <smspillaz> mmrazik: hey, thanks for the advice, found the problem
[07:08] <smspillaz> mmrazik: my wrapper script was returning "0" for failed tests, so the junit xml would mark it as failed, but ctest would mark it as passed
[07:08] <mmrazik> smspillaz: cool
[07:08] <mmrazik> (that we found the issue)
[07:08] <smspillaz> I hadn't seen the "unstable" result before, so I was wondering what was up with that
[09:12] <jibel> mterry, didrocks good morning
[09:13] <jibel> FYI, I wiped LP cache again and restarted the jobs that failed because of it, including unity
[09:21] <mterry> jibel, hello!
[09:21] <mterry> thanks
[09:33] <didrocks> hey jibel
[09:33] <didrocks> ejibel: cyphermox saw that we have some .skip file which were around
[09:33] <didrocks> jibel: ^
[09:33] <didrocks> for the indicator stack
[09:33] <didrocks> so all tests were skipped
[09:33] <didrocks> I think we have a bug in this case then ;)
[09:33] <jibel> right, that's what I was looking t
[09:33] <jibel> at
[09:34] <didrocks> thanks!
[09:36] <jibel> didrocks, in check the first step created a skip file with the condition
[09:36] <jibel> if [ -z "$(ls $WRKDIR/*.project 2>/dev/null)" -a "$CHECK_WITH_WHOLE_PPA" != "true" ]; then
[09:36] <jibel> then autopilot fails
[09:36] <jibel> and the skip file is not removed
[09:36] <didrocks> jibel: but I added the rm on top, isn't it?
[09:36] <didrocks> I did that the other day
[09:36] <didrocks> (being last week)
[09:36] <jibel> didrocks, make sense ?
[09:37] <jibel> didrocks, I don't see any rm http://paste.ubuntu.com/1705556/
[09:37] <didrocks> yeah, interesting
[09:37] <didrocks> let me look at my bzr log
[09:37] <didrocks> jibel: rev 206
[09:39] <jibel> didrocks, I confirm it's in rev 206 but did you update the jobs afterwards?
[09:39] <didrocks> jibel: I did
[09:39] <didrocks> then cyphermox did the other day to add the HUD
[09:39] <jibel> or did someone updated them with the wrong revision
[09:39] <didrocks> cyphermox: did you deploy after bzr pull?
[09:40] <cyphermox> please define deploy and bzr pull?
[09:40] <cyphermox> or rather, deploy
[09:40] <cyphermox> I did update-stack
[09:40] <didrocks> cyphermox: right, that's what is deploying
[09:40] <didrocks> cyphermox: did you get trunk before doing that?
[09:40] <cyphermox> yeah, use the right words otherwise I can't follow
[09:40] <cyphermox> yeah, should of
[09:40] <cyphermox> I usually rm the branch before
[09:40] <didrocks> cyphermox: weirdly, rev 206 seems to not being around
[09:40] <cyphermox> ok
[09:40] <didrocks> like it's in the template
[09:41] <didrocks> but not in the -check for indicator
[09:41] <cyphermox> what should 206 contain?
[09:41] <didrocks> so I wonder if we missed something
[09:41] <didrocks> cyphermox: can't you bzr diff -c 206?
[09:41] <jibel> didrocks, I think we should add a safeguard, like inserting the revno in the job description and only update the job if the revno is higher
[09:41] <didrocks> jibel: yeah, I think it's the way to go
[09:41] <cyphermox> yeah
[09:42] <cyphermox> I see
[09:42] <didrocks> cyphermox: so I don't care if you didn't bzr pull, just trying to understand if we didn't miss something or it's just you used an old branch
[09:42] <cyphermox> I don't think I did, I do have everything here right now
[09:42] <cyphermox> I wouldn't if I had used an old branch
[09:43] <didrocks> jibel: do you see any other explanation?
[09:43] <didrocks> about this missing?
[09:43] <didrocks> cyphermox: you did use -U, right? IIRC
[09:44] <jibel> didrocks, no, unless someone did a manual update
[09:44] <cyphermox> yeah I did
[09:44] <cyphermox> so I see, it's my fault
[09:44] <didrocks> cyphermox: ? you didn't use -U, you mean?
[09:44] <cyphermox> I deployed, and *then* updated the branch after noticing there was a discrepancy
[09:44] <didrocks> ah ok :)
[09:44] <cyphermox> I should have re-deployed
[09:44] <didrocks> phew, at least, we know
[09:45] <cyphermox> tanks you extensive zsh history
[09:45] <didrocks> so at least the issue we see today was fixed last week
[09:45] <didrocks> cyphermox: heh
[09:45] <cyphermox> good
[09:45] <didrocks> jibel: yeah, checking the bzr revno would be nice
[09:45] <didrocks> so that this doesn't happen anymore
[09:45] <cyphermox> yeah
[09:45] <didrocks> cyphermox: thanks :) just trying to ensure we don't have any other weird case ;)
[09:45] <cyphermox> but in this case wouldn't it look like it's pushing the same revno again?
[09:46] <didrocks> hum
[09:46] <cyphermox> how does the deploy work?
[09:46] <jibel> didrocks, anyway we need a better way to track updates, I'll think about it.
[09:46] <cyphermox> could it be trying to merge cupstream2distro remotely with a branch on 10.97.0.1 just for that purpose?
[09:46] <didrocks> jibel: yeah, will be needed. We really need history
[09:46] <cyphermox> e.g. and then explode as soon as there is a discrepancy
[09:46] <didrocks> cyphermox: hum, like we push that somewhere
[09:47] <didrocks> and deploy is automagic?
[09:47] <cyphermox> no
[09:47] <cyphermox> well, that could be another way
[09:47] <cyphermox> like, push somehwere and then call something that just runs a simple jenkins job for deploying
[09:47] <cyphermox> but the remote branch over ssh is simpler I think
[09:47] <didrocks> cyphermox: yeah, that's a good idea
[09:48] <didrocks> both, don't have any strong idea :)
[09:48] <cyphermox> if we push to the same place as jenkins pulls then it's more likely that the branch is always the same and always up to date
[09:48] <cyphermox> that's also why I went ahead and bound my local copy, too :)
[09:49] <didrocks> heh
[09:49] <cyphermox> will avoid any case of it not being up to date
[09:49] <didrocks> right
[09:49] <cyphermox> didrocks: that's the checkout instead of branch we discussed the other day
[09:49] <didrocks> cyphermox: yeah yeah, I remember about that
[09:50] <cyphermox> then we can also start to do merge requests for the stack updates as well :)
[09:50] <jibel> didrocks, I'll start with etckeeper on server's side, at least we'll have an history and can revert
[09:50] <didrocks> jibel: yeah, double safety bet :)
[09:51] <cyphermox> starting to sound like a rocket ship safety belt ;)
[09:51] <didrocks> heh ;)
[09:51] <didrocks> cyphermox: jibel: once the right version is redeployed, do you mind relaunching the full indicator stack?
[09:51] <didrocks> with rebuild, and so on
[09:51] <cyphermox> k
[09:51] <didrocks> thx
[09:52] <jibel> didrocks, that and maintenance time is close to zero :)
[09:52] <cyphermox> that's going to give me my compiz crash to retrace too
[09:52] <didrocks> jibel: heh, indeed ;)
[09:52] <didrocks> cyphermox: exactly!
[09:52] <jibel> didrocks, another topic, LP cache corruption
[09:52] <didrocks> (well, of course, it won't crash this time… :p)
[09:52] <cyphermox> right
[09:52] <cyphermox> murphy...
[09:52] <didrocks> jibel: yeah, I need to have those in my process I think
[09:53] <jibel> which will happen more and more often with the increasing number of pacakges
[09:53] <didrocks> jibel: yeah, weird that we went from 0% to a lot more in few days, when we only added 2 packages
[09:53] <didrocks> jibel: I think I'll remove all the subprocesses for things using LP
[09:53] <jibel> didrocks, I think LP manages concurrent accesses to the cache very badly
[09:54] <didrocks> and directly try to pass my own launchpad object
[09:54] <didrocks> which has a cache per jenkins job
[09:54] <cyphermox> can we do almost everything in LP anonymously?
[09:54] <didrocks> cyphermox: it's anonymous
[09:54] <didrocks> still caching
[09:54] <jibel> didrocks, this is for example the packages that failed this morning in unity http://paste.ubuntu.com/1705637/
[09:54] <cyphermox> err
[09:54] <cyphermox> I thought the issues were with auth credentials cache
[09:54] <jibel> you'll see they're all doing the same thing at the same time
[09:54] <didrocks> cyphermox: no, launchpad cache, not creds
[09:55] <cyphermox> ok
[09:55] <cyphermox> :(
[09:55] <didrocks> jibel: yeah, from what you saw, it's only the system cache, isn't it?
[09:55] <jibel> didrocks, couldn't you add a locking mechanism to avoid them accessing the cache simultaneoulsy
[09:55] <cyphermox> we don't need it to cache
[09:55] <didrocks> jibel: I prefer just using the commands from my process, and have the per jenkins job cache, as we already have for the rest
[09:55] <didrocks> cyphermox: if only it was an option…
[09:56] <cyphermox> hehe
[09:56] <jibel> didrocks, ok that's fine
[09:56] <didrocks> jibel: will work on that start of next week
[09:56] <cyphermox> didrocks: what I'm getting at is it might not be documented but I think there is a way
[09:56] <didrocks> jibel: I hope our libraries accept a random lp object :)
[09:56] <didrocks> cyphermox: are you sure? If I pass None, it's still caching
[09:56] <didrocks> cyphermox: but would be interested if you find anything
[09:57] <didrocks> cyphermox: jibel: FYI, it's pull-lp-source and bzr lp-propose which are the 2 "external" LP consumers we are using
[10:01] <cyphermox> didrocks: I see you're passing a cache
[10:01] <cyphermox> but for a damn good reason :)
[10:02] <didrocks> cyphermox: None is "use the system cache" IIRC ;)
[10:02] <didrocks> which is how I avoid that in cupstream2distro
[10:02] <didrocks> by passing a per jenkins job cache
[10:02] <cyphermox> didrocks: ah, I'm reading launchpadmanager.py; passes something for launchpadlib_dir
[10:03] <cyphermox> and that seems to be used for a cache
[10:03] <didrocks> cyphermox: yep, but that's not the pb :)
[10:03] <cyphermox> but you kind of need that, because launchpad isn't multiproc
[10:03] <cyphermox> well
[10:03] <cyphermox> it's where launchpad will cache its data
[10:03] <didrocks> the pb is when I subprocess.call('pull-lp-source')
[10:03] <cyphermox> ah, yeah I guess so
[10:03] <didrocks> this one is using the system cache
[10:03] <didrocks> and we do that in // for all projects :)
[10:03] <cyphermox> hm
[10:04] <cyphermox> then it probably should be fixed so that you can tell it a different cache
[10:04] <didrocks> so that's what I meant by "we need to do the same than pull-lp-source and see if we can hook our launchpad object (with a cache per jenkins job) to it"
[10:04] <didrocks> would be more elegant than subprocess.call :p
[10:07] <cyphermox> ah, guess so
[10:08] <cyphermox> jibel: were you fixing the cupstream2distro deploy stuff / making changes where I need to wait before deploying?
[10:09] <cyphermox> I mean, who are we waiting for right now, me? :D
[10:09] <jibel> cyphermox, I didn't change anything, it's all yours :)
[10:10] <cyphermox> ok
[10:10] <cyphermox> didrocks: jibel: so I'll re-run the update-stack now, and we'll get everything latest
[10:10] <didrocks> thanks cyphermox
[10:10] <cyphermox> then run the indicator stack
[10:10] <jibel> cyphermox, unity is running, and IIRC jenkins doesn't like when you update configs under it's feet
[10:10] <jibel> its
[10:11] <didrocks> cyphermox: you need to use the ui remember to rebuild everything :)
[10:11] <cyphermox> yeah
[10:11] <cyphermox> use the ui?
[10:11] <cyphermox> wait, please, one thing at the time
[10:11] <cyphermox> too many things going on at once
[10:11] <didrocks> jibel: I think cyphermox will run against the indicator stack
[10:11] <didrocks> not unity
[10:11] <cyphermox> yeah, just indicators, that should be fine
[10:11] <didrocks> so it's fine to redeploy there
[10:11] <jibel> k
[10:12] <cyphermox>  ./cu2d-update-stack -U indicators
[10:17] <didrocks> cyphermox: gogogo :)
[10:17] <cyphermox> oh, that's done
[10:17] <cyphermox> now just checking on unity
[10:17] <cyphermox> it's going to need to wait
[10:19] <didrocks> cyphermox: hum, how so? the -check job will magically wait for the other to finish :)
[10:19] <cyphermox> bah
[10:19] <didrocks> so we can start rebuilding! :-)
[10:19] <cyphermox> you and your automagic ;)
[10:19] <didrocks> ahah
[11:00] <andyrock> sil2100, https://code.launchpad.net/~andyrock/unity/lp-1131679/+merge/150014
[11:01] <andyrock> can you take a look?
[11:01] <sil2100> andyrock: looking
[11:04] <sil2100> andyrock: ah, I see what you did there ;) Ok, looks like a solid way to workaround nicely! Approving in a moment ;)
[11:04] <sil2100> andyrock: we had a similar thing regarding previews btw.
[11:04] <sil2100> Wit the difference those leftover previews were staying in the list till infinity!
[11:05] <andyrock> cool yeah we have a 1 second timeout before removing the icon from the launcher model
[11:05] <andyrock> and 1 second can be an inifinity in autopilot ;)
[11:05] <sil2100> ;)
[11:06] <andyrock> thx for the review
[11:06] <andyrock> MCR_, you too
[11:07] <MCR_> andyrock, I would do more reviews - but I can just do those I understand ;)
[11:08] <MCR_> but my understanding is getting better day-by-day
[11:10] <MCR_> andyrock, have you seen: https://code.launchpad.net/~mc-return/unity/unity.merge-fix1131152-cppcheck-issues/+merge/149801 ?
[11:12] <MCR_> andyrock, thx ;)
[11:13] <andyrock> ;)
[11:13] <mterry> andyrock, yay for fixing tests!
[11:17] <MCR_> andyrock, this just was missing the debian/compiz-plugins-default.install adjustments and needs reapproval: https://code.launchpad.net/~mc-return/compiz/compiz0.9.9.merge-plugin-freewins/+merge/146291
[11:17] <MCR_> (freewins \o/)
[11:18] <andyrock> untested?
[11:19] <andyrock> is distro ok with this?
[11:19] <MCR_> it is in the extra package
[11:19] <MCR_> and has to be manually installed AFAIK
[11:19] <MCR_> and is diabled by default also
[11:20] <MCR_> no more extra package, I just saw
[11:20] <MCR_> but still disabled
[11:20] <MCR_> and ofc manually tested to the extreme
[11:21] <andyrock> mmm but those are not good reasons to not test it ;)
[11:21] <MCR_> sure
[11:21] <andyrock> i can understand that test is diffcult
[11:22] <MCR_> I guess Sam will also want to get it under test
[11:22] <MCR_> but it is ready for merge still ;)
[11:22] <MCR_> it won't interfere with any default installation
[11:22] <andyrock> have you asked distro?
[11:23] <MCR_> this is a upstream Compiz change
[11:23] <MCR_> no ?
[11:26] <MCR_> andyrock, the package is named compiz-plugins now: This package contains the plugins that come with compiz but not officially
[11:26] <MCR_> supported.
[11:26] <andyrock> MCR_, let's wait sam for this ;)
[11:26] <MCR_> sure
[11:27] <MCR_> thx anyway ;)
[11:27] <andyrock> np
[11:44] <jibel> cyphermox, compiz crash again during indicators tests
[11:44] <jibel> on intel and ati
[11:54] <tvw> Hi, can someone respond to this? I want to know how the notification works in unity, when someone responds to me.
[12:16] <cyphermox> jibel: ack, I'm just about ready to go retrace that
[12:16] <cyphermox> or at least, grab the info I need to do it
[12:52] <cyphermox> smspillaz: does 6 Mb sound like a reasonable size for the memory dump of compiz on a crash, assuming it crashes early on as it starts?