| === _thumper_ is now known as thumper | ||
| === _thumper_ is now known as thumper | ||
| === thumper is now known as thumper-afk | ||
| smspilla|z | bschaefer: thanks for making those changes | 01:50 |
|---|---|---|
| smspilla|z | I figured something like that had happened | 01:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| smspilla|z | feels like that sometimes | 01:54 |
| smspilla|z | bregma: I wonder what it would have been like if we used CDash | 01:54 |
| bregma | is that another alternative to jenkins? | 01:55 |
| smspilla|z | bregma: yeah, its built by Kitware and designed specifically for CMake/CTest | 01:55 |
| 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 | 01:57 |
| === thumper-afk is now known as thumper | ||
| === smspilla|z is now known as smspillaz | ||
| === rsalveti is now known as rsalveti|afk | ||
| smspillaz | mmrazik: hey, thanks for the advice, found the problem | 07:07 |
| 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 | 07:08 |
| === zniavre__ is now known as zniavre | ||
| jibel | mterry, didrocks good morning | 09:12 |
| jibel | FYI, I wiped LP cache again and restarted the jobs that failed because of it, including unity | 09:13 |
| mterry | jibel, hello! | 09:21 |
| mterry | thanks | 09:21 |
| 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:33 |
| didrocks | thanks! | 09:34 |
| 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:36 |
| 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:37 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| === dandrader is now known as dandrader|afk | ||
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| didrocks | cyphermox: jibel: FYI, it's pull-lp-source and bzr lp-propose which are the 2 "external" LP consumers we are using | 09:57 |
| cyphermox | didrocks: I see you're passing a cache | 10:01 |
| cyphermox | but for a damn good reason :) | 10:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| === dandrader|afk is now known as dandrader | ||
| cyphermox | ah, guess so | 10:07 |
| cyphermox | jibel: were you fixing the cupstream2distro deploy stuff / making changes where I need to wait before deploying? | 10:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| cyphermox | ./cu2d-update-stack -U indicators | 10:12 |
| 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:17 |
| 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 | 10:19 |
| andyrock | sil2100, https://code.launchpad.net/~andyrock/unity/lp-1131679/+merge/150014 | 11:00 |
| andyrock | can you take a look? | 11:01 |
| sil2100 | andyrock: looking | 11:01 |
| 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:04 |
| 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:05 |
| andyrock | thx for the review | 11:06 |
| andyrock | MCR_, you too | 11:06 |
| MCR_ | andyrock, I would do more reviews - but I can just do those I understand ;) | 11:07 |
| MCR_ | but my understanding is getting better day-by-day | 11:08 |
| MCR_ | andyrock, have you seen: https://code.launchpad.net/~mc-return/unity/unity.merge-fix1131152-cppcheck-issues/+merge/149801 ? | 11:10 |
| MCR_ | andyrock, thx ;) | 11:12 |
| andyrock | ;) | 11:13 |
| mterry | andyrock, yay for fixing tests! | 11:13 |
| 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:17 |
| andyrock | untested? | 11:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| MCR_ | this is a upstream Compiz change | 11:23 |
| MCR_ | no ? | 11:23 |
| 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:26 |
| MCR_ | thx anyway ;) | 11:27 |
| andyrock | np | 11:27 |
| jibel | cyphermox, compiz crash again during indicators tests | 11:44 |
| jibel | on intel and ati | 11:44 |
| === mmrazik is now known as mmrazik|lunch | ||
| tvw | Hi, can someone respond to this? I want to know how the notification works in unity, when someone responds to me. | 11:54 |
| cyphermox | jibel: ack, I'm just about ready to go retrace that | 12:16 |
| === dandrader is now known as dandrader|lunch | ||
| cyphermox | or at least, grab the info I need to do it | 12:16 |
| === mmrazik|lunch is now known as mmrazik | ||
| 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? | 12:52 |
| === motorslav is now known as me4oslav | ||
| === dandrader|lunch is now known as dandrader | ||
| === rsalveti|afk is now known as rsalveti | ||
| === _salem is now known as salem_ | ||
| === rsalveti_ is now known as rsalveti | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| === chrisccoulson is now known as rmadison | ||
| === rmadison is now known as chrisccoulson | ||
| === francisco is now known as Guest16789 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!