Sign Up
Log In
Log In
or
Sign Up
Places
All Projects
Status Monitor
Collapse sidebar
Virtualization:Variants
qemu
README.PACKAGING
Overview
Repositories
Revisions
Requests
Users
Attributes
Meta
File README.PACKAGING of Package qemu
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 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 a script as described below. If you are not modifying any patches or their order, but just need to update the spec file from a changed template, run 'bash ./update_git.sh refresh'. If the set of patches is being modified, including their order, you will want to first run 'bash ./update_git.sh pkg2git', which makes the current package patch queue available in a local git branch named frombundle (see config.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 branch which corresponds to this release (eg: opensuse-4.2), using 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 bundles.tar.xz file, as well as the spec and patch files. The maintainer and automation use another workflow mode dealing with packaging the latest upstream qemu. See 'LATEST' references in the scripts for details. ** SPECIAL NOTE ABOUT CURRENT STATUS *** The current status as of 31 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 workflow is still a work in progress. If it isn't working right, please contact Bruce Rogers <brogers@suse.com>. *** END SPECIAL NOTE *** Additional Notes: 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 "References:" 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 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 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
Locations
Projects
Search
Status Monitor
Help
OpenBuildService.org
Documentation
API Documentation
Code of Conduct
Contact
Support
@OBShq
Terms
openSUSE Build Service is sponsored by
The Open Build Service is an
openSUSE project
.
Sign Up
Log In
Places
Places
All Projects
Status Monitor