Accepting request 731688 from home:bfrogers:branches:Virtualization

Tweak cross compiler used based. Also clean up commentary in scripts.

OBS-URL: https://build.opensuse.org/request/show/731688
OBS-URL: https://build.opensuse.org/package/show/Virtualization/qemu?expand=0&rev=488
This commit is contained in:
Bruce Rogers 2019-09-18 08:58:50 +00:00 committed by Git OBS Bridge
parent 64435eabdc
commit 3ab58a2291
6 changed files with 32 additions and 14 deletions

View File

@ -15,11 +15,11 @@ first run pkg2git.sh, in order to get the current patch queue made available in
a local git branch named frombundle. (qemu packaging now includes a "bundle of a local git branch named frombundle. (qemu packaging now includes a "bundle of
git bundles" stored as a package source file, which contains the "git version" git bundles" stored as a package source file, which contains the "git version"
of the package patches.) You will create an altered patch queue in the of the package patches.) You will create an altered patch queue in the
$GIT_BRANCH branch (see config.h for actual name), and use the frombundle branch $GIT_BRANCH branch (see config.sh for actual name), and use the frombundle branch
as a starting point (eg perhaps start by doing git reset frombundle, then cherry as a starting point (eg perhaps start by doing git reset --hard frombundle, then
-pick upstream patches from there). Once you have the patch queue ready to go cherry-pick upstream patches from there). Once you have the patch queue ready to
run git2pkg.sh to update the bundle of bundles (bundles.tsr.xz file) as well as go run git2pkg.sh to update the bundle of bundles (bundles.tsr.xz file) as well
the spec and patch files. as the spec and patch files.
Additional Notes: Additional Notes:
@ -62,8 +62,8 @@ This will cause the patch application in the spec file to be done as follows:
%patch0013 -p1 %patch0013 -p1
%endif %endif
A track worth noting is, if a given git tracked patch is to be applied in a way 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 specfile, you can still 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 include the patch, and use it by name with the patch program elsewhere in the
spec file by doing something such as: spec file by doing something such as:
Include-If: %if 0%{?patch-possibly-applied-elsewhere} Include-If: %if 0%{?patch-possibly-applied-elsewhere}

View File

@ -9,8 +9,13 @@
# That way we can easily rebase against the next stable release # That way we can easily rebase against the next stable release
# when it comes. # when it comes.
# !!!!!! WARNING - our use of the sort order of our globbing will # TODO:
# get the patches out of order once they go over 9999!!!!!!!!!!! # * don't re-create bundles that are the same, and if no change
# don't re-create the bunde-of-bundles
# * somehow for the LATEST case, keep track of the patches which
# have come and gone until we apply the whole set to the changelog
# * also when that update comes, include the Referece: references as
# being included into the update
set -e set -e

View File

@ -2,7 +2,7 @@
# #
# This script simply does some basic checks on the bundle tarball # This script simply does some basic checks on the bundle tarball
# NYI: report if the required base commit isn't there - they may need to fetch the latest from upstream # TODO: report if the required base commit isn't there - they may need to fetch the latest from upstream
set -e set -e

View File

@ -61,10 +61,7 @@ LOCAL_REPO_MAP=(
~/git/qemu-edk2-openssl-krb5 ~/git/qemu-edk2-openssl-krb5
~/git/qemu-edk2-openssl-pyca-cryptography ~/git/qemu-edk2-openssl-pyca-cryptography
) )
# Should we instead simply have this stored in bundle somehow? (perhaps have an ordering number, and
# store a patchrange value in this file. Unclear what is best - perhaps once we do a full scripting
# solution the right choice will fall out - what makes sense as to how the project gets initialized
# what is easiest to create (and how) to get packaging working with this workflow?
PATCH_PATH_MAP=( PATCH_PATH_MAP=(
"" ""
"roms/seabios/" "roms/seabios/"

View File

@ -249,9 +249,17 @@ BuildRequires: cross-arm-gcc7
%ifnarch %{ix86} x86_64 %ifnarch %{ix86} x86_64
# We must cross-compile on non-x86* # We must cross-compile on non-x86*
BuildRequires: cross-i386-binutils BuildRequires: cross-i386-binutils
%if 0%{?is_opensuse}
BuildRequires: cross-i386-gcc9 BuildRequires: cross-i386-gcc9
%else
BuildRequires: cross-i386-gcc7
%endif
BuildRequires: cross-x86_64-binutils BuildRequires: cross-x86_64-binutils
%if 0%{?is_opensuse}
BuildRequires: cross-x86_64-gcc9 BuildRequires: cross-x86_64-gcc9
%else
BuildRequires: cross-x86_64-gcc7
%endif
%endif %endif
%endif %endif
BuildRequires: curl-devel BuildRequires: curl-devel

View File

@ -179,9 +179,17 @@ BuildRequires: cross-arm-gcc7
%ifnarch %{ix86} x86_64 %ifnarch %{ix86} x86_64
# We must cross-compile on non-x86* # We must cross-compile on non-x86*
BuildRequires: cross-i386-binutils BuildRequires: cross-i386-binutils
%if 0%{?is_opensuse}
BuildRequires: cross-i386-gcc9 BuildRequires: cross-i386-gcc9
%else
BuildRequires: cross-i386-gcc7
%endif
BuildRequires: cross-x86_64-binutils BuildRequires: cross-x86_64-binutils
%if 0%{?is_opensuse}
BuildRequires: cross-x86_64-gcc9 BuildRequires: cross-x86_64-gcc9
%else
BuildRequires: cross-x86_64-gcc7
%endif
%endif %endif
%endif %endif
BuildRequires: curl-devel BuildRequires: curl-devel