forked from pool/virtualbox
f82e2df3e8
- Fix screen resizing under Wayland (boo#1194126 and boo#1194126)
New files are "VirtualBox-5.2.10-xclient.patch", "vboxclient.desktop",
"vboxclient.service", and "vboxservice.service"
The fixes were derived from looking at many hundreds of Web pages, and
by looking at the code in Fedora35. Thanks to RedHat for the help.
OBS-URL: https://build.opensuse.org/request/show/994409
OBS-URL: https://build.opensuse.org/package/show/Virtualization/virtualbox?expand=0&rev=650
129 lines
9.0 KiB
Plaintext
129 lines
9.0 KiB
Plaintext
Instructions for building the VirtualBox project
|
||
|
||
Although it is possible to modify a project at the openSUSE Build System (OBS),
|
||
I have found it to be more convenient to use the various osc commands to create a
|
||
local copy, edit it on my own computer to fix any problems, and then push the result
|
||
to OBS.
|
||
|
||
You will need a login account at OBS. This account is also used to login at openSUSE's
|
||
bugzilla, etc. Those credentials are also used by osc whose package must also be
|
||
installed.
|
||
|
||
A. Create a new sub-project:
|
||
1. Branch the package:
|
||
The sources for Tumbleweed and the Leap releases have been merges, thus
|
||
development work can be concentrates on TW. To branch VB for Tumbleweed,
|
||
osc branch Virtualization virtualbox
|
||
2. Checkout the package using the "osc co" command listed
|
||
|
||
B. For the first time, test Build the project:
|
||
1. Use "osc build" to build. This step is rather compute intensive and
|
||
takes about an hour on my Toshiba laptop with a dual-core Intel Core i7 CPU
|
||
with hyper-threading, 12 GB RAM, and an SSD. This build will create all the
|
||
VirtualBox packages except the kernel modules. To build them use "osc build -M kmp",
|
||
which takes a lot less time. The split was made to reduce the load on OBS.
|
||
Now, a kernel change only requires rebuild of the modules, not the entire package.
|
||
2. The build results are stored in the /var/tmp/build-root tree. These files
|
||
can occupy a lot of disc space, particularly when one builds several flavors.
|
||
To keep from running out of space on the / partition, I mount /var/tmp on
|
||
a separate partition. In general, about 25 GB is required for each flavor,
|
||
thus the disk usabe can approach 100 GB. If you have plenty of headroom in /,
|
||
you can skip this separate partition.
|
||
3. Special flavors:
|
||
When a new kernel is released, there may be several API changes that affect
|
||
builds of the kernel modules used by VirtualBox. In Factory, the project that
|
||
contains the latest kernels is "Kernel-HEAD-standard". To run a test build with
|
||
this kernel, use the command " osc build --alternative-project Kernel:HEAD standard".
|
||
Note: The syntax of this step has changed throughout the years. If it fails, ask
|
||
how to do it on the openSUSE Factory mailing list at opensuse-factory@opensuse.org.
|
||
When switching between kernel projects, use of the "--clean" switch is advised,
|
||
otherwise strange "missing library" messages will result.
|
||
4. On occasion, there may be breakage in the build when there is an update of
|
||
python or Qt. Use the "--alternative-project=<xxx>" switch to force usage of
|
||
the revised component. You will need to ask at factory@lists.opensuse.org to
|
||
get the proper profect name.
|
||
|
||
C. Steps to take with a new release:
|
||
1. When Oracle releases a new version, you will need to download the new tarball
|
||
from https://download.virtualbox.org/virtualbox/. While downloading the file, I
|
||
also get the new UserManual.pdf. I use the wget utility, but the browser could
|
||
be used.
|
||
2. openSUSE makes some changes to the tarballi, which are done with the command
|
||
bash ./virtualbox-patch-source.sh <name of tarball just downloaded>
|
||
This script unpacks the tar file, removes Windows and Mac host code from the file,
|
||
and recreates the tar file with "patched" in its name. Any further modifications
|
||
are made by patches that are applied during the build process. Do NOT make any
|
||
further changes to the tar file.
|
||
3. Edit the "Version" line near the start of virtualbox.spec to select the new version.
|
||
4. Use "osc rm <old_tarball-name>" and "osc add <new_tarball_name>" to get the
|
||
new file into osc. The local build will work without these changes, but the remote
|
||
operations with OBS will fail.
|
||
5. VirtualBox at openSUSE is a multi-build package consisting of virtualbox-kmp and
|
||
the rest of virtualbox. The former builds in about 20% of the time needed for the
|
||
latter, thus it is best to start with the kmp part.
|
||
6. The usual problems are as follows:
|
||
a. Fixing for kernel API changes are incorporated in a new release, thus our patch
|
||
is obsolete.
|
||
b. Oracle has revised their code such that one of the patches needed by openSUSE
|
||
fails to apply.
|
||
c. There are kernel API changes that break the building of the kmp part of VB.
|
||
5. When fixing kernel API changes, keep in mind that Oracle will be 2-3 months behind
|
||
your needs; however, they will eventually include the necessary changes in their
|
||
distribution. If you find something that you do not know how to fix, you could file
|
||
a bug tracker at https://www.virtualbox.org/wiki/Bugtracker. Note that previous
|
||
reports have gotten the response "We do not support kernel X.Y" - a really helpful
|
||
response. To be able to back out your changes, create a new patch file for the
|
||
updates. An OBS or osc build will unpack the "patched" tarball and apply the patches.
|
||
To help in the creation of such patches, it is my practice to untar the tarball and
|
||
use quilt to create the necessary patch, refresh it, and then copy it back into the
|
||
main directory. At that point it can be added into the spec file. The utility
|
||
wiggle is useful in fixing patches that will not apply.
|
||
6. Once the kmp modules, and the main part of VirtualBox are building correctly with
|
||
osc, use 'osc status' to indicate the file changes. Anything with a "?" as its status
|
||
is a new file that needs to be resolved. If these files are not added to the project,
|
||
they will not be uploaded to OBS. You should also remove any files made obsolete
|
||
because Oracle caught up with kernel API changes. At this point, the new release
|
||
should be tested by adding the directory
|
||
/var/tmp/build-root/.../home/abuild/rpmbuild/RPMS/x86_64
|
||
to the list of repositories, and updating virtualbox from that new repository. These
|
||
packages will not be signed, thus you will get a warning that can be ignored. Be sure
|
||
to install virtualbox-host-source, as well as kernel-default-devel and kernel-devel
|
||
for the kernel you are running. After loading the updated packages, then run
|
||
'sudo /lib/sbin/vboxconfig' to build and install the kernel modules.
|
||
7. The new code can now be tested. Usually, the tests will not show any problems;
|
||
however, there was a version where Windows 7 failed to boot because of a virtual
|
||
BIOS change. With kernel 5.18, there was a major bug where the FPU was not being
|
||
saved. The symptoms ranged from application crashes in a Linux VM to a full virtual
|
||
machine crash in a Windows 10 VM. The patch for this problem was provided by Oracle,
|
||
only a few days before kernel 5.18.1 was released and added to Tumbleweed. Obviously,
|
||
both Windows and Linux systems should be tested to ensure that screen resizing,
|
||
bidirectional clipboard, and shared folders work with no crashes.
|
||
8. Once the new release is tested and 'osc status' is clean, it is time to update the
|
||
changes file using the 'osc vc' command. I copy and paste the changes listed in
|
||
the Oracle release notes to the new entry and add references to any bugzilla entries.
|
||
In this section, it is essential that you list files that are deleted or added. It is
|
||
not necessary to mention the tarball change - it is implied.
|
||
9. Now it is time to send the new material to OBS using the 'osc ci' command. The
|
||
material in the new section usually appears as the commit message. If not, copy it
|
||
from the .changes file. Committing new material will trigger builds at OBS. The
|
||
status of them can be seen with the 'osc r' command. Once the builds are successful,
|
||
they should be submitted using the 'osc sr' for Tumbleweed. One peculiarity of the
|
||
factory releases is that they require a review, even for your own changes. A few
|
||
minutes after an ‘osc sr’ command, you will need to log into OBS and check your
|
||
tasks for “Outgoing Requests”. From there, you will be able to submit a review.
|
||
10. After VirtualBox is completed for Tumbleweed, and building OK on the various Leap
|
||
versions at OBS, you can branch the various Leap versions with the command
|
||
osc branch openSUSE:Leap:15.X:Update virtualbox
|
||
It is not necessary to check out the code as creating the directory that will
|
||
be used. If it already exists on your system, delete all files in that directory.
|
||
Then copy all the files from the Tumbleweed source into the Leap directory. To
|
||
syncronize your system wuth OBS, do an "osc update". At this point, you will
|
||
need to repeat the "osc rm" and "osc add" steps to update the version of the
|
||
tarball. After that, make sure that "osc status" is clean. At that point, update
|
||
the package at OBS with "osc ci". When "osc r" shows that the build has completed,
|
||
use "osc mr" to submit it to the project. For the update projects, no review by
|
||
the maintainer is requied.
|
||
11. When a new Leap release is in a pre-release state, updated VB releases can be
|
||
sent to that project from OBS.
|
||
|