[Bug 285] Review Request: VirtualBox-OSE - A general-purpose full virtualizer for PC hardware

[RPM Fusion Bugzilla]

http://bugzilla.rpmfusion.org/show_bug.cgi?id=285





--- Comment #4 from Lubomir Rintel <lkundrak at 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.