New port: emulators/virtualbox v4.x

[carsomyr@…]

Please find attached virtualbox-port-4.0.4.tgz, which is a submission for the open source edition of VirtualBox (​http://www.virtualbox.org/). I have a high degree of confidence that this port will build out-of-the-box for others. It if does, this submission would also close ticket #23080.

Note that there's an unusual aspect to this port, which is installation and loading of kernel modules. This requires installation of files outside of standard MacPorts locations, namely /Library/Extensions and /Library/StartupItems.

[raimue (Rainer Müller)]

To make clear that this differs from the binary VirtualBox distribution, I would recommend to rename this port to virtualbox-ose (Open Source Edition).

[carsomyr@…]

Replying to raimue@…:

To make clear that this differs from the binary VirtualBox distribution, I would recommend to rename this port to virtualbox-ose (Open Source Edition).

How about VirtualBox-OSE? Also, have you tried building and running?

[carsomyr@…]

Ok, I've reattached the port archive, which contains a rename from VirtualBox to VirtualBox-OSE.

[pixilla (Bradley Giesbrecht)]

I could not extract the attached virtualbox-port-4.0.4.tgz.
Could you upload the Portfile and any accompanying files, individually and uncompressed?

[carsomyr@…]

Did you try clicking on this link, and then clicking on downloaded archive file? I find it unlikely that OS X's Finder can't open it.

​https://trac.macports.org/raw-attachment/ticket/28469/virtualbox-port-4.0.4.tgz

[pixilla (Bradley Giesbrecht)]

Replying to carsomyr@…:

Did you try clicking on this link, and then clicking on downloaded archive file? I find it unlikely that OS X's Finder can't open it.

​https://trac.macports.org/raw-attachment/ticket/28469/virtualbox-port-4.0.4.tgz

No, I clicked the link in the "Attachments" section above. This link "raw-attachment" works.

[ryandesign (Ryan Carsten Schmidt)]

Thanks for working on this! I tried make a VirtualBox OSE port some time ago at version 3.0.8 but got stuck on something. It'll be great to have this in MacPorts finally.

Some thoughts on your portfile:

• We don't have a category "virtualization"; the closest we have is "emulators".
• "openmaintainer" by itself should be "nomaintainer" (see port lint).
• Rather than mentioning the license in the description, use the license keyword.
• Would this port work with libsdl-devel? If so, the libsdl dependency should be written so that libsdl-devel could satisfy it. Consult most any other port that depends on libsdl to see how this is done.
• You test build_arch in the destroot; what happens when the port is built universal?
• If PowerPC architectures are unsupported, it would be nice to bail out before the user has already downloaded and tried to build it. At minimum, you should put "supported_archs i386 x86_64"; if that's not enough to prevent installation on a PowerPC Mac, then a pre-fetch block should also be there; see the wine port for an example.
• We're not used to having ports that start services just by virtue of the port being installed. What does the startup item do when started and stopped? Perhaps it is better to inform the user how to do this and let them do it on their own.
• Can it be a launchd plist instead of a startup item? Startup items are so Panther (and MacPorts doesn't support Panther anymore so there's no reason not to use a launchd plist). If you use the standard (now misnamed) startupitem keywords to create the plist, this will automatically take care of informing the user how to use it.

[carsomyr@…]

The VirtualBox-OSE port archive.

[carsomyr@…]

Ok, I've attached the revised port archive. I made the following changes:

• The category is now "emulators". Although VirtualBox isn't exactly emulation, I found that BSD FreshPorts had the same classification.
• openmaintainer -> nomaintainer.
• The license keyword is GPL-2.
• openssl and libsdl now use pkgconfig, thus enabling libsdl-devel to provide the lib dependency.
• The "universal" variant has been disabled.
• Added "supported_archs i386 x86_64".
• Kernel extensions are now not loaded on VirtualBox activation. Instead, the following message is printed:

  ################################################################################
  # A Mac OS X Startup Item for loading and unloading VirtualBox kernel
  # extensions has been generated at ${startup_items_dir}/VirtualBox; it will be
  # run at next boot or by typing:
  # 
  # sudo SystemStarter start VirtualBox
  ################################################################################
  

  Note that kernel extensions will be loaded on reboot, though.

As for the Startup Items issue, I left it the way it was, for the following reasons:

• The Startup Item was provided, with all metadata plists, by Sun/Oracle.
• The act of loading kernel extensions is not a daemon. The launchd daemon was designed to launch other daemons. As such, it doesn't have any concept of a stop hook. I believe that MacPorts' daemondo mechanism is meant for daemons, too.
• Startup Items aren't deprecated; they're use for launching on-demand daemons is deprecated. See this link for the Mac OS X boot process: ​http://bit.ly/hrfcdV+. The documentation actually suggests using Startup Items for non-launch-on-demand daemons. I would argue that Startup Items are better tied to the boot up / shutdown cycle for Mac OS, and that VirtualBox's kernel extension loading behavior is best implemented as such.

Still, if it's absolutely necessary, I can convert the Mac OS Startup Item to a MacPorts "startupitem". I just don't think it's appropriate given the uniqueness of the Port (unless there are other Ports out there with kernel modules that I'm not aware of).

[carsomyr@…]

Any success with the revised port?

[carsomyr@…]

FYI, I've upgraded the port archive to 4.0.6. Enjoy!

[chris.perl@…]

I'm curious what version of Mac OS you're running, etc. I'm running on Snow Leopard and trying to 'sudo port -d -D . install' either of the attached virtual box port archives (with the CWD being that of the necessary Portfile) resulted in /dev/null being deleted from my system. The lack of /dev/null then resulted in the port build failing (as well as many other programs on my machine failing to work, i.e. the 'port' command just failed with the error "Illegal instruction").

I used DTrace to debug the problem (I can share the details if you want), but basically, it comes down to the virtual box build system passing "-o /dev/null" to gcc, which eventually gets passed to ld, and ld tries to remove the file its writing its output to if it already exists. Hence /dev/null being deleted.

I fixed this by patching Config.kmk. I'll attach the diff to this ticket in case anyone else wants it.

This may be a personal problem, but I figured I would share in case anyone else ran into this.

To re-create /dev/null, i had to enable the root user, logout, login on the console (using ">console") and then "mknod /dev/null c 3 2 && chmod 666 /dev/null".

[carsomyr@…]

That's very odd indeed, because I use Snow Leopard, too. My port command was just "sudo port install VirtualBox-OSE", as I have a designated local MacPorts tree. Have you tried building manually without the portfile?

[chris.perl@…]

Yep, I get the same thing. It happens when building as a normal user too, but doesn't actually break anything because I don't have permission to delete /dev/null. I downloaded and unpacked 4.0.4 source, then ran:

./configure --disable-qt4 --with-openssl-dir=/opt/local && . env.sh && kmk

Note that I disabled qt4 just so I didn't have to deal with patching the files as you do in your port.

While in another window running the following dtrace script:

dtrace -w -n 'syscall::unlink:entry /copyinstr(arg0) == "/dev/null" / { printf("pid: %d, file: %s\n", pid, copyinstr(arg0)); stop(); system("ps -f -p %d", pid); system("gdb %s %d", execname, pid);}'

Which results in the following output:

dtrace: description 'syscall::unlink:entry ' matched 1 probe
dtrace: allowing destructive actions
CPU     ID                    FUNCTION:NAME
  0  18659                     unlink:entry pid: 91740, file: /dev/null

  UID   PID  PPID   C     STIME TTY           TIME CMD
  501 91740 91736   0   0:00.00 ttys003    0:00.00 /usr/libexec/gcc/i686-apple-darwin10/4.0.1/collect2 -dynamic -arch i386 -macosx_version_min 10.6.7 -weak_reference_mismatches non-weak -o /dev/null -L/usr/lib/i686-apple-darwin10/4.0.1 -L/usr/lib/gcc/i686-apple-darwin10/4.0.1 -L/usr/lib/gcc/i686-apple-darwin10/4.0.1 -L/usr/lib/gcc/i686-apple-darwin10/4.0.1/../../../i686-apple-darwin10/4.0.1 -L/usr/lib/gcc/i686-apple-darwin10/4.0.1/../../.. --as-needed -u start -undefined dynamic_lookup /var/folders/oS/oStm863DF04cPUL51x9zNE+++TI/-Tmp-//cc2oMFNq.o

GNU gdb 6.3.50-20050815 (Apple version gdb-1515) (Sat Jan 15 08:33:48 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...collect2: No such file or directory

/Users/cperl/91740: No such file or directory
Attaching to process 91740.
Reading symbols for shared libraries . done
Reading symbols for shared libraries .... done
0x91200eae in __unlink ()
(gdb)

Note that in this output the process is "collect2" but I also noted "ld" trying to unlink /dev/null later in the process.

[carsomyr@…]

Have you tried upgrading XCode?

[carsomyr@…]

I've integrated chris.perl's patch into the 4.0.6 port archive.

[carsomyr@…]

FYI, I've made some improvements to the 4.0.6 port archive. At Chris Perl's request, support for the VDE (​http://vde.sourceforge.net/) library has been added as the "vde2" variant. Incidentally, VDE doesn't yet exist as a MacPort, and although Chris was nice enough to provide a Portfile (I leave it to him to upload what he feels is the most appropriate version). Additionally, internally built versions of libxml2 and libxslt have been added as Port dependencies.

[chris.perl@…]

Thanks for including my suggestions. I've submitted vde2 as ticket 29319.

As for the removal of /dev/null, this appears to be a problem with VirtualBox's build system. I sent an email to vbox-dev with all the details and am waiting to hear back (​http://vbox.innotek.de/pipermail/vbox-dev/2011-April/003946.html).

I ran into the problem because I'm running macports 1.9.2, which by default still builds everything as root. carsomyr didn't run into the same problem because he is running a version of macports checked out of svn, and it appears they've switched the default to building as 'nobody.' Regardless, the changes integrated into the port should stop that from happening no matter what version you're running.

[carsomyr@…]

The VirtualBox-OSE port archive (update to 4.0.6).

[carsomyr@…]

For all that are interested, I upgraded the VirtualBox-OSE port to 4.0.8.

[carsomyr@…]

The VirtualBox-OSE port archive (update to 4.0.8).

[carsomyr@…]

The VirtualBox-OSE port archive (update to 4.0.8).

[carsomyr@…]

FYI, I've updated the Portfile so that it uses Macports-style StartupItems. This maximizes compliance with porting conventions. Please find attached as virtualbox-port-4.0.8.tgz.

[rmstonecipher@…]

Roy,
I attempted building your Portfile and noticed that it is not UsingTheRightCompiler.
I'll make an effort to troubleshoot this (minor) issue and upload a patch for your Portfile.

Cheers,
Ryan Stonecipher

[carsomyr@…]

Replying to rmstonecipher@…:

Roy,
I attempted building your Portfile and noticed that it is not UsingTheRightCompiler.
I'll make an effort to troubleshoot this (minor) issue and upload a patch for your Portfile.

Cheers,
Ryan Stonecipher

Thanks!

In the meantime, I've update the port archive to 4.0.10.

[rmstonecipher@…]

Replying to carsomyr@…:

Replying to rmstonecipher@…:

Roy,
I attempted building your Portfile and noticed that it is not UsingTheRightCompiler.
I'll make an effort to troubleshoot this (minor) issue and upload a patch for your Portfile.

Cheers,
Ryan Stonecipher

Thanks!

In the meantime, I've update the port archive to 4.0.10.

Roy,
Attached is an updated 4.0.10 Portfile including this improvement.
Can I test this port using existing disk images for machines created with the non-OSE VirtualBox?
I would prefer to test before committing a port which requires a >65MB source download.

Cheers,
Ryan Stonecipher

P.S. - many library dependencies appear to be included in this source.
Are all of these fixed-version dependencies required, or can VirtualBox use dynamic libraries?

[rmstonecipher@…]

4.0.10 + UsingTheRightCompiler

[carsomyr@…]

Replying to rmstonecipher@…:

Replying to carsomyr@…:

Replying to rmstonecipher@…:

Roy,
I attempted building your Portfile and noticed that it is not UsingTheRightCompiler.
I'll make an effort to troubleshoot this (minor) issue and upload a patch for your Portfile.

Cheers,
Ryan Stonecipher

Thanks!

In the meantime, I've update the port archive to 4.0.10.

Roy,
Attached is an updated 4.0.10 Portfile including this improvement.
Can I test this port using existing disk images for machines created with the non-OSE VirtualBox?

Yes, I think so -- one version should be able to take over all of the internal data structures left by the other version. If you want to be absolutely sure, you can "export appliance" and then "import appliance".

I would prefer to test before committing a port which requires a >65MB source download.

Cheers,
Ryan Stonecipher

P.S. - many library dependencies appear to be included in this source.
Are all of these fixed-version dependencies required, or can VirtualBox use dynamic libraries?

What fixed version dependencies do you speak of? Do you mean fixed versions like libxml-2.0?

I've folded in your ./configure patch and updated the port archive with the changes (see virtualbox-port-4.0.10.tgz). Consequently, I have some questions of my own:

1. I've been told in an earlier part of this thread that md5 is obsolete as a checksum. Should it be included?
2. Should post-deactivate hooks attempt to unload the port? "port unload" doesn't seem to be invoked when VirtualBox is uninstalled. This is kind of disturbing, since kernel modules are involved.

[carsomyr@…]

The VirtualBox-OSE port archive (update to 4.0.10).

[rmstonecipher@…]

Replying to carsomyr@…:

Replying to rmstonecipher@…:

SNIP P.S. - many library dependencies appear to be included in this source.
Are all of these fixed-version dependencies required, or can VirtualBox use dynamic libraries?

What fixed version dependencies do you speak of? Do you mean fixed versions like libxml-2.0?

I've folded in your ./configure patch and updated the port archive with the changes (see virtualbox-port-4.0.10.tgz). Consequently, I have some questions of my own:

1. I've been told in an earlier part of this thread that md5 is obsolete as a checksum. Should it be included?
2. Should post-deactivate hooks attempt to unload the port? "port unload" doesn't seem to be invoked when VirtualBox is uninstalled. This is kind of disturbing, since kernel modules are involved.

1. If you will allow others to periodically upgrade the port as new versions are released, it is easiest to just edit the version and paste the output of 'port -d checksum' which, as of now, includes md5.
2. Regarding unloading during uninstall, I think that's a great idea. ​MPD has a similar problem which leads to headaches during upgrades. So far for MPD my best solution has been to reboot after upgrading - a rather inelegant solution to what should be a simple operation. This may be worth bringing up on the ​macports-dev mailing list.
   

Cheers,
Ryan Stonecipher

[rmstonecipher@…]

Cc Me!

[carsomyr@…]

Replying to rmstonecipher@…:

Replying to carsomyr@…:

Replying to rmstonecipher@…:

SNIP P.S. - many library dependencies appear to be included in this source.
Are all of these fixed-version dependencies required, or can VirtualBox use dynamic libraries?

What fixed version dependencies do you speak of? Do you mean fixed versions like libxml-2.0?

I've folded in your ./configure patch and updated the port archive with the changes (see virtualbox-port-4.0.10.tgz). Consequently, I have some questions of my own:

1. I've been told in an earlier part of this thread that md5 is obsolete as a checksum. Should it be included?
2. Should post-deactivate hooks attempt to unload the port? "port unload" doesn't seem to be invoked when VirtualBox is uninstalled. This is kind of disturbing, since kernel modules are involved.

1. If you will allow others to periodically upgrade the port as new versions are released, it is easiest to just edit the version and paste the output of 'port -d checksum' which, as of now, includes md5.
2. Regarding unloading during uninstall, I think that's a great idea. ​MPD has a similar problem which leads to headaches during upgrades. So far for MPD my best solution has been to reboot after upgrading - a rather inelegant solution to what should be a simple operation. This may be worth bringing up on the ​macports-dev mailing list.
   

Cheers,
Ryan Stonecipher

Ok, I am taking from the answers above that no further actions should be taken and a solution would result in a change to the MacPorts base. Is ticket #14774 related, by any chance? I was thinking that:

1. Unload on port deactivation always happens.
2. Reactivation happens only during an upgrade and when the previous version was deactivated from the "loaded" state.

Let me know if you encounter any new issues with the revised port. Looking forward to its inclusion!

-Roy

[pixilla (Bradley Giesbrecht)]

Cc Me!

[rmstonecipher@…]

Bradley, Ryan, Roy,
I will test VirtualBox-OSE for a week and can commit it next week if all goes well.

Cheers,
Ryan Stonecipher

[pixilla (Bradley Giesbrecht)]

I have built VirtualBox-OSE +universal several times, the app launches but I have not been able to install an OS. I have not been able to put much time into.
I would like a better startup method. /Library/StartupItems is deprecated.
​http://www.virtualbox.org/ticket/8940
Having the port not violate mtree is worth some effort too.
BTW, for myself, these archive attachments are a lot less fun to work with. I prefer Portfiles and patches that are viewable in trac.

[carsomyr@…]

Replying to pixilla@…:

I have built VirtualBox-OSE +universal several times, the app launches but I have not been able to install an OS. I have not been able to put much time into.
I would like a better startup method. /Library/StartupItems is deprecated.
​http://www.virtualbox.org/ticket/8940
Having the port not violate mtree is worth some effort too.
BTW, for myself, these archive attachments are a lot less fun to work with. I prefer Portfiles and patches that are viewable in trac.

Wait -- what version did you build and test? The current version neither violates the mtree nor uses /Library/StartupItems.

[pixilla (Bradley Giesbrecht)]

Wait -- what version did you build and test? The current version neither violates the mtree nor uses /Library/StartupItems.

Yes, I see that now. Thanks.

[carsomyr@…]

Replying to pixilla@…:

Wait -- what version did you build and test? The current version neither violates the mtree nor uses /Library/StartupItems.

Yes, I see that now. Thanks.

Be careful what you ask for, though: Using MacPorts StartupItems is actually worse for stability, because port unloading (and hence kernel module unloading) does not happen when VirtualBox is deactivated. Better deactivation behavior will probably be implemented in the MacPorts base for ports that have sensitive system-level components.

Ryan, if you're reading this, I'd happily send an e-mail to the dev mailing list concerning unloading semantics. I'm wondering what it should say.

[pixilla (Bradley Giesbrecht)]

This works for me:

/opt/macports-clean/Applications/MacPorts/VirtualBox.app/Contents/MacOS/VirtualBox --startvm WinXP

Launching VirtualBox.app, selecting WinXP and clicking Start gives this dialog error:

Failed to open a session for the virtual machine WinXP.

Does anyone have a clue why?

[carsomyr@…]

Replying to pixilla@…:

This works for me:

/opt/macports-clean/Applications/MacPorts/VirtualBox.app/Contents/MacOS/VirtualBox --startvm WinXP

Launching VirtualBox.app, selecting WinXP and clicking Start gives this dialog error:

Failed to open a session for the virtual machine WinXP.

Does anyone have a clue why?

What MacPorts version are you using? I encountered this exact problem a while ago -- think it has something to do with ticket #29267. If you build MacPorts from trunk you should be fine.

[carsomyr@…]

Another thing to note: I think VirtualBox-OSE should be renamed back to VirtualBox. The reason is that there is no longer a distinction between the open and closed source editions: ​http://www.virtualbox.org/wiki/Editions. Additionally, Ubuntu has already relegated virtualbox-ose to a transitional package: ​http://packages.ubuntu.com/oneiric/virtualbox-ose. What does everyone think?

[pixilla (Bradley Giesbrecht)]

What MacPorts version are you using? I encountered this exact problem a while ago -- think it has something to do with ticket #29267. If you build MacPorts from trunk you should be fine.

That is not a problem for me, my MP is built from trunk r79480. I just updated and rebuilt MP. We will see if that makes a difference.

This MP installation is not prefixed to /opt/local nor is /Applications my MP Applications dir so there could be some hard coded path issues I have not found any yet. It does run from the command line though.

[carsomyr@…]

Replying to pixilla@…:

What MacPorts version are you using? I encountered this exact problem a while ago -- think it has something to do with ticket #29267. If you build MacPorts from trunk you should be fine.

That is not a problem for me, my MP is built from trunk r79480. I just updated and rebuilt MP. We will see if that makes a difference.

This MP installation is not prefixed to /opt/local nor is /Applications my MP Applications dir so there could be some hard coded path issues I have not found any yet. It does run from the command line though.

Do me a favor. Look in the VirtualBox.app directory and check for broken/missing directory symlinks. I count 4 -- 2 MacOS and 2 Resources. Do you see them? I am asking because I believe these caused ticket #29267.

[pixilla (Bradley Giesbrecht)]

Do me a favor. Look in the VirtualBox.app directory and check for broken/missing directory symlinks. I count 4 -- 2 MacOS and 2 Resources. Do you see them? I am asking because I believe these caused ticket #29267.

I don't see any broken simlinks. But I have also modified my Portfile and reinstalled and I am no getting expected results with regard to Launching by double click.

[pixilla (Bradley Giesbrecht)]

I added a pre-deactivate block to unload the kext files. Seems to work for now but I think the startup process could be improved.
The patches used by my portfile are from one of the uploads. I am pretty sure the Port as it stands is Snow Leopard only. My Portfile still needs work but it works better then it did in it's earlier version.

[carsomyr@…]

Replying to pixilla@…:

I added a pre-deactivate block to unload the kext files. Seems to work for now but I think the startup process could be improved.
The patches used by my portfile are from one of the uploads. I am pretty sure the Port as it stands is Snow Leopard only. My Portfile still needs work but it works better then it did in it's earlier version.

So does reinstalling and modifying the Portfile fix your problem? Your previous response was unclear. As for the startup process, the port used to explicitly invoke StartupItems/VirtualBox/VirtualBox, but that got taken out in favor of using MacPorts' StartupItems. It seems that the best solution now is to wait for a fix from the MacPorts base itself regarding deactivation.

Could you download the latest Port archive and "merge" your changes? That away I can see them better.

[carsomyr@…]

The VirtualBox-OSE port archive (update to 4.1.0).

[carsomyr@…]

FYI, I've updated the Port archive to 4.1.0. It builds on Lion.

[fracai]

Cc Me!

[carsomyr@…]

Any luck with building and testing the new version?

[pixilla (Bradley Giesbrecht)]

Replying to carsomyr@…:

Any luck with building and testing the new version?

No, but 4.0.10 worked for me. I will try 4.1.0 in a day or so.

[rmstonecipher@…]

qt won't build for me on Lion. As soon as that wrinkle is ironed out I'll try again.

[carsomyr@…]

Try my other patch: #30278. :)

Replying to rmstonecipher@…:

qt won't build for me on Lion. As soon as that wrinkle is ironed out I'll try again.

[carsomyr@…]

FYI, I've updated the the Port files and added them as four attachments. The main change was to rename VirtualBox-OSE to virtualbox, with the rationale given at ​http://www.virtualbox.org/wiki/Editions. Consequently, the build process has been patched so that the VirtualBox edition in the "About" section is "4.1.0_MacPorts" to explicitly denote a MacPorts build. Enjoy!

[carsomyr@…]

Also, the ticket name should be changed to virtualbox 4.1.0.

[rmstonecipher@…]

I can confirm that the port builds and installs on Lion.

Roy,
I am not able to install the extension pack* (ref. attached screen capture) but all other features worked.

Ryan Schmidt, Bradley, Arno,
I have added this port to my local svn checkout of the ports tree - is it ok to commit now and let remaining issues be resolved in independent bug reports?

Cheers,
Ryan Stonecipher

*optional closed-source add-ons

[rmstonecipher@…]

Extension Pack Installation Failure Message

[carsomyr@…]

For some reason, I can't open the tiff file. Try jpeg?

[rmstonecipher@…]

Replying to carsomyr@…:

For some reason, I can't open the tiff file. Try jpeg?

PNG attached.

[rmstonecipher@…]

Extension Pack Installation Failure Message

[carsomyr@…]

Ryan, I've reattached the four Port files. Could you rebuild and try again? It seems that my previous changes to replace the "_OSE" suffix to the version number with "_MacPorts" wasn't complete, and more files had to be patched. FYI, I used a version before the current set of changes and triggered downloading of the extension pack from a guest OS, and the response was that the extension pack could not be found (the URL had the "_MacPorts" suffix in it). After applying the changes and rebuilding, the extension pack downloaded correctly into "~/Library/VirtualBox/VBoxGuestAdditions_4.1.0.iso". You may want to delete this file and ensure that the Virtual Media Manager forgets all instances of such an image.

-Roy

[carsomyr@…]

The Portfile (revision 3).

[carsomyr@…]

The build patch (revision 3).

[carsomyr@…]

The VDE patch (revision 3).

[carsomyr@…]

The startup patch (revision 3).

[carsomyr@…]

I've reattached all Port files and updated the version to 4.1.2.

[carsomyr@…]

Any luck with the update Port?

[rmstonecipher@…]

I have seen no objection since my proposal to commit the port 7 days ago.
I have successfully built and installed version 4.1.2 using Roy's updated files.
This port has been committed as of r83064.

Roy,
The extension pack (which is not the same as guest additions) still does not work.
That issue can be addressed in a future ticket.

Cheers,
Ryan Stonecipher