[Bug 285] Review Request: VirtualBox-OSE - A general-purpose full virtualizer for PC hardware
http://bugzilla.rpmfusion.org/show_bug.cgi?id=285
--- Comment #4 from Lubomir Rintel <lkundrak(a)v3.sk> 2009-01-11 13:36:33 ---
(In reply to comment #2)
Created an attachment (id=67)
-->
(http://bugzilla.rpmfusion.org/attachment.cgi?id=67) [details]
Small improvements for VirtualBox-OSE-kmod.spec
Just a few notes (I just wanted to look at the kmod):
- I could not rebuild VirtualBox-OSE-2.1.0-1.fc10.src.rpm on F10, x86_64:
Fixed.
- why isn't the src for the kernel-module part of the
VirtualBox-OSE-kmod
package? That how it's done for all the other kmods. But maybe doing what you
might have some benefits as well (smaller srpms mainly).
Smaller srpms were not a motivation. Honestly, I was only aware of drawbacks :)
Such as needlessly rebuilding both packages when in need of patching the kmod
(which happened now).
However, the buildable module source tree is generated during the build of the
main package. It can't be easily decoupled from the main package build, so
solving it this way seemed sane to me.
- find a few small changes (untested, obviously) for the kmod spec
file in
attached patch; some of them are cosmetic, others fix a corner case where only
the akmod package gets build
Thanks, Applied.
(In reply to comment #3)
* For the first thing, this stuff apparently wants a 32-bit toolchain
on
x86_64. That sucks. x86_64 packages should be really x86_64, not mixed 32/64
bits. What 32-bit stuff is this trying to build? Support for 32-bit guests? Or
just host stuff they were too lazy to port?
It's just tests. I disabled the check and 32bit tests in 64bit build, but am
not very happy about it. I'm wondering if mock used by plague would allow us to
depend on glibc-devel.i386 and let us install it?
* I'd suggest BRing qt4-devel instead of qt-devel >= 1:4, the
virtual Provides
exists for a reason. (It might also allow building against qt4 on EL if they
drop support for Qt 3, though the problem is that EL5 includes an ancient qt4
(4.2), so EPEL can't ship anything newer due to the policy not to replace RHEL
packages. And replacing EL5's qt4 in RPM Fusion isn't allowed either, for the
same reason.) (Unfortunately, qt3-devel was added only during the transition,
so you'll still have to use qt-devel < 1:4 to get Qt 3 for EL.)
Done.
New package (built on Fedora 10/x86_64, unfortunately I did not have an
opportunity to run it). Apart from the issues pointed out above it fixes a
vboxnetflt module kernel panic (triggerable only on EL-5).
Main package:
SPEC: http://v3.sk/~lkundrak/SPECS/VirtualBox-OSE.spec
SRPM: http://v3.sk/~lkundrak/SRPMS/VirtualBox-OSE-2.1.0-2.fc10.src.rpm
Kernel module:
SPEC: http://v3.sk/~lkundrak/SPECS/VirtualBox-OSE-kmod.spec
SRPM: http://v3.sk/~lkundrak/SRPMS/VirtualBox-OSE-kmod-2.1.0-2.fc10.src.rpm
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.