It works well with Windows at least on amd64. Reproducible: Always
Next stable candidate will be version 4.0.10 unless there are severe bugs.
Lets do 4.0.10 =app-emulation/virtualbox-4.0.10 =app-emulation/virtualbox-additions-4.0.10 =app-emulation/virtualbox-bin-4.0.10-r1 =app-emulation/virtualbox-extpack-oracle-4.0.10 =app-emulation/virtualbox-guest-additions-4.0.10 =app-emulation/virtualbox-modules-4.0.10 =x11-drivers/xf86-input-virtualbox-4.0.10 =x11-drivers/xf86-video-virtualbox-4.0.10 Acked by Lars (Polynomial-C)
I ain't sure about this.
amd64: virtualbox suite is fairly complex so for now; emerged all but =app-emulation/virtualbox-bin-4.0.10-r1; Am sure virtualbox and virtualbox-bin conflict, only one or other emerged at one time. After finally figuring out what kernel it was I was using, all is good and successful. Loaded modules, invoked gui, installed a suse vm straight up.
All doing well. emerged virtualbox with all use flags in staggered fashion. No sign of trouble. Response lightening fast. One odd thing. The gui cites /etc/init.d/vboxdrv as a way to load modules if not loaded. While modprobe module loads it, this /etc/init.d/vboxdrv just isn't installed. May be now defunct service in this version still referenced by tooltip. Shall switch to virtualbox-bin tomorrow.
That'a cause it's the Debian/Ubuntu way to do so.
dE Aha. Is a debian method hardcoded into a gentoo version and not removable? A minor mishap. virtualbox-bin doesn't fire up. The virtualbox version is more gentoo like anyway
As an alternative, the other way round is also possible. Terminal output and all?
dE You lost me. That aside, found a fix. Newcomer tester emerged and followed the suggested workaround for vbox-bin. Happily it worked, just view the bug. It lends itself to refinement of the ebuild to unset and re-set the environment variables that cause this.
I tested the switch from virtualbox to virtualbox-bin, the fix of the error is a logout and a login back again. (Findings posted there) I also tested the switch back from virtualbox-bin to virtualbox, it also gives the same error and the fix is a logout and a login as well.
Alright... virtualbox-4.0.12 has been released which fixes bug #364717 so I suggest to stabilize this version rather than 4.0.10. Any oppinions?
Like I said, the current stable version does not work with stable X when Gentoo is a guest. Speaking for @amd64 I would like to have a version 4.X stable ASAP. So either stabilize this version or fast-stabilize the 4.0.12
Now that virtualbox-4.1.0 was released and I had some time to do tests with virtualbox-4.0.12 I gonna push a fast stabilization of virtualbox-4.0.12. Arches please test and mark stable the following list of packages: =app-emulation/virtualbox-4.0.12 =app-emulation/virtualbox-additions-4.0.12 =app-emulation/virtualbox-bin-4.0.12 =app-emulation/virtualbox-extpack-oracle-4.0.12 =app-emulation/virtualbox-guest-additions-4.0.12 =app-emulation/virtualbox-modules-4.0.12 =x11-drivers/xf86-input-virtualbox-4.0.12 =x11-drivers/xf86-video-virtualbox-4.0.12 Target keywords are: amd64 x86 FYI: bug #374429 is no real blocker.
amd64 i use virtualbox and 4.1.12 works well so far
(In reply to comment #14) > amd64 i use virtualbox and 4.1.12 works well so far 4.0.12, sorry for the noise
I think we should all learn from the Debian release cycle. Stabilizing this frequently is not a good idea. You should wait for 10 to 15 days to see if bugs persists in the package.
(In reply to comment #16) > I think we should all learn from the Debian release cycle. Stabilizing this > frequently is not a good idea. You should wait for 10 to 15 days to see if bugs > persists in the package. This is the lastest and more importantly the last bugfix release of the 4.0 series. 3.0.12 is hopelessly outdated and we definitely need a 4.0 version stable. I don't see any reasons to not stabilize virtualbox-4.0.12 right now. Arches please proceed.
x86 stable. Works really well here.
(In reply to comment #16) > I think we should all learn from the Debian release cycle. Stabilizing this > frequently is not a good idea. You should wait for 10 to 15 days to see if bugs > persists in the package. So you say that we should have a broken stable tree for 15 days. This is not an option for amd64. We will go for 4.0.12 like x86 did
amd64 done. Thanks Blain
(In reply to comment #20) > amd64 done. Thanks Blain amd64 isn't done. virtualbox-{modules,additions,...} is stable now, but app-emulation/virtualbox-4.0.12 itself is still ~amd64.
(In reply to comment #21) > (In reply to comment #20) > > amd64 done. Thanks Blain > > amd64 isn't done. virtualbox-{modules,additions,...} is stable now, but > app-emulation/virtualbox-4.0.12 itself is still ~amd64. Reopening. Markos, please push virtualbox to stable as well. Thanks.
+ 24 Jul 2011; Lars Wendler <polynomial-c@gentoo.org> virtualbox-4.0.10.ebuild, + virtualbox-4.0.12.ebuild, virtualbox-4.1.0.ebuild: + Made pam support optional (bug #351404). Marked 4.0.12 version as stable on + amd64 (was forgotten by the arch team) for bug #371935.
