Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 251335 - app-emulation/virtualbox-{bin,ose}-2.1.0 version bump
Summary: app-emulation/virtualbox-{bin,ose}-2.1.0 version bump
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal with 1 vote (vote)
Assignee: Markus Ullmann (RETIRED)
URL: http://virtualbox.org
Whiteboard:
Keywords:
: 251456 254130 254949 259123 (view as bug list)
Depends on: 251654
Blocks:
  Show dependency tree
 
Reported: 2008-12-17 17:35 UTC by Maxim Grechkin
Modified: 2009-04-05 06:03 UTC (History)
38 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
The kernel module ebuild (virtualbox-modules-2.1.0.ebuild,1.11 KB, text/plain)
2008-12-17 20:58 UTC, Alexey Charkov
Details
The main app ebuild (virtualbox-bin-2.1.0.ebuild,5.67 KB, text/plain)
2008-12-17 21:00 UTC, Alexey Charkov
Details
The latest in-tree libcap.so.1 ebuilds (libcap.tar.bz2,4.29 KB, application/octet-stream)
2008-12-17 21:15 UTC, Alexey Charkov
Details
The main app ebuild with ~sys-libs/libcap-1.10 dependency (virtualbox-bin-2.1.0.ebuild,5.69 KB, text/plain)
2008-12-17 21:27 UTC, Alexey Charkov
Details
Updated kernel module sources (vbox-kernel-module-src-2.1.0.tar.bz2,456.38 KB, application/octet-stream)
2008-12-18 16:59 UTC, Frank Szczerba
Details
Updated kernel module ebuild (virtualbox-modules-2.1.0.ebuild,1.25 KB, text/plain)
2008-12-18 17:00 UTC, Frank Szczerba
Details
build.log (build.log,81.50 KB, text/plain)
2009-01-01 07:28 UTC, Joseph Mulloy
Details
emerge --info (emerge.info,3.96 KB, text/plain)
2009-01-01 07:29 UTC, Joseph Mulloy
Details
The -ose ebuild with patch for kernel headers 2.6.28 (virtualbox-ose-2.1.0.ebuild,6.76 KB, text/plain)
2009-01-02 18:50 UTC, Raphaël Vinot
Details
Patch for kernel headers 2.6.28 (virtualbox-ose-2.1.0-kernel-headers-2.6.28.patch,487 bytes, patch)
2009-01-02 18:51 UTC, Raphaël Vinot
Details | Diff
patch for virtualbox-modules-2.1.0 to build against kernel 2.6.29_rc* (kernel-2.6.29-fix.patch,795 bytes, patch)
2009-01-19 17:42 UTC, Ben Kohler
Details | Diff
EAPI 2 version of virtualbox-ose-additions ebuild (virtualbox-ose-additions-2.1.2.ebuild,759 bytes, text/plain)
2009-01-27 10:00 UTC, Bernard Cafarelli
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Maxim Grechkin 2008-12-17 17:35:22 UTC
Please bump virtualbox to version 2.1 available at virtualbox.org

Reproducible: Always

Steps to Reproduce:
Comment 1 Norberto Bensa 2008-12-17 18:04:27 UTC
Thanks for the ebuild :)
Comment 2 Maxim Grechkin 2008-12-17 19:35:53 UTC
If I had any idea how to do it, I will make it and place to the local overlay and never file any bug ) I believe that it is needed to separate modules from the source code to make virtualbox-modules ebuild and it is not that straightforward.
Comment 3 Alexey Charkov 2008-12-17 20:58:10 UTC
Created attachment 175641 [details]
The kernel module ebuild
Comment 4 Alexey Charkov 2008-12-17 21:00:36 UTC
Created attachment 175642 [details]
The main app ebuild

This is just a modified 2.0.6 version. The application installs but tries to load libcap.so.1, which is in =sys-libs/libcap-1* (already out of tree). Symlinking libcap.so (from the second version) to libcap.so.1 does not help (invalid ELF header). Suggestions welcome.
Comment 5 Alexey Charkov 2008-12-17 21:15:32 UTC
Created attachment 175648 [details]
The latest in-tree libcap.so.1 ebuilds

These ones were checked out from CVS and correspond to the latest state available. Unpack .tar.bz2 to your local overlay and enjoy.
Comment 6 Alexey Charkov 2008-12-17 21:27:00 UTC
Created attachment 175650 [details]
The main app ebuild with ~sys-libs/libcap-1.10 dependency

Now it works. However, Portage issues a bunch of security alerts upon installations regarding setuid binaries and DT_PATHs - I did not look into those yet.
Comment 7 Li Yanrui 2008-12-18 09:06:11 UTC
(In reply to comment #4)
> Created an attachment (id=175642) [edit]
> The main app ebuild
> 
> This is just a modified 2.0.6 version. The application installs but tries to
> load libcap.so.1, which is in =sys-libs/libcap-1* (already out of tree).
> Symlinking libcap.so (from the second version) to libcap.so.1 does not help
> (invalid ELF header). Suggestions welcome.
> 

I tried to use '/usr/lib/libcap.so.1' to symlink '/lib/libcap.so' and it can work.
Comment 8 Maxim Grechkin 2008-12-18 12:15:24 UTC
This virtualbox-modules package lacks vboxnetflt kernel driver, and I think it should be better to use vboxdrv.sh initscript provided by virtualbox. 
Comment 9 Lars Wendler (Polynomial-C) gentoo-dev 2008-12-18 12:30:13 UTC
Reassigning/CCing to maintainers.
Comment 10 Lars Wendler (Polynomial-C) gentoo-dev 2008-12-18 12:30:19 UTC
*** Bug 251456 has been marked as a duplicate of this bug. ***
Comment 11 Frank Szczerba 2008-12-18 15:18:42 UTC
I can confirm that creating a symlink from /usr/lib/libcap.so.1 to ../../lib/libcap.so works. Perhaps this should be a bug against the libcap package?
Comment 12 Frank Szczerba 2008-12-18 16:23:12 UTC
The kernel modules package needs VBOX_WITH_NETFLT for bridging to work. This is new in 2.1.0.
Comment 13 Frank Szczerba 2008-12-18 16:23:57 UTC
(In reply to comment #12)
> The kernel modules package needs VBOX_WITH_NETFLT for bridging to work. This is
> new in 2.1.0.
> 

And apparently was already mentioned. I'm going to go back to being useless now.
Comment 14 Frank Szczerba 2008-12-18 16:59:37 UTC
Created attachment 175752 [details]
Updated kernel module sources

Include the new vboxnetflt driver in the kernel module sources
Comment 15 Frank Szczerba 2008-12-18 17:00:49 UTC
Created attachment 175754 [details]
Updated kernel module ebuild

Add the vboxnetflt driver to the module ebuild
Comment 16 Frank Szczerba 2008-12-18 17:01:53 UTC
The attached virtualbox-modules ebuild and sources seem to work for me.
Comment 17 Thomas Capricelli 2008-12-19 16:06:14 UTC
does 2.1.0 behaves better with recent gcc ? i remember previous version of virtualbox could not be compiled with gcc 4.3.x.
Comment 18 Maxim Grechkin 2008-12-19 16:24:10 UTC
I emerged attached ebuilds using gcc 4.3.2 with no problems
Comment 19 Alessio Cassibba (X-Drum) 2008-12-19 17:13:24 UTC
updated ebuilds for virtualbox-2.1.0 in overlay[1]
please consider it as a work in progress,
especially the virtualbox-bin ebuild, blocked by the missing libcap.so.1
(1.x ebuilds for sys-libs/libcap were dropped) see bug #251654.

As usual please report any problem found on ebuild in overlay here,
i will test gcc 4.3.x asap too.

[1] http://overlays.gentoo.org/dev/jokey
Comment 20 Jeremy Sermersheim 2008-12-19 18:39:38 UTC
(In reply to comment #11)
> I can confirm that creating a symlink from /usr/lib/libcap.so.1 to
> ../../lib/libcap.so works. Perhaps this should be a bug against the libcap
> package?
> 

+1 on amd64...host interface networking works beautifully...good work
Comment 21 Frank Szczerba 2008-12-20 00:05:59 UTC
(In reply to comment #17)
> does 2.1.0 behaves better with recent gcc ? i remember previous version of
> virtualbox could not be compiled with gcc 4.3.x.
> 
 (In reply to comment #18)
> I emerged attached ebuilds using gcc 4.3.2 with no problems
> 

The attached ebuilds are just for -bin. I didn't update the -ose ebuild (and haven't gotten around to gcc 4.3.2 yet anyway).
Comment 22 Maxim Grechkin 2008-12-20 07:52:32 UTC
At least modules build correctly with 4.3.2 :)
Comment 23 Petteri Räty (RETIRED) gentoo-dev 2008-12-20 21:22:44 UTC
(In reply to comment #11)
> I can confirm that creating a symlink from /usr/lib/libcap.so.1 to
> ../../lib/libcap.so works. Perhaps this should be a bug against the libcap
> package?
> 

No. This is very much wrong. If you want to know why search for information how how share library versioning works on Linux. If virtualbox-bin uses only APIs that haven't changed between the SONAME bump then we could consider using for example LD_PRELOAD in wrapper scripts to load libcap.so.2
Comment 24 Frank Szczerba 2008-12-22 16:54:27 UTC
Virtualbox only uses 2 entry points to libcap (cap_set_proc() and cap_from_text()), and those are ABI-compatible between libcap1 and libcap2 (cap_from_text() takes a const char * and returns an opaque object, which is passed to cap_set_proc()).

I think it makes more sense to fix this with an LD_PRELOAD in the virtualbox-bin package rather than re-introduce libcap1 (which apparently uses insecure kernel interfaces, thus the move to libcap2).
Comment 25 Frank Szczerba 2008-12-22 17:24:15 UTC
Is it possible to use LD_PRELOAD to replace libcap.so.1 with libcap.so.2? I thought from comment #23 that it was, but I can't seem to find a way to make it work. Maybe this is because the VirtualBox executable is setuid?

What did work for me was moving the (evil) symlink into /opt/VirtualBox, which at least means other apps will not be affected by it.

(In reply to comment #23)
> (In reply to comment #11)
> > I can confirm that creating a symlink from /usr/lib/libcap.so.1 to
> > ../../lib/libcap.so works. Perhaps this should be a bug against the libcap
> > package?
> > 
> 
> No. This is very much wrong. If you want to know why search for information how
> how share library versioning works on Linux. If virtualbox-bin uses only APIs
> that haven't changed between the SONAME bump then we could consider using for
> example LD_PRELOAD in wrapper scripts to load libcap.so.2
> 

Comment 26 Petteri Räty (RETIRED) gentoo-dev 2008-12-22 21:33:49 UTC
(In reply to comment #25)
> Is it possible to use LD_PRELOAD to replace libcap.so.1 with libcap.so.2? I
> thought from comment #23 that it was, but I can't seem to find a way to make it
> work. Maybe this is because the VirtualBox executable is setuid?
> 

Yeah setuid would mean that libcap.so.2 would also need to be marked setuid. See
http://bugs.gentoo.org/show_bug.cgi?id=86844#c3
Comment 27 Petteri Räty (RETIRED) gentoo-dev 2008-12-22 21:34:50 UTC
I would say just to make the symlink in /opt/VirtualBox.
Comment 28 James Glanville 2008-12-23 10:45:07 UTC
As the section of the libcap ABI necessary has remained constant, I found that hexediting the VirtualBox binary replacing "libcap.so.1" with "libcap.so.2" works perfectly. This has the advantage of not requiring any horrible symlinks or LD_PRELOAD. I'm sure this could be done with sed or dd, but I was not sure of the syntax for binary files so i used a gui hex editor. Would this be a suitable fix to get virtualbox-bin-2.1.0 in the portage tree?
Comment 29 Dennis Schridde 2008-12-23 12:58:57 UTC
I guess not, if you can prove that the license permits it.
And I doubt sed is suitable for editing binary data, but I'm no expert.
Comment 30 jannis 2008-12-23 13:43:52 UTC
Here on amd64 I don't see a problem with libcap. I only have one /usr/lib64/libcap.so (installed from sys-libs/libcap-2.15) and VirtualBox builds and runs fine (using the ebuilds from jokey's overlay) without any symlinks, PRELOADs or wrappers.
Comment 31 Alessio Cassibba (X-Drum) 2008-12-23 14:02:09 UTC
(In reply to comment #28)
[..]
(In reply to comment #29)
[..]

clearly the (PUEL) license *doesn't allow* this kind of modifications
to the binaries, maybe is possibile in order to grant interoperability (but IANAL), personally i don't think that messing with copyrighted binaries and stuff is a great idea (and we have to respect licenses).

For the record libcap-2.x is ok for virtualbox-ose (ebuild in overlay)
but again, please stop to force the use of libcap.so.2 over libcap.so.1,
this was remarked here and in bug #251654

upstream is aware of this issue (maybe in the next release this should be solved) but for now we have only two solutions:
- reinstate the "bad" sys-libs/libcap-1.10-r11 ebuild.

- drop a prebuild libcap.so.1 library with the package in /opt/VirtualBox,
but in this scenario how to handle possible problems with the distributed libcap.so.1?
Comment 32 Alessio Cassibba (X-Drum) 2008-12-23 14:11:23 UTC
(In reply to comment #30)
> Here on amd64 I don't see a problem with libcap. I only have one
> /usr/lib64/libcap.so (installed from sys-libs/libcap-2.15) and VirtualBox
> builds and runs fine (using the ebuilds from jokey's overlay) without any
> symlinks, PRELOADs or wrappers.
> 

starting wiht virtualbox 2.1.0 sys-libs/libcap is used only for host icmp support see:
(http://www.virtualbox.org/ticket/2859 comments #5 and #7 by frank)

so no issues with libcap-2.x in virtualbox-ose, the problem discussed here
is related to virtualbox-bin package and the link done by upstream against libcap-1.x.
Comment 33 Frank Szczerba 2008-12-23 19:09:09 UTC
(In reply to comment #32)
> (In reply to comment #30)
> > Here on amd64 I don't see a problem with libcap. I only have one
> > /usr/lib64/libcap.so (installed from sys-libs/libcap-2.15) and VirtualBox
> > builds and runs fine (using the ebuilds from jokey's overlay) without any
> > symlinks, PRELOADs or wrappers.
> > 
> 
> starting wiht virtualbox 2.1.0 sys-libs/libcap is used only for host icmp
> support see:
> (http://www.virtualbox.org/ticket/2859 comments #5 and #7 by frank)
> 
> so no issues with libcap-2.x in virtualbox-ose, the problem discussed here
> is related to virtualbox-bin package and the link done by upstream against
> libcap-1.x.
> 

As I mentioned in comment #24, the only libcap entry points used are ABI-compatible between libcap1 and libcap2. I don't think hex-editing the application is a good idea, and I don't think reinstating a library that uses a deprecated kernel API is a particularly good idea either.

If a private-to-VirtualBox-bin symlink for libcap is not acceptable to the devs, I will write a private libcap.so.1 library that just shims the two used calls over to libcap.so.2 and add that to the build. Would that be an acceptable solution?
Comment 34 Alessio Cassibba (X-Drum) 2008-12-25 18:12:29 UTC
update:

i was able to build and test with sys-devel/gcc-4.3.2 the following packages:
app-emulation/virtualbox-ose-2.1.0
app-emulation/virtualbox-guest-additions-2.1.0
x11-drivers/xf86-input-virtualbox-2.1.0
x11-drivers/xf86-video-virtualbox-2.1.0

so i removed the gcc-4.3.x checks in configure for this ebuilds,
please note that possible build failures caused by gcc should not
be reported to upstream (gcc-4.3.x is not supported at this time, 
an elog warning was added to the ebuilds)

updated ebuilds are on jokey's overlay

(In reply to comment #19)
[..]
> 
> As usual please report any problem found on ebuild in overlay here,
> i will test gcc 4.3.x asap too.
> 
> [1] http://overlays.gentoo.org/dev/jokey
> 

Comment 35 Joseph Mulloy 2008-12-31 18:48:34 UTC
So if this doesn't affect virtualbox-ose can it be bumped?
Comment 36 Joseph Mulloy 2008-12-31 18:49:53 UTC
(In reply to comment #35)
> So if this doesn't affect virtualbox-ose can it be bumped?
> 

Please ignore this comment. Just saw the comment above.
Comment 37 Joseph Mulloy 2009-01-01 07:27:34 UTC
Tried to install from the ebuild in the overlay with gcc 4.1.2, I used gcc profile to switch from 4.3. I'll attach the log and emerge info. I would have created a new bug but I know this is in an overlay and not the official tree, I can open a separate bug if you wish. I'm running my system from ~x86 and I have the jokey and kde-testing overlays installed.
Comment 38 Joseph Mulloy 2009-01-01 07:28:25 UTC
Created attachment 176982 [details]
build.log

virtualbox-ose-2.1.0 build log
Comment 39 Joseph Mulloy 2009-01-01 07:29:39 UTC
Created attachment 176984 [details]
emerge --info
Comment 40 Raphaël Vinot 2009-01-02 18:20:02 UTC
(In reply to comment #38)
> Created an attachment (id=176982) [edit]
> build.log
> 
> virtualbox-ose-2.1.0 build log
> 

solution in there : http://www.virtualbox.org/ticket/2936
Comment 41 Raphaël Vinot 2009-01-02 18:50:56 UTC
Created attachment 177131 [details]
The -ose ebuild with patch for kernel headers 2.6.28
Comment 42 Raphaël Vinot 2009-01-02 18:51:52 UTC
Created attachment 177132 [details, diff]
Patch for kernel headers 2.6.28
Comment 43 Joseph Mulloy 2009-01-02 18:55:52 UTC
(In reply to comment #40)
> (In reply to comment #38)
> > Created an attachment (id=176982) [edit]
> > build.log
> > 
> > virtualbox-ose-2.1.0 build log
> > 
> 
> solution in there : http://www.virtualbox.org/ticket/2936
> 

Thanks, I added the patch to the ebuild on my local machine and I put the patch
in app-emulation/virtualbox-ose/files. I added another epatch line after the
one for the gcc 4.3 patch. I'll let you guys know if it works and I'll upload
my changes to Bugzilla.

A few questions, is there anyway to check for a specific version of a package
in the ebuild, specifically which version of sys-kernel/linux-headers is
installed? This bug only affects 2.6.28 but then again if the patch doesn't
hurt on older versions then we can just always apply it. Also what the prefered
way of providing the patch, it's only 478 bytes so it's small enough that it
wouldn't be a big deal to leave it in the tree. The only thing is that right
now there is no credit given to whoever wrote the patch. Right now I've named
the file virtualbox-ose-2.1.0-linux-2.6.28.patch, better suggestions would be
appreciated.

Thanks
Comment 44 Joseph Mulloy 2009-01-02 18:56:45 UTC
(In reply to comment #41)
> Created an attachment (id=177131) [edit]
> The -ose ebuild with patch for kernel headers 2.6.28
> 

Looks like you beat me to it.

I just got it to compile by editing things by hand.
Comment 45 Alessio Cassibba (X-Drum) 2009-01-03 19:09:26 UTC
(In reply to comment #44)
> (In reply to comment #41)
> > Created an attachment (id=177131) [edit]
> > The -ose ebuild with patch for kernel headers 2.6.28
> > 
> 
> Looks like you beat me to it.
> 
> I just got it to compile by editing things by hand.
> 

patch added and updated the ebuild in overlay,
thanks.
Comment 46 Alon Bar-Lev 2009-01-07 11:24:41 UTC
Can you please reconsider removing the hal dependency?

From bug#197541 comment#10 it looks like it is not required anymore.

I have hal on my system only due to VirtualBox...
Comment 47 Michael Palimaka (kensington) gentoo-dev 2009-01-07 17:56:51 UTC
*** Bug 254130 has been marked as a duplicate of this bug. ***
Comment 48 Adam Hawkins 2009-01-14 09:32:28 UTC
Markus, I am having a problem with your ebuild.  I've posted on the forums here: http://forums.gentoo.org/viewtopic-p-5387327.html#5387327

Thanks for the work.
Comment 49 Jeroen Roovers gentoo-dev 2009-01-14 17:19:50 UTC
*** Bug 254949 has been marked as a duplicate of this bug. ***
Comment 50 Alessio Cassibba (X-Drum) 2009-01-14 19:51:11 UTC
(In reply to comment #48)
> Markus, I am having a problem with your ebuild.  I've posted on the forums
> here: http://forums.gentoo.org/viewtopic-p-5387327.html#5387327
> 
> Thanks for the work.
> 

Hi, please be sure that:

a) if you are using the overlay via layman (and the overlay is updated to a recent version)
b) if you are using the overlay ebuilds via a subversion checkout
(eg: svn co https://overlays.gentoo.org/svn/dev/jokey/trunk) be sure 
to update the "checkouted" ebuilds with the command:
svn up

Note: that the the file virtualbox-ose-2-localconfig is necessary for a correct build, so that file *must* exists on your overlay

Note2: i answered to this on forums.gentoo.org too
Comment 51 Ben Kohler gentoo-dev 2009-01-19 17:42:15 UTC
Created attachment 179006 [details, diff]
patch for virtualbox-modules-2.1.0 to build against kernel 2.6.29_rc*

This patch should allow virtualbox-modules to build against 2.6.29_rc kernels, pulled it from virtualbox's forums.  Works for me.
Comment 52 Neil Cathey 2009-01-22 07:49:27 UTC
It seems that VirtualBox 2.1.2 has been released.  I noticed this among the ChangeLog:

Linux hosts: don’t depend on libcap1 anymore (bug #2859)

According to the referenced bug, "In r15871 I've changed the code to use direct kernel calls to prevent the dependency to libcap." So it appears it no longer needs libcap at all.
Comment 53 Neil Cathey 2009-01-22 07:52:08 UTC
Whoops, it turned that bug number into a Gentoo bug.  Here's the link for those who don't want to dig for it:

http://www.virtualbox.org/ticket/2859

And here's the ChangeLog:

http://www.virtualbox.org/wiki/Changelog
Comment 54 Alon Bar-Lev 2009-01-22 13:22:58 UTC
What about removing the hal forced dependency?
Comment 55 Ryan 2009-01-22 14:27:33 UTC
Thought I would go ahead and update virtualbox 2.1.2 has been released, lots of bug fixes. Fixes for linux hosts are:
# Linux hosts: don’t depend on libcap1 anymore (bug #2859)
# Linux hosts: compile fixes for 2.6.29-rc1
# Linux hosts: don’t drop any capability if the VM was started by root (2.1.0 regression) 

Full changlog http://www.virtualbox.org/wiki/Changelog

Testing the install with the 2.0.6 ebuild (I'm using bin not ose)
Comment 56 Ryan 2009-01-22 14:51:51 UTC
First off, sorry for the double announcement. I was excited and didn't think to check if it was already there.

Second, why are we installing modules from a custom package hosted by a dev. It seems the modules are inside the Virtualbox.tar.bz2 inside the run file. Would it make sense to just use this same file instead of re-downloading material we've already downloaded once?
Comment 57 Ryan 2009-01-22 15:01:33 UTC
Well the ebuilds from the tree (-bin-2.0.6) work. Just renamed them and update the build number.

I pulled the modules out of the downloaded file from Sun and they seem to be working.

I still get the duplicate IP error with my XP Host
Comment 58 Norberto Bensa 2009-01-22 18:58:12 UTC
(In reply to comment #57)

> I still get the duplicate IP error with my XP Host

I've seen that in a kubuntu host running xp as guest at work. Network is basically 20 linux boxes and lots and lots and lots of w2k and wxp. 

Is that a know bug in VB? Is there a bugzilla entry?

Comment 59 Ryan 2009-01-22 22:27:18 UTC
yep http://www.virtualbox.org/ticket/2757
Comment 60 Alessio Cassibba (X-Drum) 2009-01-22 23:43:52 UTC
(In reply to comment #56)
(In reply to comment #55)
(In reply to comment #53)
(In reply to comment #52)
Well, i noticed the new release too (i follow the official mailing list),  please be patient :) 
[ and please 2.1.2 issues request should be filed to a separate bug ]


(In reply to comment #54)
> What about removing the hal forced dependency?
> 

in 2.1.0 was impossible for virtualbox-ose (several build errors)
let's see with this release (2.1.2)


Comment 61 Chris Slycord 2009-01-25 18:30:07 UTC
2.1.12 has been released
And it seems like the libcap issue has been fixed now.
http://www.virtualbox.org/ticket/2859
They changed it to use direct kernel calls instead of using libcap.
Comment 62 Alessio Cassibba (X-Drum) 2009-01-25 21:30:08 UTC
(In reply to comment #61)
> 2.1.12 has been released
> And it seems like the libcap issue has been fixed now.
> http://www.virtualbox.org/ticket/2859
> They changed it to use direct kernel calls instead of using libcap.
> 
Yes, see comment #55 and comment #60 on this bug report :)

2.1.2 Version bump bug #256265
Comment 63 Alessio Cassibba (X-Drum) 2009-01-27 00:25:04 UTC
(In reply to comment #60)
> (In reply to comment #54)
> > What about removing the hal forced dependency?
> > 
> 
> in 2.1.0 was impossible for virtualbox-ose (several build errors)
> let's see with this release (2.1.2)
> 

Update,
the hal dependency is now optional and controlled via USE flag
for virtualbox-ose-{2.1.0, 2.1.2}, i reported the problem upstream 
and the issue with dbus was fixed in svn (Changeset 16225).

Updated ebuilds in overlay
Comment 64 Bernard Cafarelli gentoo-dev 2009-01-27 10:00:54 UTC
Created attachment 179871 [details]
EAPI 2 version of virtualbox-ose-additions ebuild

This ebuild uses SRC_URI arrow (EAPI 2 feature) to download source file, to remove fetch restriction
Comment 65 Sven 2009-01-27 10:55:44 UTC
(In reply to comment #64)
> Created an attachment (id=179871) [edit]
> EAPI 2 version of virtualbox-ose-additions ebuild
> 
> This ebuild uses SRC_URI arrow (EAPI 2 feature) to download source file, to
> remove fetch restriction

And it's not even necessary to use the arrow. Since the EAPI 2 versions of portage, portage will (and has to!) extract the filename from the URL to pass it as the "-O" parameter to wget which fixes the problem that was caused by http redirects and portage not taking control of the output filename.
Comment 66 Alessio Cassibba (X-Drum) 2009-01-28 23:35:23 UTC
(In reply to comment #64)
[..]

(In reply to comment #65)
> (In reply to comment #64)
[..]

Done, all the ebuilds were converted to EAPI=2 (only 1.6.6 was excluded)
updates available on jokey's overlay as usual

Comment 67 Thomas Scheller 2009-02-04 09:15:11 UTC
(In reply to comment #66)

The overlay works fine for me. Is there something special that should be tested and reported here?
Comment 68 Norberto Bensa 2009-02-04 13:45:45 UTC
(In reply to comment #67)
> Is there something special that should be tested
> and reported here?

Hm. Make it respect the Qt theme? I'm currently using KDE4.2, with Oxygen style, but VirtualBox uses some of those very ugly stock Qt themes.



Comment 69 Andrew Udvare 2009-02-18 15:38:41 UTC
When will version 2.1.4 (ose) be making it into the main Portage tree?
Comment 70 Dennis Schridde 2009-02-18 15:46:44 UTC
Even more interesting: When will 2.1.4 appear in the overlay? ;)

To someone with powers: I think there are some duplicates: bug #256265, bug #256327, bug #259123
Comment 71 Aniruddha 2009-02-18 16:43:01 UTC
*** Bug 259123 has been marked as a duplicate of this bug. ***
Comment 72 Bartek 'Paczesiowa' Cwiklowski 2009-02-20 02:09:26 UTC
ebuild in jokey overlay for virtualbox-ose (with eapi2) has dependency for "media-libs/libsdl:[X]" which doesn't work with paludis, and they say: "because that's not a valid slotname"
Comment 73 Justin Lecher gentoo-dev 2009-02-20 10:16:43 UTC
(In reply to comment #72)
> ebuild in jokey overlay for virtualbox-ose (with eapi2) has dependency for
> "media-libs/libsdl:[X]" which doesn't work with paludis, and they say: "because
> that's not a valid slotname"
> 

It will probably say the same if you use portage, because

media-libs/libsdl:${SLOT}    defines the slot and
media-libs/libsdl[${USE}]    forces the usage of a USE flags. Looks like there was something mixed up.
Comment 74 Alessio Cassibba (X-Drum) 2009-02-22 14:39:14 UTC
(In reply to comment #70)
> Even more interesting: When will 2.1.4 appear in the overlay? ;)
> 
yes, in overlay since 02/21/09 :)

> To someone with powers: I think there are some duplicates: bug #256265, bug
> #256327, bug #259123

(In reply to comment #72)
(In reply to comment #73) 
yes the use dependency was messed, just fixed in overlay, thanks!

Comment 75 Aniruddha 2009-02-22 16:36:56 UTC
(In reply to comment #74)
> (In reply to comment #70)
> > Even more interesting: When will 2.1.4 appear in the overlay? ;)
> > 
> yes, in overlay since 02/21/09 :)
> 

Where do I find info about the jockey overlay?
Comment 76 Alessio Cassibba (X-Drum) 2009-02-22 16:39:55 UTC
(In reply to comment #75)
> Where do I find info about the jockey overlay?

as reported previously here the url is: http://overlays.gentoo.org/dev/jokey
if you nedd informations about overlays and their usage in gentoo please
refer to: http://www.gentoo.org/proj/en/overlays/userguide.xml
 

Comment 77 Sebastian Beßler 2009-03-02 16:00:40 UTC
The filename has changed. 
The ebuild tries to download VirtualBox-2.1.4-42893-Linux_amd64.run but there is now only VirtualBox-2.1.4-43001-Linux_amd64.run on the Server 
Comment 78 Alessio Cassibba (X-Drum) 2009-03-02 22:49:51 UTC
(In reply to comment #77)
> The filename has changed. 
> The ebuild tries to download VirtualBox-2.1.4-42893-Linux_amd64.run but there
> is now only VirtualBox-2.1.4-43001-Linux_amd64.run on the Server 
> 

yup, as reported on bug 259688 (comment 21, 22, 23) upstream silently
updated tarballs and binaries, just updated Manifests and ebuild on 
jokey's overlay
Comment 79 Thomas Scheller 2009-03-02 23:15:21 UTC
Get the following error message after update to latest version of jokey overlay:

2009-03-03 00:04:26 (1,04 MB/s) - `/usr/portage/distfiles/VirtualBox-2.1.4-OSE.tar.bz2' saved [47896348/47896348]

 * VirtualBox-2.1.4-OSE.tar.bz2 RMD160 SHA1 SHA256 size ;-) ...                                                                                                   [ ok ]
 * checking ebuild checksums ;-) ...                                                                                                                              [ ok ]
 * checking auxfile checksums ;-) ...                                                                                                                             [ ok ]
 * checking miscfile checksums ;-) ...                                                                                                                            [ ok ]
>>> Unpacking source...
>>> Unpacking VirtualBox-2.1.4-OSE.tar.bz2 to /var/tmp/portage/app-emulation/virtualbox-ose-2.1.4/work
>>> Source unpacked in /var/tmp/portage/app-emulation/virtualbox-ose-2.1.4/work
>>> Configuring source in /var/tmp/portage/app-emulation/virtualbox-ose-2.1.4/work/VirtualBox-2.1.4_OSE ...
Checking for environment: Determined build machine: linux.amd64, target machine: linux.amd64, OK.
Checking for kBuild: found, OK.
Checking for gcc: found version 4.1.2, OK.
Checking for as86: found version 0.16.17, OK.
Checking for bcc: found version 0.16.17, OK.
Checking for iasl: found version 20060912, OK.
Checking for xslt: found, OK.
Checking for pthread: found, OK.
Checking for libxml2: found version 2.7.2, OK.
Checking for libxslt: found version 1.1.24, OK.
Checking for libIDL: found version 0.8.12, OK.
Checking for zlib: found version 1.2.3, OK.
Checking for libpng: found version 1.2.35, OK.
Checking for SDL: found version 1.2.13, OK.
Checking for X libraries: found, OK.
Checking for Xcursor: found, OK.
Checking for Qt4: found version 4.4.2, OK.
Checking for Qt4 devtools: found version 4.4.2, OK.
Checking for python support: found version 2.5.2, OK.
Checking for static stc++ library: found, OK.
Checking for ALSA: found version 1.0.17, OK.
Checking for libcap library: found, OK.
Checking for compiler.h: compiler.h not found, OK.
Checking for 32-bit support: OK.
Checking for GSOAP compiler: found, OK.

Successfully generated '/var/tmp/portage/app-emulation/virtualbox-ose-2.1.4/work/VirtualBox-2.1.4_OSE/AutoConfig.kmk' and '/var/tmp/portage/app-emulation/virtualbox-ose-2.1.4/work/VirtualBox-2.1.4_OSE/env.sh'.
Source '/var/tmp/portage/app-emulation/virtualbox-ose-2.1.4/work/VirtualBox-2.1.4_OSE/env.sh' once before you start to build VBox:

  source /var/tmp/portage/app-emulation/virtualbox-ose-2.1.4/work/VirtualBox-2.1.4_OSE/env.sh
  kmk

To compile the kernel module, do:

  cd ./out/linux.amd64/release/bin/src/vboxdrv
  make


  +++ WARNING +++ WARNING +++ WARNING +++ WARNING +++ WARNING +++ WARNING +++
  Hardening is enabled which means that the VBox binaries will not run from
  the binary directory. The binaries have to be installed suid root and some
  more prerequisites have to be fulfilled which is normally done by installing
  the final package. For development, the hardening feature can be disabled
  by specifying the --disable-hardening parameter. Please never disable that
  feature for the final distribution!
  +++ WARNING +++ WARNING +++ WARNING +++ WARNING +++ WARNING +++ WARNING +++

Enjoy!
>>> Source configured.
>>> Compiling source in /var/tmp/portage/app-emulation/virtualbox-ose-2.1.4/work/VirtualBox-2.1.4_OSE ...
kmk -j4 TOOL_GCC3_CC=x86_64-pc-linux-gnu-gcc TOOL_GCC3_CXX=x86_64-pc-linux-gnu-g++ TOOL_GCC3_AS=x86_64-pc-linux-gnu-gcc TOOL_GCC3_AR=x86_64-pc-linux-gnu-ar TOOL_GCC3_LD=x86_64-pc-linux-gnu-g++ TOOL_GCC3_LD_SYSMOD=x86_64-pc-linux-gnu-ld 'TOOL_GCC3_CFLAGS= -pipe -O2' 'TOOL_GCC3_CXXFLAGS= -pipe -O2' TOOL_YASM_AS=yasm KBUILD_PATH=/var/tmp/portage/app-emulation/virtualbox-ose-2.1.4/work/VirtualBox-2.1.4_OSE/kBuild all 
Config.kmk:1564: /var/tmp/portage/app-emulation/virtualbox-ose-2.1.4/work/VirtualBox-2.1.4_OSE/out/linux.amd64/release/GCCConfig.kmk: No such file or directory
Config.kmk:2511: *** extraneous `endif'.  Stop.
 * 
 * ERROR: app-emulation/virtualbox-ose-2.1.4 failed.
 * Call stack:
 *               ebuild.sh, line   49:  Called src_compile
 *             environment, line 3516:  Called die
 * The specific snippet of code:
 *       MAKE="kmk" emake TOOL_GCC3_CC="$(tc-getCC)" TOOL_GCC3_CXX="$(tc-getCXX)" TOOL_GCC3_AS="$(tc-getCC)" TOOL_GCC3_AR="$(tc-getAR)" TOOL_GCC3_LD="$(tc-getCXX)" TOOL_GCC3_LD_SYSMOD="$(tc-getLD)" TOOL_GCC3_CFLAGS="${CFLAGS}" TOOL_GCC3_CXXFLAGS="${CXXFLAGS}" TOOL_YASM_AS=yasm KBUILD_PATH="${S}/kBuild" all || die "kmk failed"
 *  The die message:
 *   kmk failed
 * 
 * If you need support, post the topmost build error, and the call stack if relevant.
 * A complete build log is located at '/var/tmp/portage/app-emulation/virtualbox-ose-2.1.4/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/app-emulation/virtualbox-ose-2.1.4/temp/environment'.
 * This ebuild is from a repository named 'dev-jokey'
 * 
Comment 80 Alessio Cassibba (X-Drum) 2009-03-02 23:17:22 UTC
(In reply to comment #79)
> Get the following error message after update to latest version of jokey
> overlay:
well, what to say :)
the new OSE tarball (for virtualbox-ose-2.1.4) has a typo in Config.kmk
just commited on overlay a fixed ebuild, please update!
Comment 81 Thomas Scheller 2009-03-03 09:06:59 UTC
Works fine, tested with Kernel 2.6.29-rc6
Comment 82 Markus Ullmann (RETIRED) gentoo-dev 2009-03-11 09:25:18 UTC
Fix applied in CVS
Comment 83 Gian 2009-03-15 11:13:17 UTC
(In reply to comment #82)
> Fix applied in CVS
> 

Somehow, I still get the error described in Comment #79. 
Comment 84 Miles V. 2009-03-16 13:38:55 UTC
I too am still getting the message in #79
Comment 85 Grigorij Ivanow 2009-03-16 21:02:39 UTC
***extraneous `endif' still showing, as in comment #79. I've just synced with main portage tree. No overlays installed.
Comment 86 Olivier Crete (RETIRED) gentoo-dev 2009-03-17 00:01:57 UTC
Your fix is wrong. Here it doesn't work with it, but it works without it..
Comment 87 Alessio Cassibba (X-Drum) 2009-03-17 18:19:59 UTC
(In reply to comment #86)
> Your fix is wrong. Here it doesn't work with it, but it works without it..
> 

well just to sort out things (again):

Virtualbox-2.1.4-OSE changed tarball name 2 times,
the first time the was needed
the second time the patch wasnt since upstream fixed the offending endif

So i dont know why it was included again in the current ebuild, i already
asked to a developer to solve this, and since this bug is closed
please refer to bug 262271 for this issue