Hi
Thanks.
I found a well hidden {1} timeout setting in the preferences / devices
and increased this from the default 2 secs to 10 secs. This does seem
to help, but as always with sporadic problems only time will tell if
this is a fix, or if the problem is just dormant for a while.
What I don't understand is, given the error says "Could not connect to
MerSDK Virtual Machine" why should a timeout for connecting to a
Jolla device play any role?
Is the error misleading? is the problem actually in connecting FROM
the MerSDK to the Jolla?
Chris
{1} when the preferences pane opens, at least on my OSX host the
timeout setting is "offscreen" in an embedded pane with scroll bars in
the middle of the preferences pane. Only if you scroll down in the
embedded pane are further settings including the timeout revealed.
Truly a wonderful bit of UI design 8-)
Zitat von fasza2mob...@gmail.com:
I believe the timeout setting can be adjusted in QtCreator where
you set up your mer device(ssh password, etc). By increasing this
value you can probably prevent the timeout issue altogether. I don't
have the SDK in front of me to give you the exact menu you need to
open, but it isn't too hard to find once you know what you're
looking for.
On Sat Apr 26 2014 13:41:20 GMT+0100 (BST),
christopher.l...@thurweb.ch wrote:
Hi All
I am suffering from sporadic bouts of the error: "Could not connect to
MerSDK Virtual Machine. Timeout waiting for reply from server"
One moment I can be happily hacking and deploying code to my Jolla
without error. Then I make a small change to the code, try to deploy,
and bing! the error rears its ugly head once again like a scandinavian
troll from under a bridge.
Project ERROR: Could not connect to MerSDK Virtual Machine. Timeout
waiting for reply from server.
14:02:28: The process
"/Users/christopherlamb/.config/SailfishAlpha4/mer-sdk-tools/MerSDK/SailfishOS-armv7hl/deploy" exited with
code
1.
Error while building/deploying project landed26_QT5 (kit:
MerSDK-SailfishOS-armv7hl)
When executing step 'Rpm'
14:02:28: Elapsed time: 00:27.
When the error occurs, there seem to be at least 2 variants:
1) It will successfully deploy "As binaries" without error, but will
give the error on "deploy as RPM".
2) Any kind of deploy gives the error.
The strange thing is, that despite the error, it does seem to
(sometimes) deploy (or possibly partially deploy) code.
Right now I am getting the error in constellation 1), so according to
the error a "deploy as RPM" should fail. Yet the test below indicates
that it is at least partially deploying code.
[root@Jolla javascript]# pwd
/usr/share/landed26_QT5/qml/javascript
[root@Jolla javascript]#
[root@Jolla javascript]# ls -ahl
total 52K
drwxr-xr-x 1 root root 180 2014-04-26 13:56 .
drwxr-xr-x 1 root root 110 2014-04-26 13:56 ..
-rw-r--r-- 1 root root 4.2K 2014-04-26 13:55 jsonpath.js
-rw-r--r-- 1 root root 1.3K 2014-04-26 13:55 jsonSupport.js
-rw-r--r-- 1 root root 349 2014-04-26 13:55 landed.js
-rw-r--r-- 1 root root 1.2K 2014-04-26 13:55 message.js
-rw-r--r-- 1 root root 8.4K 2014-04-26 13:55 readDataModel.js
-rwxr-xr-x 1 root root 8.8K 2014-02-03 08:32 settingsDB.js
-rw-r--r-- 1 root root 5.2K 2014-04-26 13:55 writeDataModel.js
//create new file testDeploy.js in QtCreator, then attempt deploy as
RPM. Error is generated. Repeat attempt to deploy as RPM. Error is
generated again.
//but testDeploy.js is now on the Jolla!
[root@Jolla javascript]# ls -ahl
total 56K
drwxr-xr-x 1 root root 206 2014-04-26 14:01 .
drwxr-xr-x 1 root root 110 2014-04-26 14:01 ..
-rw-r--r-- 1 root root 4.2K 2014-04-26 14:00 jsonpath.js
-rw-r--r-- 1 root root 1.3K 2014-04-26 14:00 jsonSupport.js
-rw-r--r-- 1 root root 349 2014-04-26 14:00 landed.js
-rw-r--r-- 1 root root 1.2K 2014-04-26 14:00 message.js
-rw-r--r-- 1 root root 8.4K 2014-04-26 14:00 readDataModel.js
-rwxr-xr-x 1 root root 8.8K 2014-02-03 08:32 settingsDB.js
-rw-r--r-- 1 root root 38 2014-04-26 14:00 testDeploy.js
-rw-r--r-- 1 root root 5.2K 2014-04-26 14:00 writeDataModel.js
So it looks like that after a second failed deploy, the file is
actually deployed!
During bouts of the error, QtCreator seems to get out of sync the true
status of the SDK VM (indicated by the VirtualBox GUI). So QtCreator
may show the green "Start SDK" status, even though the SDK is already
running. Or QtCreator shows the same button grey.
So far I have not found any lasting solution to prevent the error in
the first place. Sometimes it goes away on its own accord, and
sometimes various combinations of restarting VirtualBox, the VM,
QtCreator or my development host help for a while (but rarely for long).
What exactly is the timeout? Is this a property that I can increase?
The "known issues" page of the Alpha (Qt4.8) SDK suggests:
https://sailfishos.org/wiki/SDK_Alpha_Known_Issues
VBoxManage modifyvm MerSDK --natdnshostresolver1 on
But that has not helped.
I am running the very latest version of the SailfishOS SDK, but had
the same error with previous versions.
Any ideas?
Chris
_______________________________________________
SailfishOS.org Devel mailing list
_______________________________________________
SailfishOS.org Devel mailing list
_______________________________________________
SailfishOS.org Devel mailing list
