2019-09-12 17:54:03 +02:00
|
|
|
The qemu package, and derived packages have a special maintenance workflow in
|
|
|
|
|
order to support git based patching. Please use it in order to have changes
|
|
|
|
|
you make be acceptable to the package maintainers.
|
|
|
|
|
|
|
|
|
|
The qemu.spec file is generated from a qemu.spec.in template, so to make changes
|
2019-10-10 04:07:57 +02:00
|
|
|
to the spec file (besides the script generated patch references), you'll need to
|
|
|
|
|
edit the template, not the spec file. The spec file patch references are inserted
|
|
|
|
|
by scripts, which are described below.
|
2019-09-12 17:54:03 +02:00
|
|
|
|
|
|
|
|
If you are not modifying any patches or their order, but just need to update the
|
2019-09-28 17:46:49 +02:00
|
|
|
spec file from a changed template, run 'bash ./update_git.sh refresh'.
|
2019-09-12 17:54:03 +02:00
|
|
|
|
|
|
|
|
If the set of patches is being modified, including their order, you will want to
|
2019-10-10 04:07:57 +02:00
|
|
|
first run 'bash ./update_git.sh pkg2git', which makes the current package patch
|
|
|
|
|
queue available in a local git branch named frombundle (see confi.sh for the
|
|
|
|
|
locations). This set of patches comes from a "bundle of git bundles", the
|
|
|
|
|
bundles.tar.xz file, which is included as a package source file. You will then
|
|
|
|
|
create an altered patch queue in the $GIT_BRANCH branch ( again,see config.sh),
|
|
|
|
|
and use the frombundle branch as the starting point for your changes (eg perhaps
|
|
|
|
|
start by doing git reset --hard frombundle, then cherry-pick upstream patches
|
|
|
|
|
from there). Once you have the patch queue ready to go run 'bash ./update_git.sh
|
|
|
|
|
git2pkg' which updates the bunndles.tar.xz file, as well as the spec and patch
|
|
|
|
|
files.
|
2019-09-12 17:54:03 +02:00
|
|
|
|
|
|
|
|
** SPECIAL NOTE ABOUT CURRENT STATUS ***
|
2019-10-10 04:07:57 +02:00
|
|
|
The current status as of 03 Oct 2019 is that for this incarnation of qemu
|
|
|
|
|
packaging, the previous workflow which relied on the patches being in a shared
|
|
|
|
|
git repo on github or gitlab is no longer supported. This new bundle based
|
|
|
|
|
workflos is still a work in progress.
|
2019-09-12 17:54:03 +02:00
|
|
|
If it isn't working right, please contact Bruce Rogers <brogers@suse.com>.
|
|
|
|
|
|
|
|
|
|
Also note that qemu now takes advantage of the MultiBuild feature of the Build
|
|
|
|
|
Service. No longer do the qemu-linux-user and qemu-testsuite packages have build
|
|
|
|
|
service links to the qemu package, but instead are generated straight from the
|
|
|
|
|
main qemu spec file via the use of a _multibuild file which identifies those
|
|
|
|
|
package variants.
|
|
|
|
|
- Bruce Rogers
|
|
|
|
|
*** END SPECIAL NOTE ***
|
|
|
|
|
|
2019-10-10 04:07:57 +02:00
|
|
|
Additional Notes:
|
|
|
|
|
|
2019-09-12 17:54:03 +02:00
|
|
|
Patches which are from an upstream git repo should have the commit id recorded
|
|
|
|
|
just below the Subject line (after a blank line) as follows:
|
|
|
|
|
|
|
|
|
|
Git-commit: <40-char-sha-id>
|
|
|
|
|
|
|
|
|
|
If a patch is anticipated to be shortly included in upstream repo, mark that
|
|
|
|
|
fact by doing the above with 40 0's, which will flag it as needing to be updated
|
|
|
|
|
in the near future.
|
|
|
|
|
|
|
|
|
|
Bug or feature tracking identifiers should also be added to the patch similarly,
|
|
|
|
|
using the abbreviations identified here:
|
|
|
|
|
http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines#Current_set_of_abbreviations
|
|
|
|
|
using the "Reference:" tag, with multiple entries comma separated.
|
|
|
|
|
|
|
|
|
|
The ability to provide a conditional inclusion of a patch (eg based on
|
|
|
|
|
architecture, is provided by using the "Include-If:" tag similarly, as follows:
|
|
|
|
|
|
|
|
|
|
Include-If: %ifarch aarch64
|
|
|
|
|
|
|
|
|
|
This will cause the patch application in the spec file to be done as follows:
|
|
|
|
|
%ifarch aarch64
|
|
|
|
|
%patch0013 -p1
|
|
|
|
|
%endif
|
|
|
|
|
|
2019-09-18 10:58:50 +02:00
|
|
|
A trick worth noting is, if a given git tracked patch is to be applied in a way
|
|
|
|
|
that can't be done in the normal patching section of the spec file, you can still
|
2019-09-12 17:54:03 +02:00
|
|
|
include the patch, and use it by name with the patch program elsewhere in the
|
|
|
|
|
spec file by doing something such as:
|
|
|
|
|
Include-If: %if 0%{?patch-possibly-applied-elsewhere}
|
|
|
|
|
(this variable will remain undefined in the spec file) And then elsewhere in spec
|
|
|
|
|
file, the actual patch (eg specially-handled-change.patch) is referenced as, eg:
|
|
|
|
|
|
|
|
|
|
patch -p1 < %_sourcedir/specially-handled-change.patch
|
