Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

https://github.com/sugarlabs/sugar-web/pull/102 2013/12/12 Daniel Narvaez > Right, as expected > > > 1386897905.351919 DEBUG root: IndexStore.flush: force=True _pending_writes=0 > 1386897905.352442 DEBUG root: Start database flush > 1386897909.310487 DEBUG root: Completed database flush > 13868

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

On Tue, Dec 17, 2013 at 2:37 PM, Daniel Narvaez wrote: > Yeah, perhaps we need to start distinguishing unit tests from integration > tests, with the second not being run by default > +1 (the test which runs/stops every activity is another example of integration > test). > When developing on suga

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

On 17 December 2013 20:31, Code Raguet wrote: > > On Tue, Dec 17, 2013 at 2:37 PM, Daniel Narvaez wrote: > >> Yeah, perhaps we need to start distinguishing unit tests from integration >> tests, with the second not being run by default >> > +1 > > (the test which runs/stops every activity is anot

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

On 13 December 2013 20:56, Code Raguet wrote: > Only on the first save(). >> Using getEnv().defaultTimeoutInterval = something we could increase the >> timeout for all the datastore tests or even for all the tests. I'm worried >> it would get a bit annoying for development to always have a big ti

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

On Fri, Dec 13, 2013 at 5:24 PM, Rogelio Mita < rogeliom...@activitycentral.com> wrote: > Then we can do: > - separate this functional tests on another file and run it on full-master > maybe for first approach? > better in quick-master, IMHO. Doubling the timeouts it's annoying for humans but robo

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

2013/12/13 Code Raguet > Only on the first save(). >> Using getEnv().defaultTimeoutInterval = something we could increase the >> timeout for all the datastore tests or even for all the tests. I'm worried >> it would get a bit annoying for development to always have a big timeout... > > > Perhaps

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

> > Only on the first save(). > Using getEnv().defaultTimeoutInterval = something we could increase the > timeout for all the datastore tests or even for all the tests. I'm worried > it would get a bit annoying for development to always have a big timeout... Perhaps we should do as in env.js... A

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

2013/12/12 Daniel Narvaez > Only on the first save(). > > Using *getEnv*().*defaultTimeoutInterval* = something we could increase the > timeout for all the datastore tests or even for all the tests. I'm worried it > would get a bit annoying for development to always have a big timeout... An >

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

Right, as expected 1386897905.351919 DEBUG root: IndexStore.flush: force=True _pending_writes=0 1386897905.352442 DEBUG root: Start database flush 1386897909.310487 DEBUG root: Completed database flush 1386897909.334923 DEBUG root: FileStore: Nothing to do Only on the first save(). Using *getE

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

So I added a couple of logs around database.update(), which is the only place it seems it could block for a while. A good log looks like 1386896014.997774 DEBUG root: IndexStore.flush: force=True _pending_writes=0 1386896014.997934 DEBUG root: Start database flush 1386896015.016607 DEBUG root: Com

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

Very similar delay in your logs 1386875635.966910 DEBUG root: IndexStore.flush: force=True _pending_writes=0 1386875641.161983 DEBUG root: FileStore: Nothing to do There is a 5 seconds timeout in datastore too # Force a flush after _n_ seconds since the last change to the db _FLUSH_TIMEOUT = 5

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

apisocket.py is probably responding but after 5 seconds... 1386868991.591994 DEBUG root: datastore.get_properties dbus.String(u'd02d98ab-7bab-4cf5-92c8-24409a6c35d7') 1386868991.613979 DEBUG root: datastore.update dbus.String(u'd02d98ab-7bab-4cf5-92c8-24409a6c35d7') 1386868991.615363 DEBUG root: I

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

When failing 1386868991.611618 DEBUG gwebsockets: Received text message {"method":"datastore.set_metadata","id":3,"params":["d02d98ab-7bab-4cf5-92c8-24409a6c35d7",{"title":"hello"}],"jsonrpc":"2.0"} 1386868994.676076 DEBUG gwebsockets: Got data, length 278 1386868995.920466 DEBUG gwebsockets: Got

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

On 12 December 2013 20:11, Code Raguet wrote: > what about this? >> >> Traceback (most recent call last): >> File >> "/home/broot/sugar-build/build/out/install/lib/python2.7/site-packages/jarabe/frame/devicestray.py", >> line 35, in __init__ >> mod.setup(self) >> File >> "/home/broot/sug

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

On 12 December 2013 16:28, Rogelio Mita wrote: > good point Gonzalo, finishing with env.js we will move to review datastore > at any time. > > > Daniel, I think we can increase the timeout until we can find a solution? > while we work on a solution we can go see if timeout issue related to some >

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

2013/12/12 Gonzalo Odiard > Just remember than this is different to env.js, > we have already a lot of users of this api, then we need look how to solve > these issues > I catch your point here, the idea is not change the API usage, because motive you said above, or if it changes anyway, we shou

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

BTW: gwebsockets's log shows no error On Thu, Dec 12, 2013 at 4:11 PM, Code Raguet wrote: > Today it failed again, but in two tests: > - "datastore object should be able to set and get metadata" > - "datastore object should be able to save and load text" > > both from datastore and due to timeou

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

Today it failed again, but in two tests: - "datastore object should be able to set and get metadata" - "datastore object should be able to save and load text" both from datastore and due to timeout log excerpt: > [1AChrome 25.0 (Linux) datastore object should be able to set and get > metadat

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

2013/12/12 Daniel Narvaez > Interesting that he has different tests failing, on buildbot it seems to > be always the same. Maybe he can try to osbuild pull, try to reproduce > again, and post build/logs/check-modules.log? Seeing a slightly different > failure might help us understanding. > > The

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

2013/12/11 Daniel Narvaez > That's not enough to say if python is never sending the message or if > javascript is never receiving/handling it. So I make gwebsockets log sent > messages to... when we get the next failure we can check if that helps > figuring out what is going on. Sorry, I see th

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

2013/12/12 Gonzalo Odiard > "breaking carefully" :) don't worry! the idea is not to change anything without testing, datastore has enough tests, first of all we would begin to look at these =) -- Roger Activity Central __

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

On Thu, Dec 12, 2013 at 12:28 PM, Rogelio Mita < rogeliom...@activitycentral.com> wrote: > > 2013/12/12 Gonzalo Odiard > >> Datastore api have a few places with comments about function/methods than >> should be async, but are sync. >> >> Ex: >> https://github.com/sugarlabs/sugar-toolkit-gtk3/blob

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

2013/12/12 Gonzalo Odiard > Datastore api have a few places with comments about function/methods than > should be async, but are sync. > > Ex: > https://github.com/sugarlabs/sugar-toolkit-gtk3/blob/master/src/sugar3/datastore/datastore.py#L369 > > No idea about if is related, just a comment. > g

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

Datastore api have a few places with comments about function/methods than should be async, but are sync. Ex: https://github.com/sugarlabs/sugar-toolkit-gtk3/blob/master/src/sugar3/datastore/datastore.py#L369 No idea about if is related, just a comment. Gonzalo On Thu, Dec 12, 2013 at 6:33 AM,

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

Interesting that he has different tests failing, on buildbot it seems to be always the same. Maybe he can try to osbuild pull, try to reproduce again, and post build/logs/check-modules.log? Seeing a slightly different failure might help us understanding. The timeout is 5 seconds so it's probably l

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

Roger has told me recently (today) that this also happen in his local env... Some datastore related test randomly fails. Is not always the same test, but it is one of datastore's and them always fail due to timeouts. Perhaps it's just matter of performance and we can workaround it with higher time

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

As an update, we are now back to the intermittent datastore tests failure which we have been getting for a while. http://buildbot.sugarlabs.org/builders/full-master/builds/17/steps/shell_3/logs/modules [1AChrome 25.0 (Linux): Executed 16 of 34 Chrome 25.0 (Linux) datastore should be a

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

On Tue, Dec 10, 2013 at 6:50 PM, Daniel Narvaez wrote: > After I cleaned disk, it always succeeded so far. > Nice! Green again :D > Let's see when/how it fails again, I guess. But let me know if you want > access to the slaves. > + 1 Thank, Daniel! And, of course, next time I can take a look

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

After I rebooted, it failed two times on the x86_64 slave and it succeeded two times on i386. Probably worth to keep a look on the difference between the two slaves because x86_64 seems to have failed a lot more than i386. After I cleaned disk, it always succeeded so far. Let's see when/how it fa

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

On 10 December 2013 20:47, Code Raguet wrote: > Hello, list! > quick-master is failing in almost every build since last Sunday (Dec 8). > I'd like to fix this and get back to green. > > I'm not able to replay this failure locally, has anyone a failing local > env? > Not me :/ > full-master has

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

Hello, list! quick-master is failing in almost every build since last Sunday (Dec 8). I'd like to fix this and get back to green. I'm not able to replay this failure locally, has anyone a failing local env? full-master has been running successfully (3 times) since quick-master is broken, so, I wo

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

Thanks! On 6 December 2013 18:15, Code Raguet wrote: > Daniel, I've sent a tiny patch for osbuild. > Can you review it, please? > > > On Wed, Dec 4, 2013 at 11:53 AM, Code Raguet > wrote: > >> Thanks, I'll sniff around that and I'll try to send a patch. >> >> >> On Wed, Dec 4, 2013 at 9:53 AM,

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

Daniel, I've sent a tiny patch for osbuild. Can you review it, please? On Wed, Dec 4, 2013 at 11:53 AM, Code Raguet wrote: > Thanks, I'll sniff around that and I'll try to send a patch. > > > On Wed, Dec 4, 2013 at 9:53 AM, Daniel Narvaez wrote: > >> Unfortunately I don't think there is a way at

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

Thanks, I'll sniff around that and I'll try to send a patch. On Wed, Dec 4, 2013 at 9:53 AM, Daniel Narvaez wrote: > Unfortunately I don't think there is a way at the moment. But you are > making a very good point here, should be trivial to print out the commit in > osbuild pull, so that it's a

[Sugar-devel] Frequent buildbot check failures in sugar-web

Unfortunately I don't think there is a way at the moment. But you are making a very good point here, should be trivial to print out the commit in osbuild pull, so that it's available in the log... I'll see if I can get at it or patches welcome of course... Should probably go in _pull_module https:

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

yesterday, before Gonzalo has fixed buildbot, I wanted to help with this and I was willing to run a "git bisect". Some submodule HEADs were broken and I needed a revision (commit SHA) of those where a build had been succesful. Looking at quick-master builder I found that build #23 was the last succ

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

Did you see the without-configuration issue in buildbot or locally? If locally could you please post logs if you are able to repro? (Thanks for pointing out the other failure, will post another email) On Monday, 2 December 2013, Rogelio Mita wrote: > Sometimes when check command is running, it c

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

Sometimes when check command is running, it calls karma without configuration file then fails, any idea why?. Anyway, right now full-master fails before run "sugar-web checker" by two test on sugar-toolkit-gtk3: test_dist_source_out_of_source and test_dist_xo_out_of_source 2013/11/28 Rogelio Mit

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

I will take note of this 2013/11/28 Daniel Narvaez > > http://buildbot.sugarlabs.org/builders/quick-sucrose-0.100/builds/6/steps/shell_2/logs/modules > > We are getting a lot of these, like 50% of the times. Unfortunately my > laptop broke so I won't be able to debug them until it comes back re

[Sugar-devel] Frequent buildbot check failures in sugar-web

http://buildbot.sugarlabs.org/builders/quick-sucrose-0.100/builds/6/steps/shell_2/logs/modules We are getting a lot of these, like 50% of the times. Unfortunately my laptop broke so I won't be able to debug them until it comes back repaired. Help sorting this out would be appreciated, especially i