Python 3 support

[AndreasH]

While I can not speak of how to do this with "the debian way", I do know that the official way to build the package is to do so using the VirtualBox build process and not the hosts.

Example: running the following

Code: Select all   Expand viewCollapse view

/trunk/src/VBox/Installer/linux/debian/rules binary
                          ^^^^^

To clean if you need to rebuild:

Code: Select all   Expand viewCollapse view

/trunk/src/VBox/Installer/linux/debian/rules clean
                          ^^^^^

That works, as long as you have all dependencies installed. To the list you linked above, I added 'zip' which was needed to build the guest additions, IIRC.

The toplevel debian directory shouldn't be removed, it should be turned into one which directly works again.

If this is not the official way to build it, I don't see the reason why. Why would you need two different ways to build the same package, with the potential of producing two different results or no result at all, as is the case right now? It may be possible to create a working top-level debian directory again, if you adapt the paths. But it will be different from the one under src/VBox/Installer/linux, and every change would have to be carefully kept in sync between the two.

Unneccessary work, if you ask me. I'd put the Instructions from PerryG plus the right apt-get line in a top-level README or INSTALL file, and that's it. It took me most of the time to find this out, because the broken top-level debian fooled me into thinking this was the 'official' way to build the package.

[Perryg]

Maybe I should clarify a few things. When I said official way what I meant is the original way as told by the DEVs a long time ago. IIRC the top level debian folder was added at the request of debian or one of its maintainers ( correct me if I am mistaken ). I do know for sure that running both in the top level and the installer folder produces the exact same results though and the main fault has to do with the qt versioning going on in some distros. I ran into this when I first upgraded to version 5 of qt and the real reason was the host having multiple copies of qt with various version ( IE: qt4 and qt5 ). This confused VBox to a point. It would find the proper qt when running config but fail during compile since it also saw qt4 and seem to stop without going on to find qt5. Since I don't usually build deb runs as I prefer a simple .run to install, I did/have not looked into it in depth to find the real cause. If I can find time later in the week or so I might try to see what needs to be done, but I usually let Frank do this as he is way more familiar with this part of the code then I am.

[klaus]

Trust me, there are good reasons for having two slightly different debian directories. It's too much effort to explain in detail, since for the normal debian based distro cases there should be absolutely no noticeable difference between the two - as we already concluded, anything else is a bug. For quite a few years the 2nd (deep down) debian folder wasn't even publicly visible and only used to create innotek/Sun/Oracle's official .deb packages.

[klaus]

Back to the topic: did you try the 5.1.26 or 5.1.28 packages? They now should come with python3 support, at least I saw that the right shared libraries are now packaged, without ending up with excessive dependencies.

[p0c]

Back to the topic: did you try the 5.1.26 or 5.1.28 packages? They now should come with python3 support, at least I saw that the right shared libraries are now packaged, without ending up with excessive dependencies.

Hi Klaus, thanks for your help on this topic.

I've ran into this issue myself:

Code: Select all   Expand viewCollapse view

p0c@box ~: $ python -c 'import vboxapi; vm = vboxapi.VirtualBoxManager()'
m=VBoxPython3_6m x=No module named 'VBoxPython3_6m'
m=VBoxPython3m x=No module named 'VBoxPython3m'
m=VBoxPython x=No module named 'VBoxPython'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3.6/site-packages/vboxapi/__init__.py", line 970, in __init__
    self.platform = PlatformXPCOM(dPlatformParams)
  File "/usr/lib/python3.6/site-packages/vboxapi/__init__.py", line 730, in __init__
    import xpcom.vboxxpcom
  File "/usr/lib/virtualbox-sdk/xpcom/vboxxpcom.py", line 78, in <module>
    raise Exception('Cannot find VBoxPython module (tried: %s)' % (', '.join(_asVBoxPythons),))
Exception: Cannot find VBoxPython module (tried: VBoxPython3_6m, VBoxPython3m, VBoxPython)


My default python version:

Code: Select all   Expand viewCollapse view

p0c@box ~ $ python -V
Python 3.6.2


I've used the latest package:

Code: Select all   Expand viewCollapse view

p0c@box ~ $ VirtualBox -h
Oracle VM VirtualBox Manager 5.1.28


I assume support for python3 should have been enabled with that release? Your patch is not valid anymore, as it seems that code for dual python2/3 support has been incorporated into the 5.1.28 branch now by default. Can you shed some light on this?

[klaus]

p0c, you didn't mention which Linux distribution you're using and which VirtualBox package you installed. This is vital information, as only the distro-specific .deb/.rpm packages are containing multiple VBoxPython libraries. You must install the right package variant, otherwise you might get the wrong set of libraries.

[p0c]

I'm running Arch linux, 64-bit. The virtualbox package is 5.1.28, the latest available.

[klaus]

Since you're still avoiding to give clear answers regarding the package source I can only give guesswork responses. Arch linux users tend to use a custom VirtualBox package, and if that one doesn't contain python3 support I can't help. The Linux packages from virtualbox.org (except the .run one, being distro independent it can't anticipate which python versions it might encounter, with unpredictable build options) should contain python3 support matching the distro verson's packages.

[renn0xtek9]

I am sorry to up this problem, but I therefore wanted to enquire about the current status.
I am on Kubuntu 18.04
I tried to install the python3-sdk today, and I still have problem.
I install virtualbox as described from their website
And trying to run the sample I get the following thing.
Not sure what is going wrong

Code: Select all   Expand viewCollapse view

 ./vboxshell.py -w
('init exception: ', <ZSI.EvaluateException o7fea1a01a7d0>)
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/vboxapi/__init__.py", line 1015, in __init__
    vbox = self.platform.getVirtualBox()
  File "/usr/lib/python2.7/dist-packages/vboxapi/__init__.py", line 886, in getVirtualBox
    return self.connect(self.url, self.user, self.password)
  File "/usr/lib/python2.7/dist-packages/vboxapi/__init__.py", line 944, in connect
    self.vbox = self.wsmgr.logon(self.user, self.password)
  File "/home/max/Downloads/sdk/bindings/webservice/python/lib/VirtualBox_wrappers.py", line 14806, in logon
    val=self.mgr.getPort().IWebsessionManager_logon(req)
  File "/home/max/Downloads/sdk/bindings/webservice/python/lib/VirtualBox_client.py", line 11541, in IWebsessionManager_logon
    response = self.binding.Receive(IWebsessionManager_logonResultMsg.typecode)
  File "/usr/lib/python2.7/dist-packages/ZSI/client.py", line 536, in Receive
    return _Binding.Receive(self, replytype, **kw)
  File "/usr/lib/python2.7/dist-packages/ZSI/client.py", line 454, in Receive
    msg = FaultFromFaultMessage(self.ps)
  File "/usr/lib/python2.7/dist-packages/ZSI/fault.py", line 253, in FaultFromFaultMessage
    pyobj = ps.Parse(FaultType.typecode)
  File "/usr/lib/python2.7/dist-packages/ZSI/parse.py", line 326, in Parse
    return how.parse(self.body_root, self)
  File "/usr/lib/python2.7/dist-packages/ZSI/TCcompound.py", line 236, in parse
    '" missing from complexType', ps.Backtrace(elt))
EvaluateException: Element "faultstring" missing from complexType
[Element trace: /SOAP-ENV:Envelope/SOAP-ENV:Body/SOAP-ENV:Fault]
Traceback (most recent call last):
  File "./vboxshell.py", line 3614, in <module>
    main(sys.argv)
  File "./vboxshell.py", line 3585, in main
    'vb':           oVBoxMgr.getVirtualBox(),
  File "/usr/lib/python2.7/dist-packages/vboxapi/__init__.py", line 1048, in getVirtualBox
    return self.platform.getVirtualBox()
  File "/usr/lib/python2.7/dist-packages/vboxapi/__init__.py", line 886, in getVirtualBox
    return self.connect(self.url, self.user, self.password)
  File "/usr/lib/python2.7/dist-packages/vboxapi/__init__.py", line 944, in connect
    self.vbox = self.wsmgr.logon(self.user, self.password)
  File "/home/max/Downloads/sdk/bindings/webservice/python/lib/VirtualBox_wrappers.py", line 14806, in logon
    val=self.mgr.getPort().IWebsessionManager_logon(req)
  File "/home/max/Downloads/sdk/bindings/webservice/python/lib/VirtualBox_client.py", line 11541, in IWebsessionManager_logon
    response = self.binding.Receive(IWebsessionManager_logonResultMsg.typecode)
  File "/usr/lib/python2.7/dist-packages/ZSI/client.py", line 536, in Receive
    return _Binding.Receive(self, replytype, **kw)
  File "/usr/lib/python2.7/dist-packages/ZSI/client.py", line 454, in Receive
    msg = FaultFromFaultMessage(self.ps)
  File "/usr/lib/python2.7/dist-packages/ZSI/fault.py", line 253, in FaultFromFaultMessage
    pyobj = ps.Parse(FaultType.typecode)
  File "/usr/lib/python2.7/dist-packages/ZSI/parse.py", line 326, in Parse
    return how.parse(self.body_root, self)
  File "/usr/lib/python2.7/dist-packages/ZSI/TCcompound.py", line 236, in parse
    '" missing from complexType', ps.Backtrace(elt))
ZSI.EvaluateException: Element "faultstring" missing from complexType
[Element trace: /SOAP-ENV:Envelope/SOAP-ENV:Body/SOAP-ENV:Fault]


[klaus]

Python 3 support right now is limited to using the local API. I couldn't find anything in Python3 which gets anywhere near the ZSI stuff (which is for Python2 only) when talking to SOAP webservices. There is no plan on our side to work on this as long as the SOAP support in Python3 stays unusable.

[renn0xtek9]

Thanks for your answer,
This is not very clear to me. I have python 3 installed.
the vboxshell.py script is the one directly delivered in the sdk
I tried to run it as a test but it failed.
Is there something I should change in my installation? Or what do you mean by "local API"

[klaus]

You specified the option "-w", which tells vboxshell.py to use the webservice flavor (which only exists in working shape for Python2). If you leave out this option then you should have instant success on Python3.

[renn0xtek9]

Well I don't know, they manage to make something conceptually very easy, totally abstruse
The vboxshell.py does indeed work.
Now if I want to apply it in my own script and do something like this https://www.min.at/prinz/?x=entry:entry160823-123520
I get

Code: Select all   Expand viewCollapse view

./testvbox.py
Traceback (most recent call last):
  File "./testvbox.py", line 29, in <module>
    main()
  File "./testvbox.py", line 22, in main
    vbox = vboxMgr.vbox
AttributeError: 'VirtualBoxManager' object has no attribute 'vbox'


while doing this (using getVirtualBox)

Code: Select all   Expand viewCollapse view

iomport vboxapi
#from vboxapi import VirtualBoxManager

def main():
   vboxMgr = vboxapi.VirtualBoxManager(None, None)
   vbox = vboxMgr.getVirtualBox()
   # 'example-vm' is the name of the VM we want to change
   vm = vbox.findMachine('NeonTestAndKill')
   machines = vbox.getMachines()
   print(machines)


I get this

Code: Select all   Expand viewCollapse view

./testvbox.py
[<XPCOM component '<unknown>' (implementing IMachine)>, <XPCOM component '<unknown>' (implementing IMachine)>, <XPCOM component '<unknown>' (implementing IMachine)>, <XPCOM component '<unknown>' (implementing IMachine)>, <XPCOM component '<unknown>' (implementing IMachine)>, <XPCOM component '<unknown>' (implementing IMachine)>, <XPCOM component '<unknown>' (implementing IMachine)>, <XPCOM component '<unknown>' (implementing IMachine)>]


For me it should be as easy as :

Code: Select all   Expand viewCollapse view

vboxMg=vboxapi.VirtualBoxManager
vboxMg.StartMachine("$yourmachine")

vboxMg.SendInstruction("$instru","$yourmachine")

vboxMg.ShutdownMachine("$yourmachine")