This version is a major update. The following major new features were added: * Reorganization of VirtualBox into a base package and Extension Packs; see chapter 1.5, Installing VirtualBox and extension packs, see the manual for more information * New settings/disk file layout for VM portability; see chapter 10.1, Where VirtualBox stores its files, see the manual for more information * Major rework of the GUI (now called “VirtualBox Manager”): o Redesigned user interface with guest window preview (also for screenshots) o New “scale” display mode with scaled guest display; see chapter 1.8.5, Resizing the machine’s window, see the manual for more information o Support for creating and starting .vbox desktop shortcuts (bug #1889) o The VM list is now sortable o Machines can now be deleted easily without a trace including snapshots and saved states, and optionally including attached disk images (bug #5511; also, VBoxManage unregistervm --delete can do the same now) o Built-in creation of desktop file shortcuts to start VMs on double click (bug #2322) * VMM: support more than 1.5/2 GB guest RAM on 32-bit hosts * New virtual hardware: o Intel ICH9 chipset with three PCI buses, PCI Express and Message Signaled Interrupts (MSI); see chapter 3.4.1, “Motherboard” tab, see the manual for more information o Intel HD Audio, for better support of modern guest operating systems (e.g. 64-bit Windows; bug #2785) * Improvements to OVF support (see chapter 1.12, Importing and exporting virtual machines, see the manual for more information): o Open Virtualization Format Archive (OVA) support o Significant performance improvements during export and import o Creation of the manifest file on export is optional now o Imported disks can have formats other than VMDK * Resource control: added support for limiting a VM’s CPU time and IO bandwidth; see chapter 5.8, Limiting bandwidth for disk images, see the manual for more information * Storage: support asynchronous I/O for iSCSI, VMDK, VHD and Parallels images * Storage: support for resizing VDI and VHD images; see chapter 8.21, VBoxManage modifyhd, see the manual for more information. * Guest Additions: support for multiple virtual screens in Linux and Solaris guests using X.Org server 1.3 and later * Language bindings: uniform Java bindings for both local (COM/XPCOM) and remote (SOAP) invocation APIs In addition, the following items were fixed and/or added: * VMM: Enable large page support by default on 64-bit hosts (applies to nested paging only) * VMM: fixed guru meditation when running Minix (VT-x only; bug #6557) * VMM: fixed crash under certain circumstances (Linux hosts only, non VT-x/AMD-V mode only; bugs #4529 and #7819) * GUI: add configuration dialog for port forwarding in NAT mode (bug #1657) * GUI: show the guest window content on save and restore * GUI: certain GUI warnings don’t stop the VM output anymore * GUI: fixed black fullscreen minitoolbar on KDE4 hosts (Linux hosts only; bug #5449) * BIOS: implemented multi-sector reading to speed up booting of certain guests (e.g. Solaris) * Bridged networking: improved throughput by filtering out outgoing packets intended for the host before they reach the physical network (Linux hosts only; bug #7792) * 3D support: allow use of CR_SYSTEM_GL_PATH again (bug #6864) * 3D support: fixed various clipping/visibility issues (bugs #5659, #5794, #5848, #6018, #6187, #6570) * 3D support: guest application stack corruption when using glGetVertexAttrib[ifd]v (bug #7395) * 3D support: fixed OpenGL support for libMesa 7.9 * 3D support: fixed Unity/Compiz crashes on natty * 2D Video acceleration: multimonitor support * VRDP: fixed rare crash in multimonitor configuration * VRDP: support for upstream audio * Display: fixed occasional guest resize crash * NAT: port forwarding rules can be applied at runtime * SATA: allow to attach CD/DVD-ROM drives including passthrough (bug #7058) * Floppy: support readonly image files, taking this as the criteria for making the medium readonly (bug #5651) * Audio: fixed memory corruption during playback under rare circumstances * Audio: the DirectSound backend now allows VMs to be audible when another DirectSound application is active, including another VM (bug #5578) * EFI: support for SATA disks and CDROMs * BIOS: reduce the stack usage of the VESA BIOS function #4F01 (Quake fix) * OVF/OVA: fixed export of VMs with iSCSI disks * Storage: Apple DMG image support for the virtual CD/DVD (bug #6760) * Linux host USB support: introduced a less invasive way of accessing raw USB devices (bugs #1093, #5345, #7759) * Linux hosts: support recent Linux kernels with CONFIG_DEBUG_SET_MODULE_RONX set * Guest Additions: Shared Folders now can be marked as being auto-mounted on Windows, Linux and Solaris guests * Linux Additions: Shared Folders now support symbolic links (bug #818) * Linux Additions: combined 32-bit and 64-bit additions into one file * Windows Additions: automatic logon on Windows Vista/Windows 7 is now able to handle renamed user accounts; added various bugfixes For the changelog of previous VirtualBox series, have a look at Reproducible: Always Steps to Reproduce:
(In reply to comment #0) > This version is a major update. The following major new features were added: I do not think quoting the full changelog is necessary. Just link to the website instead. > * Reorganization of VirtualBox into a base package and Extension Packs; This probably requires reorganisation of the ebuilds, too. I assume that app-emulation/virtualbox-ose will become app-emulation/virtualbox and the non-free extensions will move into a separate package.
I do not really have much time to work on this at the moment. So any help of volunteers is highly appreciated.
FYI with 4.0 app-emulation/virtualbox-bin should be depreciated as the binaries are only gpl code. USB EHCI is implemented with an extension pack now, available on the virualbox website.
Created attachment 257912 [details] Updated ebuild for 4.0.0 This is an updated ebuild for virtualbox-ose. added a use flag for "doc" as it appears we weren't and still aren't installing them. added dependencies app-arch/makeself and doc? ( dev-texlive/texlive-basic dev-texlive/texlive-latex dev-texlive/texlive-latexrecommended dev-texlive/texlive-latexextra dev-texlive/texlive-fontsrecommended dev-texlive/texlive-fontsextra ) currently require 3 updated patches.
Created attachment 257914 [details, diff] updated asneeded patch
Created attachment 257916 [details, diff] Updated VNC patch
Created attachment 257919 [details, diff] fix dependency patch
Sorry for additional noise. I'm a little new at this. Comments welcome.
Do you also have an ebuild for the extension-pack?
Created attachment 257932 [details, diff] patch 3.2.12 -> 4.0.0 Ebuild looks good so far, changes are minimal. I renamed the patches from virtualbox-ose-X-4.0.0.patch to virtualbox-ose-4.0.0-X.patch, as that seems to be the standard. Attached is the patch from 3.2.12 to 4.0.0 for easier review.
Hi Jonathan. Thanks for the ebuild and the patches. I've looked at the ebuild and it looks quite good. I have some suggestions I've already implemented in my private overlay at https://www.fn-clan.de/downloads/gentoo/poly-c_overlay/app-emulation/ I'd like to rename the ebuild from app-emulation/virtualbox-ose to app-emulation/virtualbox as I am planning to remove app-emulation/virtualbox-bin once some 4.x version becomes stable. The makeself dependency and the makeself patch are IMHO not necessary. Simply patch the check for makeself away from the configure script. I don't see any reason why virtualbox should need makeself. A patch which removes the check can be found in my overlay. The asneeded patch doesn't work anymore when you use a compiler with forced asneeded (see http://www.gentoo.org/proj/en/qa/asneeded.xml section "Forced --as-needed"). I will ask some of our asneeded-gurus for help about this once the ebuild landed in portage. I'm still wondering if it's really worth requiring a user to install fully blown latex just for getting some documentation installed. I think it's a bit overkill but if there are many voices appearing which want to have that feature I can keep it of course. There is one problem with installing the renamed ebuild. Once installation finished you have to run "env-update" as root and then "source /etc/profile" as user because the VBOX_APP_HOME variable changed. Otherwise the new virtualbox won't start but just present some error message window. A reboot should do the same of course but we aren't using windows are we? ;)
Keywords += InOverlay ? (s.g.o doesn't have the ebuild yet)
Whoops, I wonder why my comment changed the bug status to RESOLVED FIXED. The bug will stay open until the ebuild is in portage. Well my overlay is no official one which can get added through layman easily (it's possible of course but not through a single "layman -a"). So I'd say leave the keyword for now.
I figured out a problem: The ebuild as presented here automagically uses Java. What makes this worse is that it uses /usr/lib/jvm/java-6-sun/bin/javac as the path to javac, without ever checking the existence of that file. See VirtualBox-4.0.0_OSE/Config.kmk: # Add correct detection for you distro after the /usr/../java-6-sun line.
(In reply to comment #14) > I figured out a problem: > The ebuild as presented here automagically uses Java. What makes this worse is > that it uses /usr/lib/jvm/java-6-sun/bin/javac as the path to javac, without > ever checking the existence of that file. > > See VirtualBox-4.0.0_OSE/Config.kmk: > # Add correct detection for you distro after the /usr/../java-6-sun line. Should be fixed in my overlay.
*** Bug 349624 has been marked as a duplicate of this bug. ***
*** Bug 349622 has been marked as a duplicate of this bug. ***
*** Bug 349618 has been marked as a duplicate of this bug. ***
The extpack is just a tar gz file with the extension .vbox-extpack. It extracts with the extension installer built in to with the one I submitted: /usr/lib/virtualbox-ose/ExtensionPacks/Oracle_VM_VirtualBox_Extension_Pack/ current contents: darwin.amd64/ darwin.x86/ linux.amd64/ linux.x86/ solaris.amd64/ solaris.x86/ win.amd64/ win.x86/ I don't think we need all of them, Just the linux. not sure how to unpack it from portage.
Created attachment 257999 [details] extpack ebuild.
(In reply to comment #21) > Created an attachment (id=257999) [details] > extpack ebuild. mkdir should be replaced with dodir, cp with dobin & friends.
Thank you hubertstar. I've added a modified version of your ebuild to my overlay. As soon as I had some time to work on and test the virtualbox-guest-additions and the xf86-{input,video}-virtualbox packages I gonna add all ebuilds to portage.
I was wondering about the naming of the extpack ebuild. As it is possible that others may come out with packs I was thinking either virtualbox-extpack-oracle or virtualbox-oracle-extpack.
*** Bug 349746 has been marked as a duplicate of this bug. ***
(In reply to comment #24) > I was wondering about the naming of the extpack ebuild. As it is possible that > others may come out with packs I was thinking either virtualbox-extpack-oracle > or virtualbox-oracle-extpack. > Good idea! virtualbox-extpack should be a meta-package, Install oracle extpack by enable use flag. I was uploaded the new virtualbox-extpack ebuild. Lars Wendler, please check it. sorry for my bad english.
Created attachment 258153 [details] new virtualbox-extpack ebuild with oracle use flag.
hubestar, you had the correct idea with creating a meta package for the extensions but as long as there's only one extensions package available a meta package simply makes no sense. As soon as there are more than one extensions available I gonna add a meta package. Meanwhile I will stick with virtualbox-extpack-oracle.
(In reply to comment #26) > (In reply to comment #24) > > I was wondering about the naming of the extpack ebuild. As it is possible that > > others may come out with packs I was thinking either virtualbox-extpack-oracle > > or virtualbox-oracle-extpack. > > > > Good idea! > > virtualbox-extpack should be a meta-package, Install oracle extpack by enable > use flag. This doesn't seem like the current gentoo way of doing it. IMHO, you should use the same technique as the VIDEO_CARDS="", ALSA_CARDS="" variables in make.conf, which are use-expanded.
(In reply to comment #29) > (In reply to comment #26) > > (In reply to comment #24) > > > I was wondering about the naming of the extpack ebuild. As it is possible that > > > others may come out with packs I was thinking either virtualbox-extpack-oracle > > > or virtualbox-oracle-extpack. > > > > > > > Good idea! > > > > virtualbox-extpack should be a meta-package, Install oracle extpack by enable > > use flag. > > This doesn't seem like the current gentoo way of doing it. IMHO, you should use > the same technique as the VIDEO_CARDS="", ALSA_CARDS="" variables in make.conf, > which are use-expanded. I don't see a reason to not do it the same way like it's done in media-plugins/gst-plugins-meta (via USE flags and not through another make.conf variable...). Once there are a big load of different extensions available we can still implement this. But currently it's just too early to do it this way. AFAIK there's still only the Oracle extension pack available.
(In reply to comment #30) > (In reply to comment #29) > > (In reply to comment #26) > > > (In reply to comment #24) > > > > I was wondering about the naming of the extpack ebuild. As it is possible that > > > > others may come out with packs I was thinking either virtualbox-extpack-oracle > > > > or virtualbox-oracle-extpack. > > > > > > > > > > Good idea! > > > > > > virtualbox-extpack should be a meta-package, Install oracle extpack by enable > > > use flag. > > > > This doesn't seem like the current gentoo way of doing it. IMHO, you should use > > the same technique as the VIDEO_CARDS="", ALSA_CARDS="" variables in make.conf, > > which are use-expanded. > > I don't see a reason to not do it the same way like it's done in > media-plugins/gst-plugins-meta (via USE flags and not through another make.conf > variable...). All of the USE-flags state a certain feature or codec, or something like it. Well, or just think about why most of those USE_flags are global. But in contrast, already the first USE-flag in the ebuilds attached to this bug, is highly specific. If it was called "usb" instead of "oracle", that would probably be a better use-flag-way of doing things. (On the other hand, it's just usb 2.0 support) I would really vote for another make.conf variable - if that is needed at all. Similar to the xorg-drivers ebuild, for example (it only uses make.conf variables). > Once there are a big load of different extensions available we > can still implement this. But currently it's just too early to do it this way. > AFAIK there's still only the Oracle extension pack available. Sure. I wasn't asking for it to happen right now. Emerging the one extpack seperately is not a big deal.
At this time, which file should to be tested ? virtualbox-ose-4.0.0.ebuild.patch or virtualbox-ose-4.0.0.ebuild ?
(In reply to comment #32) > At this time, which file should to be tested ? > virtualbox-ose-4.0.0.ebuild.patch or virtualbox-ose-4.0.0.ebuild ? The ebuilds being in my overlay are the ones which will go into portage. FYI, I've planned to add the ebuilds p.masked before end of the year.
Virtualbox should depend on cdrtools (requires mkisofs) Checking for mkisofs: ** mkisofs (variable MKISOFS) not found!
(In reply to comment #34) > Virtualbox should depend on cdrtools (requires mkisofs) > > Checking for mkisofs: > ** mkisofs (variable MKISOFS) not found! This is simply another useless check which I now patched away.
(In reply to comment #11) > I'd like to rename the ebuild from app-emulation/virtualbox-ose to > app-emulation/virtualbox as I am planning to remove > app-emulation/virtualbox-bin once some 4.x version becomes stable. That's bad news for me. I am running amd64 no-multilib on all of my systems, and virtualbox-bin is the only package I can merge because of virtualbox-ose using the 32-bit toolchain for building the guest additions (according to http://www.virtualbox.org/wiki/Linux%20build%20instructions). Will the new virtualbox-4.0.0 package still need 32-bit components?
(In reply to comment #36) > (In reply to comment #11) > > I'd like to rename the ebuild from app-emulation/virtualbox-ose to > > app-emulation/virtualbox as I am planning to remove > > app-emulation/virtualbox-bin once some 4.x version becomes stable. > > That's bad news for me. I am running amd64 no-multilib on all of my systems, > and virtualbox-bin is the only package I can merge because of virtualbox-ose > using the 32-bit toolchain for building the guest additions (according to > http://www.virtualbox.org/wiki/Linux%20build%20instructions). > > Will the new virtualbox-4.0.0 package still need 32-bit components? Uh... I didn't take no-multilib users into account... sorry for that. I guess I will have to set up a no_multilib environment first to test this issue but I cannot do that before I return home from 27C3. If this is still true for vbox-4 the planned package rename cannot be done of course (although I really dislike maintenance of the -bin package as I don't use it on any of my systems). Seems like there will be no vbox-4 in portage before next year :-/
(In reply to comment #33) > (In reply to comment #32) > > At this time, which file should to be tested ? > > virtualbox-ose-4.0.0.ebuild.patch or virtualbox-ose-4.0.0.ebuild ? > > The ebuilds being in my overlay are the ones which will go into portage. > what is the name of the overlay? :-)
https://www.fn-clan.de/downloads/gentoo/poly-c_overlay/app-emulation/ Is in the URL of this bug. You can extract only relevant part from overlay via: lftp -e "mirror --only-newer --verbose downloads/gentoo/poly-c_overlay/app-emulation/ ." http://www.fn-clan.de/ and use your local overlay or you can use the normal method: layman -o http://www.fn-clan.de/downloads/gentoo/poly-c_overlay/layman-poly-c.xml && layman -a poly-c
(In reply to comment #39) > https://www.fn-clan.de/downloads/gentoo/poly-c_overlay/app-emulation/ > Is in the URL of this bug. You can extract only relevant part from overlay via: > lftp -e "mirror --only-newer --verbose > downloads/gentoo/poly-c_overlay/app-emulation/ ." http://www.fn-clan.de/ and > use your local overlay or you can use the normal method: layman -o > http://www.fn-clan.de/downloads/gentoo/poly-c_overlay/layman-poly-c.xml && > layman -a poly-c > * Overlay "poly-c" does not exist. first method seems to work but I would prefer using layman to stay updated easily
(In reply to comment #40) > * Overlay "poly-c" does not exist. > > first method seems to work but I would prefer using layman to stay updated > easily Didn't work for me neither (layman 1.4.1). I had to add the URL to the XML file to layman.cfg. Then it worked.
(In reply to comment #40) > (In reply to comment #39) > > use your local overlay or you can use the normal method: layman -o > > http://www.fn-clan.de/downloads/gentoo/poly-c_overlay/layman-poly-c.xml && > > layman -a poly-c > > > > * Overlay "poly-c" does not exist. > > first method seems to work but I would prefer using layman to stay updated > easily According to the manpage of layman the command should look like this: layman -o http://www.fn-clan.de/downloads/gentoo/poly-c_overlay/layman-poly-c.xml -a poly-c
(In reply to comment #42) > (In reply to comment #40) > > (In reply to comment #39) > > > use your local overlay or you can use the normal method: layman -o > > > http://www.fn-clan.de/downloads/gentoo/poly-c_overlay/layman-poly-c.xml && > > > layman -a poly-c > > > > > > > * Overlay "poly-c" does not exist. > > > > first method seems to work but I would prefer using layman to stay updated > > easily > According to the manpage of layman the command should look like this: > layman -o > http://www.fn-clan.de/downloads/gentoo/poly-c_overlay/layman-poly-c.xml -a > poly-c You're right. Seems like this has changed a bit in portage. But your given command still doesn't work as the -f option is missing. The full command looks like this: layman -o http://www.fn-clan.de/downloads/gentoo/poly-c_overlay/layman-poly-c.xml -f -a poly-c (replace -a with -s if you want to re-sync the overlay) This might be a good opportunity to request addition of my overlay to the official list of overlays. Sorry for the inconveniences guys. I gonna try to sort this out as soon as possible.
s/portage/layman/ (damn I need some sleep when 27C3 is over ;)
I would like to see a bump of the virtualbox-bin ebuild (which would not include the expack). Up to know, I have QT-free system, and emergeing virtualbox 4.0 pulls in QT :-(
btw ebuild working well and no problems so far :-)
Works fine on my x86 box, too
*** Bug 350214 has been marked as a duplicate of this bug. ***
poly-c overlay is now officially available through layman (thanks to sping). By the way, chances are high that virtualbox-4.0.0 will go into portage as virtualbox-ose-4.0.0 and removeal of virtualbox-bin will be skipped for now (no guaranty that it won't go away anytime later). I know that this will impose some more trouble to all you brave testers out there but at least the no-multilib issue is important enough to not get rid of virtualbox-bin yet. What still bothers me is the naming of the extpack. I don't think "virtualbox-extpack-oracle" is appropriate. I'd rather prefer "virtualbox-extpack-puel". What do you guys think?
IMHO a clean way to do that and stay consistent with the behaviour of the rest of the tree is to have a package name like 'virtualbox-extension-packs' and use the ACCEPT_LICENSE variable (e.g. ACCEPT_LICENSE="PUEL") to unmask the package. Btw, naming '-ose' makes no-sense because there is no proprietary/open versions anymore, the only things that remain closed are the extension modules. It doesn't hurt however.
(In reply to comment #49) > What still bothers me is the naming of the extpack. I don't think > "virtualbox-extpack-oracle" is appropriate. I'd rather prefer > "virtualbox-extpack-puel". What do you guys think? Why should the license be part of the name? What if company XYZ releases another extpack under gpl, would that be called virtualbox-extpack-gpl rather than virtualbox-extpack-XYZ? What if multiple extpacks with the same license exist?
Throwing in my very own opinion on the extpack naming, if you all don’t mind. The only thing that defines an extpack, as of now (and probably in the future as well), is its manufacturer, so that’s what should be part of the name. I started out by considering: N1. virtualbox-extpack-oracle N2. virtualbox-extpack-usb N3. virtualbox-extpack-puel N4. virtualbox-oracle-extpack Maybe in the future: F1. somebody else will come up with an alternative (maybe free) USB extpack; F2. Oracle’s own extpack will come to include other extensions (say, a virtual modem card); F3. an extpack will be released under multiple licenses. In the F1 case, we want to avoid collision over ”usb”, so N2 isn’t a viable option; N2 isn’t an option due to F2 too; due to F3, I’d also suggest against N3. So, the only remaining ones are N1 and N4; as a personal preference, I’d go for N1, but that’s just me of course; I’m sure others might prefer the brand+extpack order. Also, there’s nothing weird about having oracle in the package name; for a long time we’ve had www-browser/mozilla-firefox, so this isn’t anything new. I hope this helps solve the naming issue.
*** Bug 350401 has been marked as a duplicate of this bug. ***
Created attachment 258674 [details] virtualbox-modules-4.0.0
Created attachment 258676 [details] virtualbox-ose-additions-4.0.0
*** Bug 350852 has been marked as a duplicate of this bug. ***
Alright gyus I've now added the following packages to the tree: app-emulation/virtualbox-4.0.0 app-emulation/virtualbox-bin-4.0.0 app-emulation/virtualbox-modules-4.0.0 app-emulation/virtualbox-additions-4.0.0 app-emulation/virtualbox-extpack-oracle-4.0.0 x11-drivers/xf86-input-virtualbox-4.0.0 x11-drivers/xf86-video-virtualbox-4.0.0 app-emulation/virtualbox-guest-additions-4.0.0 Thank you very much for all your suggestions and your brave testings :) If there are any problems with the new packages, please file new bugs (after you have looked that there wasn't already filed one for the problem you wanna report ;). As soon as there are other extpacks than the oracle one I gonna start working on a -meta package with USE_EXPAND. If you find extpacks not being in the tree, don't hesitate to report them via bugzilla.
