Please bump virtualbox to version 2.1 available at virtualbox.org Reproducible: Always Steps to Reproduce:
Thanks for the ebuild :)
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.
Created attachment 175641 [details] The kernel module ebuild
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.
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.
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.
(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.
This virtualbox-modules package lacks vboxnetflt kernel driver, and I think it should be better to use vboxdrv.sh initscript provided by virtualbox.
Reassigning/CCing to maintainers.
*** Bug 251456 has been marked as a duplicate of this bug. ***
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?
The kernel modules package needs VBOX_WITH_NETFLT for bridging to work. This is new in 2.1.0.
(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.
Created attachment 175752 [details] Updated kernel module sources Include the new vboxnetflt driver in the kernel module sources
Created attachment 175754 [details] Updated kernel module ebuild Add the vboxnetflt driver to the module ebuild
The attached virtualbox-modules ebuild and sources seem to work for me.
does 2.1.0 behaves better with recent gcc ? i remember previous version of virtualbox could not be compiled with gcc 4.3.x.
I emerged attached ebuilds using gcc 4.3.2 with no problems
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
(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
(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).
At least modules build correctly with 4.3.2 :)
(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
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).
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 >
(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
I would say just to make the symlink in /opt/VirtualBox.
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?
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.
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.
(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?
(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.
(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?
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 >
So if this doesn't affect virtualbox-ose can it be bumped?
(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.
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.
Created attachment 176982 [details] build.log virtualbox-ose-2.1.0 build log
Created attachment 176984 [details] emerge --info
(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
Created attachment 177131 [details] The -ose ebuild with patch for kernel headers 2.6.28
Created attachment 177132 [details, diff] Patch for kernel headers 2.6.28
(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
(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.
(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.
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...
*** Bug 254130 has been marked as a duplicate of this bug. ***
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.
*** Bug 254949 has been marked as a duplicate of this bug. ***
(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
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.
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.
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
What about removing the hal forced dependency?
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)
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?
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
(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?
yep http://www.virtualbox.org/ticket/2757
(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)
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.
(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
(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
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
(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.
(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
(In reply to comment #66) The overlay works fine for me. Is there something special that should be tested and reported here?
(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.
When will version 2.1.4 (ose) be making it into the main Portage tree?
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
*** Bug 259123 has been marked as a duplicate of this bug. ***
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"
(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.
(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!
(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?
(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
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
(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
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' *
(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!
Works fine, tested with Kernel 2.6.29-rc6
Fix applied in CVS
(In reply to comment #82) > Fix applied in CVS > Somehow, I still get the error described in Comment #79.
I too am still getting the message in #79
***extraneous `endif' still showing, as in comment #79. I've just synced with main portage tree. No overlays installed.
Your fix is wrong. Here it doesn't work with it, but it works without it..
(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
