[PATCH 0/5] raisin: Miscelaneous improvements

[PATCH 0/5] raisin: Miscelaneous improvements

[George Dunlap]

Miscellaneous improvements

George Dunlap (5):
  raisin: Handle aliases for packages, add pciutils-dev / libpci-dev
    alias
  raisin: Detect systemd
  raisin: Allow iasl to alias acpica-tools, unify Fedora and CentOS deps
    for xen
  raisin: Change update/release parsing OSes
  raisin: Add XEN_CONFIG_EXTRA to config file

 components/qemu_traditional |  2 +-
 components/xen              | 18 ++++++++++++++----
 configs/config-4.5          |  4 ++++
 configs/config-4.6          |  4 ++++
 configs/config-master       |  4 ++++
 lib/common-functions.sh     | 33 +++++++++++++++++++++++++--------
 6 files changed, 52 insertions(+), 13 deletions(-)

-- 
2.1.4

[PATCH 1/5] raisin: Handle aliases for packages, add pciutils-dev / libpci-dev alias

[George Dunlap]

It's not uncommon for packages to be renamed, and for package managers
to know the translation from old packages to new packages.  For
example:

# apt-get install pciutils-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'libpci-dev' instead of 'pciutils-dev'
libpci-dev is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

So the command succeeds, but the subsequent package check still fails,
cince "pciutils-dev" wasn't actually installed.  This means that even
after running "install-builddep", "build" will prompt you to install the
old package every time.

Allow components to specify known aliases for a given package by
speficying a a|b|c.  Check-package will check consecutively for a, b,
and c; if it finds any of them, it will stop looking and install
nothing.  If it finds nothing, it will add the first package to the
missing_packages list.

Assuming that package managers are backwards-compatible, components
should put the oldest known package first for maximum compatibility.

Also add such an alias for pciutils-dev|libpci-dev in qemu_traditional

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
---
 components/qemu_traditional |  2 +-
 lib/common-functions.sh     | 25 ++++++++++++++++++++-----
 2 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/components/qemu_traditional b/components/qemu_traditional
index 3150c3e..d73c6b8 100644
--- a/components/qemu_traditional
+++ b/components/qemu_traditional
@@ -10,7 +10,7 @@ function qemu_traditional_skip() {
 }
 
 function qemu_traditional_check_package() {
-    local DEP_Debian_common="build-essential zlib1g-dev pciutils-dev pkg-config \
+    local DEP_Debian_common="build-essential zlib1g-dev pciutils-dev|libpci-dev pkg-config \
               libncurses5-dev"
     local DEP_Debian_x86_32="$DEP_Debian_common"
     local DEP_Debian_x86_64="$DEP_Debian_common"
diff --git a/lib/common-functions.sh b/lib/common-functions.sh
index 03642ae..a389054 100644
--- a/lib/common-functions.sh
+++ b/lib/common-functions.sh
@@ -233,14 +233,29 @@ function _install-package-unknown() {
 
 # Modifies inherited variable "missing"
 function check-package() {
+    local OIFS=${IFS}
+    local p
+    local x
+    
     for p in $*
     do
-        if ! _check-package-${PKGTYPE} $p
-        then
-            missing+=("$p")
-        fi
+	local found=false
+	IFS='|'
+	for x in $p
+	do
+            if _check-package-${PKGTYPE} $x
+            then
+		found=true
+            fi
+	done
+	IFS="$OIFS"
+	if ! $found
+	then
+	    # Add the first of the aliases, on the assumption that the package
+	    # manager will be backwards-compatible
+	    missing+=("${p%%|*}")
+	fi
     done
-
 }
 
 function install-package() {
-- 
2.1.4

Re: [PATCH 1/5] raisin: Handle aliases for packages, add pciutils-dev / libpci-dev alias

[Stefano Stabellini]

On Wed, 14 Oct 2015, George Dunlap wrote:
> It's not uncommon for packages to be renamed, and for package managers
> to know the translation from old packages to new packages.  For
> example:
> 
> # apt-get install pciutils-dev
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Note, selecting 'libpci-dev' instead of 'pciutils-dev'
> libpci-dev is already the newest version.
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> 
> So the command succeeds, but the subsequent package check still fails,
> cince "pciutils-dev" wasn't actually installed.  This means that even
> after running "install-builddep", "build" will prompt you to install the
> old package every time.
> 
> Allow components to specify known aliases for a given package by
> speficying a a|b|c.  Check-package will check consecutively for a, b,
> and c; if it finds any of them, it will stop looking and install
> nothing.  If it finds nothing, it will add the first package to the
> missing_packages list.
> 
> Assuming that package managers are backwards-compatible, components
> should put the oldest known package first for maximum compatibility.
> 
> Also add such an alias for pciutils-dev|libpci-dev in qemu_traditional
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

Thanks for the patch, this is very useful and I like the way it is done.

Please use spaces for indentation.


>  components/qemu_traditional |  2 +-
>  lib/common-functions.sh     | 25 ++++++++++++++++++++-----
>  2 files changed, 21 insertions(+), 6 deletions(-)
> 
> diff --git a/components/qemu_traditional b/components/qemu_traditional
> index 3150c3e..d73c6b8 100644
> --- a/components/qemu_traditional
> +++ b/components/qemu_traditional
> @@ -10,7 +10,7 @@ function qemu_traditional_skip() {
>  }
>  
>  function qemu_traditional_check_package() {
> -    local DEP_Debian_common="build-essential zlib1g-dev pciutils-dev pkg-config \
> +    local DEP_Debian_common="build-essential zlib1g-dev pciutils-dev|libpci-dev pkg-config \
>                libncurses5-dev"
>      local DEP_Debian_x86_32="$DEP_Debian_common"
>      local DEP_Debian_x86_64="$DEP_Debian_common"
> diff --git a/lib/common-functions.sh b/lib/common-functions.sh
> index 03642ae..a389054 100644
> --- a/lib/common-functions.sh
> +++ b/lib/common-functions.sh
> @@ -233,14 +233,29 @@ function _install-package-unknown() {
>  
>  # Modifies inherited variable "missing"
>  function check-package() {
> +    local OIFS=${IFS}

local OIFS="$IFS"


> +    local p
> +    local x
> +    
>      for p in $*
>      do
> -        if ! _check-package-${PKGTYPE} $p
> -        then
> -            missing+=("$p")
> -        fi
> +	local found=false
> +	IFS='|'
> +	for x in $p
> +	do
> +            if _check-package-${PKGTYPE} $x
> +            then
> +		found=true
> +            fi
> +	done
> +	IFS="$OIFS"
> +	if ! $found
> +	then
> +	    # Add the first of the aliases, on the assumption that the package
> +	    # manager will be backwards-compatible
> +	    missing+=("${p%%|*}")
> +	fi
>      done
> -
>  }

Everything else is fine

Re: [PATCH 1/5] raisin: Handle aliases for packages, add pciutils-dev / libpci-dev alias

[George Dunlap]

On 16/10/15 14:37, Stefano Stabellini wrote:
> On Wed, 14 Oct 2015, George Dunlap wrote:
>> It's not uncommon for packages to be renamed, and for package managers
>> to know the translation from old packages to new packages.  For
>> example:
>>
>> # apt-get install pciutils-dev
>> Reading package lists... Done
>> Building dependency tree
>> Reading state information... Done
>> Note, selecting 'libpci-dev' instead of 'pciutils-dev'
>> libpci-dev is already the newest version.
>> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>>
>> So the command succeeds, but the subsequent package check still fails,
>> cince "pciutils-dev" wasn't actually installed.  This means that even
>> after running "install-builddep", "build" will prompt you to install the
>> old package every time.
>>
>> Allow components to specify known aliases for a given package by
>> speficying a a|b|c.  Check-package will check consecutively for a, b,
>> and c; if it finds any of them, it will stop looking and install
>> nothing.  If it finds nothing, it will add the first package to the
>> missing_packages list.
>>
>> Assuming that package managers are backwards-compatible, components
>> should put the oldest known package first for maximum compatibility.
>>
>> Also add such an alias for pciutils-dev|libpci-dev in qemu_traditional
>>
>> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> Thanks for the patch, this is very useful and I like the way it is done.
> 
> Please use spaces for indentation.

Oops -- used to emacs just doing that for me automatically.

> 
> 
>>  components/qemu_traditional |  2 +-
>>  lib/common-functions.sh     | 25 ++++++++++++++++++++-----
>>  2 files changed, 21 insertions(+), 6 deletions(-)
>>
>> diff --git a/components/qemu_traditional b/components/qemu_traditional
>> index 3150c3e..d73c6b8 100644
>> --- a/components/qemu_traditional
>> +++ b/components/qemu_traditional
>> @@ -10,7 +10,7 @@ function qemu_traditional_skip() {
>>  }
>>  
>>  function qemu_traditional_check_package() {
>> -    local DEP_Debian_common="build-essential zlib1g-dev pciutils-dev pkg-config \
>> +    local DEP_Debian_common="build-essential zlib1g-dev pciutils-dev|libpci-dev pkg-config \
>>                libncurses5-dev"
>>      local DEP_Debian_x86_32="$DEP_Debian_common"
>>      local DEP_Debian_x86_64="$DEP_Debian_common"
>> diff --git a/lib/common-functions.sh b/lib/common-functions.sh
>> index 03642ae..a389054 100644
>> --- a/lib/common-functions.sh
>> +++ b/lib/common-functions.sh
>> @@ -233,14 +233,29 @@ function _install-package-unknown() {
>>  
>>  # Modifies inherited variable "missing"
>>  function check-package() {
>> +    local OIFS=${IFS}
> 
> local OIFS="$IFS"

Ack

> 
> 
>> +    local p
>> +    local x
>> +    
>>      for p in $*
>>      do
>> -        if ! _check-package-${PKGTYPE} $p
>> -        then
>> -            missing+=("$p")
>> -        fi
>> +	local found=false
>> +	IFS='|'
>> +	for x in $p
>> +	do
>> +            if _check-package-${PKGTYPE} $x
>> +            then
>> +		found=true
>> +            fi
>> +	done
>> +	IFS="$OIFS"
>> +	if ! $found
>> +	then
>> +	    # Add the first of the aliases, on the assumption that the package
>> +	    # manager will be backwards-compatible
>> +	    missing+=("${p%%|*}")
>> +	fi
>>      done
>> -
>>  }
> 
> Everything else is fine

Cool, thanks.

 -George

[PATCH 2/5] raisin: Detect systemd

[George Dunlap]

Add systemd development libraries if we detect systemd present on the system

Signed-off-by: George Dunlap <george.dunlap@citrix.com>
---
 components/xen | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/components/xen b/components/xen
index 090cceb..93ed288 100644
--- a/components/xen
+++ b/components/xen
@@ -8,6 +8,11 @@ function xen_check_package() {
     local DEP_Debian_common="build-essential python-dev gettext uuid-dev   \
              libncurses5-dev libyajl-dev libaio-dev pkg-config libglib2.0-dev  \
              libssl-dev libpixman-1-dev bridge-utils wget"
+
+    if [[ -e "/usr/lib/systemd" ]]
+    then
+	DEP_Debian_common="$DEP_Debian_common libsystemd-daemon-dev"
+    fi
     local DEP_Debian_x86_32="$DEP_Debian_common bcc iasl bin86 texinfo"
     local DEP_Debian_x86_64="$DEP_Debian_x86_32 libc6-dev-i386"
     local DEP_Debian_arm32="$DEP_Debian_common libfdt-dev"
@@ -16,6 +21,10 @@ function xen_check_package() {
     local DEP_Fedora_common="make gcc python-devel gettext libuuid-devel   \
              ncurses-devel glib2-devel libaio-devel openssl-devel yajl-devel   \
              patch pixman-devel glibc-devel bridge-utils grub2 wget tar bzip2"
+    if [[ -e "/usr/lib/systemd" ]]
+    then
+	DEP_Fedora_common="$DEP_Fedora_common systemd-devel|systemd-container-devel"
+    fi
     local DEP_Fedora_x86_32="$DEP_Fedora_common dev86 acpica-tools texinfo"
     local DEP_Fedora_x86_64="$DEP_Fedora_x86_32 glibc-devel.i686"
 
@@ -23,6 +32,7 @@ function xen_check_package() {
     local DEP_CentOS_x86_32="$DEP_CentOS_common dev86 texinfo iasl"
     local DEP_CentOS_x86_64="$DEP_CentOS_x86_32 glibc-devel.i686"
 
+
     verbose_echo Checking Xen dependencies
     eval check-package \$DEP_"$DISTRO"_"$RAISIN_ARCH"
 }
-- 
2.1.4

Re: [PATCH 2/5] raisin: Detect systemd

[George Dunlap]

On 14/10/15 17:21, George Dunlap wrote:
> Add systemd development libraries if we detect systemd present on the system
> 
> Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Sorry, meant to add a comment here...

> ---
>  components/xen | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/components/xen b/components/xen
> index 090cceb..93ed288 100644
> --- a/components/xen
> +++ b/components/xen
> @@ -8,6 +8,11 @@ function xen_check_package() {
>      local DEP_Debian_common="build-essential python-dev gettext uuid-dev   \
>               libncurses5-dev libyajl-dev libaio-dev pkg-config libglib2.0-dev  \
>               libssl-dev libpixman-1-dev bridge-utils wget"
> +
> +    if [[ -e "/usr/lib/systemd" ]]
> +    then
> +	DEP_Debian_common="$DEP_Debian_common libsystemd-daemon-dev"
> +    fi
>      local DEP_Debian_x86_32="$DEP_Debian_common bcc iasl bin86 texinfo"
>      local DEP_Debian_x86_64="$DEP_Debian_x86_32 libc6-dev-i386"
>      local DEP_Debian_arm32="$DEP_Debian_common libfdt-dev"
> @@ -16,6 +21,10 @@ function xen_check_package() {
>      local DEP_Fedora_common="make gcc python-devel gettext libuuid-devel   \
>               ncurses-devel glib2-devel libaio-devel openssl-devel yajl-devel   \
>               patch pixman-devel glibc-devel bridge-utils grub2 wget tar bzip2"
> +    if [[ -e "/usr/lib/systemd" ]]
> +    then
> +	DEP_Fedora_common="$DEP_Fedora_common systemd-devel|systemd-container-devel"
> +    fi

This is a bit dodgy, as basically CentOS (and I think Fedora) have
separate packages for systemd when inside a container vs on real
hardware.  But unfortunately I'm not sure there's a way to make yum
smart enough to know, "Gee, I'm in a container, I should run systemd
instead".

Having the "alias" like this allows the user to work around it by
manually installing systemd-container-devel.  It's not great though,
because there's still nothing to prompt the user to install the correct
package.

Also...

>      local DEP_Fedora_x86_32="$DEP_Fedora_common dev86 acpica-tools texinfo"
>      local DEP_Fedora_x86_64="$DEP_Fedora_x86_32 glibc-devel.i686"
>  
> @@ -23,6 +32,7 @@ function xen_check_package() {
>      local DEP_CentOS_x86_32="$DEP_CentOS_common dev86 texinfo iasl"
>      local DEP_CentOS_x86_64="$DEP_CentOS_x86_32 glibc-devel.i686"
>  
> +

Oops.

 -George

Re: [PATCH 2/5] raisin: Detect systemd

[Stefano Stabellini]

On Wed, 14 Oct 2015, George Dunlap wrote:
> On 14/10/15 17:21, George Dunlap wrote:
> > Add systemd development libraries if we detect systemd present on the system
> > 
> > Signed-off-by: George Dunlap <george.dunlap@citrix.com>
> 
> Sorry, meant to add a comment here...
> 
> > ---
> >  components/xen | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> > 
> > diff --git a/components/xen b/components/xen
> > index 090cceb..93ed288 100644
> > --- a/components/xen
> > +++ b/components/xen
> > @@ -8,6 +8,11 @@ function xen_check_package() {
> >      local DEP_Debian_common="build-essential python-dev gettext uuid-dev   \
> >               libncurses5-dev libyajl-dev libaio-dev pkg-config libglib2.0-dev  \
> >               libssl-dev libpixman-1-dev bridge-utils wget"
> > +
> > +    if [[ -e "/usr/lib/systemd" ]]
> > +    then
> > +	DEP_Debian_common="$DEP_Debian_common libsystemd-daemon-dev"
> > +    fi
> >      local DEP_Debian_x86_32="$DEP_Debian_common bcc iasl bin86 texinfo"
> >      local DEP_Debian_x86_64="$DEP_Debian_x86_32 libc6-dev-i386"
> >      local DEP_Debian_arm32="$DEP_Debian_common libfdt-dev"
> > @@ -16,6 +21,10 @@ function xen_check_package() {
> >      local DEP_Fedora_common="make gcc python-devel gettext libuuid-devel   \
> >               ncurses-devel glib2-devel libaio-devel openssl-devel yajl-devel   \
> >               patch pixman-devel glibc-devel bridge-utils grub2 wget tar bzip2"
> > +    if [[ -e "/usr/lib/systemd" ]]
> > +    then
> > +	DEP_Fedora_common="$DEP_Fedora_common systemd-devel|systemd-container-devel"
> > +    fi
> 
> This is a bit dodgy, as basically CentOS (and I think Fedora) have
> separate packages for systemd when inside a container vs on real
> hardware.  But unfortunately I'm not sure there's a way to make yum
> smart enough to know, "Gee, I'm in a container, I should run systemd
> instead".
> 
> Having the "alias" like this allows the user to work around it by
> manually installing systemd-container-devel.  It's not great though,
> because there's still nothing to prompt the user to install the correct
> package.

Can we check which package is installed on the system using
check-package (systemd vs systemd-container)? Maybe that would be more
reliable.

Re: [PATCH 2/5] raisin: Detect systemd

[George Dunlap]

On 16/10/15 14:41, Stefano Stabellini wrote:
> On Wed, 14 Oct 2015, George Dunlap wrote:
>> On 14/10/15 17:21, George Dunlap wrote:
>>> Add systemd development libraries if we detect systemd present on the system
>>>
>>> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
>>
>> Sorry, meant to add a comment here...
>>
>>> ---
>>>  components/xen | 10 ++++++++++
>>>  1 file changed, 10 insertions(+)
>>>
>>> diff --git a/components/xen b/components/xen
>>> index 090cceb..93ed288 100644
>>> --- a/components/xen
>>> +++ b/components/xen
>>> @@ -8,6 +8,11 @@ function xen_check_package() {
>>>      local DEP_Debian_common="build-essential python-dev gettext uuid-dev   \
>>>               libncurses5-dev libyajl-dev libaio-dev pkg-config libglib2.0-dev  \
>>>               libssl-dev libpixman-1-dev bridge-utils wget"
>>> +
>>> +    if [[ -e "/usr/lib/systemd" ]]
>>> +    then
>>> +	DEP_Debian_common="$DEP_Debian_common libsystemd-daemon-dev"
>>> +    fi
>>>      local DEP_Debian_x86_32="$DEP_Debian_common bcc iasl bin86 texinfo"
>>>      local DEP_Debian_x86_64="$DEP_Debian_x86_32 libc6-dev-i386"
>>>      local DEP_Debian_arm32="$DEP_Debian_common libfdt-dev"
>>> @@ -16,6 +21,10 @@ function xen_check_package() {
>>>      local DEP_Fedora_common="make gcc python-devel gettext libuuid-devel   \
>>>               ncurses-devel glib2-devel libaio-devel openssl-devel yajl-devel   \
>>>               patch pixman-devel glibc-devel bridge-utils grub2 wget tar bzip2"
>>> +    if [[ -e "/usr/lib/systemd" ]]
>>> +    then
>>> +	DEP_Fedora_common="$DEP_Fedora_common systemd-devel|systemd-container-devel"
>>> +    fi
>>
>> This is a bit dodgy, as basically CentOS (and I think Fedora) have
>> separate packages for systemd when inside a container vs on real
>> hardware.  But unfortunately I'm not sure there's a way to make yum
>> smart enough to know, "Gee, I'm in a container, I should run systemd
>> instead".
>>
>> Having the "alias" like this allows the user to work around it by
>> manually installing systemd-container-devel.  It's not great though,
>> because there's still nothing to prompt the user to install the correct
>> package.
> 
> Can we check which package is installed on the system using
> check-package (systemd vs systemd-container)? Maybe that would be more
> reliable.

Oh, you mean check-package and then modify the list of required packages
as a result?  That could work.

 -George

Re: [PATCH 2/5] raisin: Detect systemd

[Stefano Stabellini]

On Mon, 19 Oct 2015, George Dunlap wrote:
> On 16/10/15 14:41, Stefano Stabellini wrote:
> > On Wed, 14 Oct 2015, George Dunlap wrote:
> >> On 14/10/15 17:21, George Dunlap wrote:
> >>> Add systemd development libraries if we detect systemd present on the system
> >>>
> >>> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
> >>
> >> Sorry, meant to add a comment here...
> >>
> >>> ---
> >>>  components/xen | 10 ++++++++++
> >>>  1 file changed, 10 insertions(+)
> >>>
> >>> diff --git a/components/xen b/components/xen
> >>> index 090cceb..93ed288 100644
> >>> --- a/components/xen
> >>> +++ b/components/xen
> >>> @@ -8,6 +8,11 @@ function xen_check_package() {
> >>>      local DEP_Debian_common="build-essential python-dev gettext uuid-dev   \
> >>>               libncurses5-dev libyajl-dev libaio-dev pkg-config libglib2.0-dev  \
> >>>               libssl-dev libpixman-1-dev bridge-utils wget"
> >>> +
> >>> +    if [[ -e "/usr/lib/systemd" ]]
> >>> +    then
> >>> +	DEP_Debian_common="$DEP_Debian_common libsystemd-daemon-dev"
> >>> +    fi
> >>>      local DEP_Debian_x86_32="$DEP_Debian_common bcc iasl bin86 texinfo"
> >>>      local DEP_Debian_x86_64="$DEP_Debian_x86_32 libc6-dev-i386"
> >>>      local DEP_Debian_arm32="$DEP_Debian_common libfdt-dev"
> >>> @@ -16,6 +21,10 @@ function xen_check_package() {
> >>>      local DEP_Fedora_common="make gcc python-devel gettext libuuid-devel   \
> >>>               ncurses-devel glib2-devel libaio-devel openssl-devel yajl-devel   \
> >>>               patch pixman-devel glibc-devel bridge-utils grub2 wget tar bzip2"
> >>> +    if [[ -e "/usr/lib/systemd" ]]
> >>> +    then
> >>> +	DEP_Fedora_common="$DEP_Fedora_common systemd-devel|systemd-container-devel"
> >>> +    fi
> >>
> >> This is a bit dodgy, as basically CentOS (and I think Fedora) have
> >> separate packages for systemd when inside a container vs on real
> >> hardware.  But unfortunately I'm not sure there's a way to make yum
> >> smart enough to know, "Gee, I'm in a container, I should run systemd
> >> instead".
> >>
> >> Having the "alias" like this allows the user to work around it by
> >> manually installing systemd-container-devel.  It's not great though,
> >> because there's still nothing to prompt the user to install the correct
> >> package.
> > 
> > Can we check which package is installed on the system using
> > check-package (systemd vs systemd-container)? Maybe that would be more
> > reliable.
> 
> Oh, you mean check-package and then modify the list of required packages
> as a result?  That could work.

Yes, that is what I had in mind. Better than relying on a filesystem
path.

Re: [PATCH 2/5] raisin: Detect systemd

[Stefano Stabellini]

On Wed, 14 Oct 2015, George Dunlap wrote:
> Add systemd development libraries if we detect systemd present on the system
> 
> Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Please use spaces for indentation

    
>  components/xen | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/components/xen b/components/xen
> index 090cceb..93ed288 100644
> --- a/components/xen
> +++ b/components/xen
> @@ -8,6 +8,11 @@ function xen_check_package() {
>      local DEP_Debian_common="build-essential python-dev gettext uuid-dev   \
>               libncurses5-dev libyajl-dev libaio-dev pkg-config libglib2.0-dev  \
>               libssl-dev libpixman-1-dev bridge-utils wget"
> +
> +    if [[ -e "/usr/lib/systemd" ]]

I don't know much about systemd but isn't there a better way to detect
systemd? Check if it is running for example?


> +    then
> +	DEP_Debian_common="$DEP_Debian_common libsystemd-daemon-dev"
> +    fi
>      local DEP_Debian_x86_32="$DEP_Debian_common bcc iasl bin86 texinfo"
>      local DEP_Debian_x86_64="$DEP_Debian_x86_32 libc6-dev-i386"
>      local DEP_Debian_arm32="$DEP_Debian_common libfdt-dev"
> @@ -16,6 +21,10 @@ function xen_check_package() {
>      local DEP_Fedora_common="make gcc python-devel gettext libuuid-devel   \
>               ncurses-devel glib2-devel libaio-devel openssl-devel yajl-devel   \
>               patch pixman-devel glibc-devel bridge-utils grub2 wget tar bzip2"
> +    if [[ -e "/usr/lib/systemd" ]]
> +    then
> +	DEP_Fedora_common="$DEP_Fedora_common systemd-devel|systemd-container-devel"
> +    fi
>      local DEP_Fedora_x86_32="$DEP_Fedora_common dev86 acpica-tools texinfo"
>      local DEP_Fedora_x86_64="$DEP_Fedora_x86_32 glibc-devel.i686"
>  
> @@ -23,6 +32,7 @@ function xen_check_package() {
>      local DEP_CentOS_x86_32="$DEP_CentOS_common dev86 texinfo iasl"
>      local DEP_CentOS_x86_64="$DEP_CentOS_x86_32 glibc-devel.i686"
>  
> +

spurious change


>      verbose_echo Checking Xen dependencies
>      eval check-package \$DEP_"$DISTRO"_"$RAISIN_ARCH"
>  }
> -- 
> 2.1.4
> 

Re: [PATCH 2/5] raisin: Detect systemd

[Ian Campbell]

On Fri, 2015-10-16 at 14:39 +0100, Stefano Stabellini wrote:
> On Wed, 14 Oct 2015, George Dunlap wrote:
> > Add systemd development libraries if we detect systemd present on the
> > system
> > 
> > Signed-off-by: George Dunlap <george.dunlap@citrix.com>
> 
> Please use spaces for indentation
> 
>     
> >  components/xen | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> > 
> > diff --git a/components/xen b/components/xen
> > index 090cceb..93ed288 100644
> > --- a/components/xen
> > +++ b/components/xen
> > @@ -8,6 +8,11 @@ function xen_check_package() {
> >      local DEP_Debian_common="build-essential python-dev gettext uuid
> > -dev   \
> >               libncurses5-dev libyajl-dev libaio-dev pkg-config
> > libglib2.0-dev  \
> >               libssl-dev libpixman-1-dev bridge-utils wget"
> > +
> > +    if [[ -e "/usr/lib/systemd" ]]
> 
> I don't know much about systemd but isn't there a better way to detect
> systemd? Check if it is running for example?

You might want to build with systemd support even if systemd isn't actually
the current init system the system was booted with?

> 
> 
> > +    then
> > +	DEP_Debian_common="$DEP_Debian_common libsystemd-daemon-dev"
> > +    fi
> >      local DEP_Debian_x86_32="$DEP_Debian_common bcc iasl bin86
> > texinfo"
> >      local DEP_Debian_x86_64="$DEP_Debian_x86_32 libc6-dev-i386"
> >      local DEP_Debian_arm32="$DEP_Debian_common libfdt-dev"
> > @@ -16,6 +21,10 @@ function xen_check_package() {
> >      local DEP_Fedora_common="make gcc python-devel gettext libuuid
> > -devel   \
> >               ncurses-devel glib2-devel libaio-devel openssl-devel yajl
> > -devel   \
> >               patch pixman-devel glibc-devel bridge-utils grub2 wget
> > tar bzip2"
> > +    if [[ -e "/usr/lib/systemd" ]]
> > +    then
> > +	DEP_Fedora_common="$DEP_Fedora_common systemd-devel|systemd
> > -container-devel"
> > +    fi
> >      local DEP_Fedora_x86_32="$DEP_Fedora_common dev86 acpica-tools
> > texinfo"
> >      local DEP_Fedora_x86_64="$DEP_Fedora_x86_32 glibc-devel.i686"
> >  
> > @@ -23,6 +32,7 @@ function xen_check_package() {
> >      local DEP_CentOS_x86_32="$DEP_CentOS_common dev86 texinfo iasl"
> >      local DEP_CentOS_x86_64="$DEP_CentOS_x86_32 glibc-devel.i686"
> >  
> > +
> 
> spurious change
> 
> 
> >      verbose_echo Checking Xen dependencies
> >      eval check-package \$DEP_"$DISTRO"_"$RAISIN_ARCH"
> >  }

Re: [PATCH 2/5] raisin: Detect systemd

[Stefano Stabellini]

On Fri, 16 Oct 2015, Ian Campbell wrote:
> On Fri, 2015-10-16 at 14:39 +0100, Stefano Stabellini wrote:
> > On Wed, 14 Oct 2015, George Dunlap wrote:
> > > Add systemd development libraries if we detect systemd present on the
> > > system
> > > 
> > > Signed-off-by: George Dunlap <george.dunlap@citrix.com>
> > 
> > Please use spaces for indentation
> > 
> >     
> > >  components/xen | 10 ++++++++++
> > >  1 file changed, 10 insertions(+)
> > > 
> > > diff --git a/components/xen b/components/xen
> > > index 090cceb..93ed288 100644
> > > --- a/components/xen
> > > +++ b/components/xen
> > > @@ -8,6 +8,11 @@ function xen_check_package() {
> > >      local DEP_Debian_common="build-essential python-dev gettext uuid
> > > -dev   \
> > >               libncurses5-dev libyajl-dev libaio-dev pkg-config
> > > libglib2.0-dev  \
> > >               libssl-dev libpixman-1-dev bridge-utils wget"
> > > +
> > > +    if [[ -e "/usr/lib/systemd" ]]
> > 
> > I don't know much about systemd but isn't there a better way to detect
> > systemd? Check if it is running for example?
> 
> You might want to build with systemd support even if systemd isn't actually
> the current init system the system was booted with?

That is possible but also the vice versa might be true: one might want
to build without systemd even if systemd is running. Maybe we need some
kind of variable that can be overridden by the user?


> > 
> > > +    then
> > > +	DEP_Debian_common="$DEP_Debian_common libsystemd-daemon-dev"
> > > +    fi
> > >      local DEP_Debian_x86_32="$DEP_Debian_common bcc iasl bin86
> > > texinfo"
> > >      local DEP_Debian_x86_64="$DEP_Debian_x86_32 libc6-dev-i386"
> > >      local DEP_Debian_arm32="$DEP_Debian_common libfdt-dev"
> > > @@ -16,6 +21,10 @@ function xen_check_package() {
> > >      local DEP_Fedora_common="make gcc python-devel gettext libuuid
> > > -devel   \
> > >               ncurses-devel glib2-devel libaio-devel openssl-devel yajl
> > > -devel   \
> > >               patch pixman-devel glibc-devel bridge-utils grub2 wget
> > > tar bzip2"
> > > +    if [[ -e "/usr/lib/systemd" ]]
> > > +    then
> > > +	DEP_Fedora_common="$DEP_Fedora_common systemd-devel|systemd
> > > -container-devel"
> > > +    fi
> > >      local DEP_Fedora_x86_32="$DEP_Fedora_common dev86 acpica-tools
> > > texinfo"
> > >      local DEP_Fedora_x86_64="$DEP_Fedora_x86_32 glibc-devel.i686"
> > >  
> > > @@ -23,6 +32,7 @@ function xen_check_package() {
> > >      local DEP_CentOS_x86_32="$DEP_CentOS_common dev86 texinfo iasl"
> > >      local DEP_CentOS_x86_64="$DEP_CentOS_x86_32 glibc-devel.i686"
> > >  
> > > +
> > 
> > spurious change
> > 
> > 
> > >      verbose_echo Checking Xen dependencies
> > >      eval check-package \$DEP_"$DISTRO"_"$RAISIN_ARCH"
> > >  }
> 

Re: [PATCH 2/5] raisin: Detect systemd

[George Dunlap]

On 16/10/15 15:04, Stefano Stabellini wrote:
> On Fri, 16 Oct 2015, Ian Campbell wrote:
>> On Fri, 2015-10-16 at 14:39 +0100, Stefano Stabellini wrote:
>>> On Wed, 14 Oct 2015, George Dunlap wrote:
>>>> Add systemd development libraries if we detect systemd present on the
>>>> system
>>>>
>>>> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
>>>
>>> Please use spaces for indentation
>>>
>>>     
>>>>  components/xen | 10 ++++++++++
>>>>  1 file changed, 10 insertions(+)
>>>>
>>>> diff --git a/components/xen b/components/xen
>>>> index 090cceb..93ed288 100644
>>>> --- a/components/xen
>>>> +++ b/components/xen
>>>> @@ -8,6 +8,11 @@ function xen_check_package() {
>>>>      local DEP_Debian_common="build-essential python-dev gettext uuid
>>>> -dev   \
>>>>               libncurses5-dev libyajl-dev libaio-dev pkg-config
>>>> libglib2.0-dev  \
>>>>               libssl-dev libpixman-1-dev bridge-utils wget"
>>>> +
>>>> +    if [[ -e "/usr/lib/systemd" ]]
>>>
>>> I don't know much about systemd but isn't there a better way to detect
>>> systemd? Check if it is running for example?
>>
>> You might want to build with systemd support even if systemd isn't actually
>> the current init system the system was booted with?
> 
> That is possible but also the vice versa might be true: one might want
> to build without systemd even if systemd is running. Maybe we need some
> kind of variable that can be overridden by the user?

You mean like XEN_CONFIG_EXTRA? :-D

For people frobbing around with XEN_CONFIG_EXTRA, I think it's
reasonable for them to get a build error if they add --with-systemd but
don't have the requisite packages.  (I'm pretty sure that's what will
happen now, at any rate.)

Since I'm going to be checking for systemd packages anyway due to the
container issue, maybe it would just make sense to include the dep
automatically only if the systemd packages are installed.

Alternately, I suppose we could extend the check-package "syntax" to
have "if package X in stalled, add dependency Y" -- similar to the '|'
operator we added earlier.  Then we could do something like this:

systemd:systemd-devel systemd-container:systemd-container-devel

What do you think?

 -George

Re: [PATCH 2/5] raisin: Detect systemd

[Stefano Stabellini]

On Mon, 19 Oct 2015, George Dunlap wrote:
> On 16/10/15 15:04, Stefano Stabellini wrote:
> > On Fri, 16 Oct 2015, Ian Campbell wrote:
> >> On Fri, 2015-10-16 at 14:39 +0100, Stefano Stabellini wrote:
> >>> On Wed, 14 Oct 2015, George Dunlap wrote:
> >>>> Add systemd development libraries if we detect systemd present on the
> >>>> system
> >>>>
> >>>> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
> >>>
> >>> Please use spaces for indentation
> >>>
> >>>     
> >>>>  components/xen | 10 ++++++++++
> >>>>  1 file changed, 10 insertions(+)
> >>>>
> >>>> diff --git a/components/xen b/components/xen
> >>>> index 090cceb..93ed288 100644
> >>>> --- a/components/xen
> >>>> +++ b/components/xen
> >>>> @@ -8,6 +8,11 @@ function xen_check_package() {
> >>>>      local DEP_Debian_common="build-essential python-dev gettext uuid
> >>>> -dev   \
> >>>>               libncurses5-dev libyajl-dev libaio-dev pkg-config
> >>>> libglib2.0-dev  \
> >>>>               libssl-dev libpixman-1-dev bridge-utils wget"
> >>>> +
> >>>> +    if [[ -e "/usr/lib/systemd" ]]
> >>>
> >>> I don't know much about systemd but isn't there a better way to detect
> >>> systemd? Check if it is running for example?
> >>
> >> You might want to build with systemd support even if systemd isn't actually
> >> the current init system the system was booted with?
> > 
> > That is possible but also the vice versa might be true: one might want
> > to build without systemd even if systemd is running. Maybe we need some
> > kind of variable that can be overridden by the user?
> 
> You mean like XEN_CONFIG_EXTRA? :-D

Actually I was thinking of something more specific like:

if [[ -z "$WITH_SYSTEMD" ]]
then
    if check-package systemd
    then
        WITH_SYSTEMD=y
    else
        WITH_SYSTEMD=n
    fi
fi

so that people that don't want systemd but they have it installed for
some reasons, they can export WITH_SYSTEMD=n and from raisin point of
view we are not cluttering the interface too much. But I am also OK with
just enable systemd if it is installed and not enable it if it is not.


> For people frobbing around with XEN_CONFIG_EXTRA, I think it's
> reasonable for them to get a build error if they add --with-systemd but
> don't have the requisite packages.  (I'm pretty sure that's what will
> happen now, at any rate.)
> 
> Since I'm going to be checking for systemd packages anyway due to the
> container issue, maybe it would just make sense to include the dep
> automatically only if the systemd packages are installed.

I agree, that works and it is simple.


> Alternately, I suppose we could extend the check-package "syntax" to
> have "if package X in stalled, add dependency Y" -- similar to the '|'
> operator we added earlier.  Then we could do something like this:
> 
> systemd:systemd-devel systemd-container:systemd-container-devel
> 
> What do you think?

I would prefer to avoid it unless strictly necessary.

[PATCH 3/5] raisin: Allow iasl to alias acpica-tools, unify Fedora and CentOS deps for xen

[George Dunlap]

CentOS 7 now aliases acpica-tools instead of iasl, making its deps
essentially the same as Fedora.  Add iasl|acpica-tools as an alias in
the Fedora deps, and make the CentOS deps a straight clone of the
Fedora deps (as they are for the other components).

Signed-off-by: George Dunlap <george.dunlap@citrix.com>
---
 components/xen | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/components/xen b/components/xen
index 93ed288..4c37cca 100644
--- a/components/xen
+++ b/components/xen
@@ -25,12 +25,12 @@ function xen_check_package() {
     then
 	DEP_Fedora_common="$DEP_Fedora_common systemd-devel|systemd-container-devel"
     fi
-    local DEP_Fedora_x86_32="$DEP_Fedora_common dev86 acpica-tools texinfo"
+    local DEP_Fedora_x86_32="$DEP_Fedora_common dev86 iasl|acpica-tools texinfo"
     local DEP_Fedora_x86_64="$DEP_Fedora_x86_32 glibc-devel.i686"
 
     local DEP_CentOS_common="$DEP_Fedora_common"
-    local DEP_CentOS_x86_32="$DEP_CentOS_common dev86 texinfo iasl"
-    local DEP_CentOS_x86_64="$DEP_CentOS_x86_32 glibc-devel.i686"
+    local DEP_CentOS_x86_32="$DEP_Fedora_x86_32"
+    local DEP_CentOS_x86_64="$DEP_Fedora_x86_64"
 
 
     verbose_echo Checking Xen dependencies
-- 
2.1.4

Re: [PATCH 3/5] raisin: Allow iasl to alias acpica-tools, unify Fedora and CentOS deps for xen

[Stefano Stabellini]

On Wed, 14 Oct 2015, George Dunlap wrote:
> CentOS 7 now aliases acpica-tools instead of iasl, making its deps
> essentially the same as Fedora.  Add iasl|acpica-tools as an alias in
> the Fedora deps, and make the CentOS deps a straight clone of the
> Fedora deps (as they are for the other components).
> 
> Signed-off-by: George Dunlap <george.dunlap@citrix.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  components/xen | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/components/xen b/components/xen
> index 93ed288..4c37cca 100644
> --- a/components/xen
> +++ b/components/xen
> @@ -25,12 +25,12 @@ function xen_check_package() {
>      then
>  	DEP_Fedora_common="$DEP_Fedora_common systemd-devel|systemd-container-devel"
>      fi
> -    local DEP_Fedora_x86_32="$DEP_Fedora_common dev86 acpica-tools texinfo"
> +    local DEP_Fedora_x86_32="$DEP_Fedora_common dev86 iasl|acpica-tools texinfo"
>      local DEP_Fedora_x86_64="$DEP_Fedora_x86_32 glibc-devel.i686"
>  
>      local DEP_CentOS_common="$DEP_Fedora_common"
> -    local DEP_CentOS_x86_32="$DEP_CentOS_common dev86 texinfo iasl"
> -    local DEP_CentOS_x86_64="$DEP_CentOS_x86_32 glibc-devel.i686"
> +    local DEP_CentOS_x86_32="$DEP_Fedora_x86_32"
> +    local DEP_CentOS_x86_64="$DEP_Fedora_x86_64"
>  
>  
>      verbose_echo Checking Xen dependencies
> -- 
> 2.1.4
> 

[PATCH 4/5] raisin: Change update/release parsing OSes

[George Dunlap]

At the moment, something like 7.1.1503 will be parsed as RELEASE=7.1
UPDATE=1503.  Change the bash string so that RELEASE=7 UPDATE=1.1503
in this case.

Also add an example CentOS 7 release string, and add the RELEASE /
UPDATE parsing to lsb_release as well.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>
---
 lib/common-functions.sh | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/lib/common-functions.sh b/lib/common-functions.sh
index a389054..1343dc8 100644
--- a/lib/common-functions.sh
+++ b/lib/common-functions.sh
@@ -103,13 +103,15 @@ function get_distro() {
         os_VENDOR=`lsb_release -i -s`
         os_RELEASE=`lsb_release -r -s`
         os_CODENAME=`lsb_release -c -s`
-        os_UPDATE=""
+        os_UPDATE=${os_RELEASE#*.}
+        os_RELEASE=${os_RELEASE%%.*}
     elif [[ -r /etc/redhat-release ]]
     then
         # Red Hat Enterprise Linux Server release 5.5 (Tikanga)
         # Red Hat Enterprise Linux Server release 7.0 Beta (Maipo)
         # CentOS release 5.5 (Final)
         # CentOS Linux release 6.0 (Final)
+        # CentOS Linux release 7.1.1503 (Core)
         # Fedora release 16 (Verne)
         # XenServer release 6.2.0-70446c (xenenterprise)
         os_CODENAME=""
@@ -120,8 +122,8 @@ function get_distro() {
                 ver=`sed -e 's/^.* \([0-9].*\) (\(.*\)).*$/\1\|\2/' /etc/redhat-release`
                 os_CODENAME=${ver#*|}
                 os_RELEASE=${ver%|*}
-                os_UPDATE=${os_RELEASE##*.}
-                os_RELEASE=${os_RELEASE%.*}
+                os_UPDATE=${os_RELEASE#*.}
+                os_RELEASE=${os_RELEASE%%.*}
                 break
             fi
         done
-- 
2.1.4

Re: [PATCH 4/5] raisin: Change update/release parsing OSes

[Stefano Stabellini]

On Wed, 14 Oct 2015, George Dunlap wrote:
> At the moment, something like 7.1.1503 will be parsed as RELEASE=7.1
> UPDATE=1503.  Change the bash string so that RELEASE=7 UPDATE=1.1503
> in this case.
> 
> Also add an example CentOS 7 release string, and add the RELEASE /
> UPDATE parsing to lsb_release as well.
> 
> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
> ---
>  lib/common-functions.sh | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/lib/common-functions.sh b/lib/common-functions.sh
> index a389054..1343dc8 100644
> --- a/lib/common-functions.sh
> +++ b/lib/common-functions.sh
> @@ -103,13 +103,15 @@ function get_distro() {
>          os_VENDOR=`lsb_release -i -s`
>          os_RELEASE=`lsb_release -r -s`
>          os_CODENAME=`lsb_release -c -s`
> -        os_UPDATE=""
> +        os_UPDATE=${os_RELEASE#*.}
> +        os_RELEASE=${os_RELEASE%%.*}
>      elif [[ -r /etc/redhat-release ]]
>      then
>          # Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>          # Red Hat Enterprise Linux Server release 7.0 Beta (Maipo)
>          # CentOS release 5.5 (Final)
>          # CentOS Linux release 6.0 (Final)
> +        # CentOS Linux release 7.1.1503 (Core)
>          # Fedora release 16 (Verne)
>          # XenServer release 6.2.0-70446c (xenenterprise)
>          os_CODENAME=""
> @@ -120,8 +122,8 @@ function get_distro() {
>                  ver=`sed -e 's/^.* \([0-9].*\) (\(.*\)).*$/\1\|\2/' /etc/redhat-release`
>                  os_CODENAME=${ver#*|}
>                  os_RELEASE=${ver%|*}
> -                os_UPDATE=${os_RELEASE##*.}
> -                os_RELEASE=${os_RELEASE%.*}
> +                os_UPDATE=${os_RELEASE#*.}
> +                os_RELEASE=${os_RELEASE%%.*}
>                  break

This change is OK, but I don't know if this is what we want for the
other case above. I would be tempted to leave the lsb_release case as
is.

Re: [PATCH 4/5] raisin: Change update/release parsing OSes

[George Dunlap]

On 16/10/15 14:49, Stefano Stabellini wrote:
> On Wed, 14 Oct 2015, George Dunlap wrote:
>> At the moment, something like 7.1.1503 will be parsed as RELEASE=7.1
>> UPDATE=1503.  Change the bash string so that RELEASE=7 UPDATE=1.1503
>> in this case.
>>
>> Also add an example CentOS 7 release string, and add the RELEASE /
>> UPDATE parsing to lsb_release as well.
>>
>> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
>> ---
>>  lib/common-functions.sh | 8 +++++---
>>  1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/lib/common-functions.sh b/lib/common-functions.sh
>> index a389054..1343dc8 100644
>> --- a/lib/common-functions.sh
>> +++ b/lib/common-functions.sh
>> @@ -103,13 +103,15 @@ function get_distro() {
>>          os_VENDOR=`lsb_release -i -s`
>>          os_RELEASE=`lsb_release -r -s`
>>          os_CODENAME=`lsb_release -c -s`
>> -        os_UPDATE=""
>> +        os_UPDATE=${os_RELEASE#*.}
>> +        os_RELEASE=${os_RELEASE%%.*}
>>      elif [[ -r /etc/redhat-release ]]
>>      then
>>          # Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>>          # Red Hat Enterprise Linux Server release 7.0 Beta (Maipo)
>>          # CentOS release 5.5 (Final)
>>          # CentOS Linux release 6.0 (Final)
>> +        # CentOS Linux release 7.1.1503 (Core)
>>          # Fedora release 16 (Verne)
>>          # XenServer release 6.2.0-70446c (xenenterprise)
>>          os_CODENAME=""
>> @@ -120,8 +122,8 @@ function get_distro() {
>>                  ver=`sed -e 's/^.* \([0-9].*\) (\(.*\)).*$/\1\|\2/' /etc/redhat-release`
>>                  os_CODENAME=${ver#*|}
>>                  os_RELEASE=${ver%|*}
>> -                os_UPDATE=${os_RELEASE##*.}
>> -                os_RELEASE=${os_RELEASE%.*}
>> +                os_UPDATE=${os_RELEASE#*.}
>> +                os_RELEASE=${os_RELEASE%%.*}
>>                  break
> 
> This change is OK, but I don't know if this is what we want for the
> other case above. I would be tempted to leave the lsb_release case as
> is.

?

Don't we want the resulting state of "get_distro()" to work the same
whether you have lsb_release installed or not?

I wrote this patch quite a while ago, but I'm pretty sure that I tested
it with the lsb package installed and not installed for C7 (and maybe C6
as well) and with this patch I got the same results.

(Or to put it a different way: The only reason I even modified the
lsb_release section is because I installed the lsb package and got
strange results.)

 -George

Re: [PATCH 4/5] raisin: Change update/release parsing OSes

[Stefano Stabellini]

On Mon, 19 Oct 2015, George Dunlap wrote:
> On 16/10/15 14:49, Stefano Stabellini wrote:
> > On Wed, 14 Oct 2015, George Dunlap wrote:
> >> At the moment, something like 7.1.1503 will be parsed as RELEASE=7.1
> >> UPDATE=1503.  Change the bash string so that RELEASE=7 UPDATE=1.1503
> >> in this case.
> >>
> >> Also add an example CentOS 7 release string, and add the RELEASE /
> >> UPDATE parsing to lsb_release as well.
> >>
> >> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
> >> ---
> >>  lib/common-functions.sh | 8 +++++---
> >>  1 file changed, 5 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/lib/common-functions.sh b/lib/common-functions.sh
> >> index a389054..1343dc8 100644
> >> --- a/lib/common-functions.sh
> >> +++ b/lib/common-functions.sh
> >> @@ -103,13 +103,15 @@ function get_distro() {
> >>          os_VENDOR=`lsb_release -i -s`
> >>          os_RELEASE=`lsb_release -r -s`
> >>          os_CODENAME=`lsb_release -c -s`
> >> -        os_UPDATE=""
> >> +        os_UPDATE=${os_RELEASE#*.}
> >> +        os_RELEASE=${os_RELEASE%%.*}
> >>      elif [[ -r /etc/redhat-release ]]
> >>      then
> >>          # Red Hat Enterprise Linux Server release 5.5 (Tikanga)
> >>          # Red Hat Enterprise Linux Server release 7.0 Beta (Maipo)
> >>          # CentOS release 5.5 (Final)
> >>          # CentOS Linux release 6.0 (Final)
> >> +        # CentOS Linux release 7.1.1503 (Core)
> >>          # Fedora release 16 (Verne)
> >>          # XenServer release 6.2.0-70446c (xenenterprise)
> >>          os_CODENAME=""
> >> @@ -120,8 +122,8 @@ function get_distro() {
> >>                  ver=`sed -e 's/^.* \([0-9].*\) (\(.*\)).*$/\1\|\2/' /etc/redhat-release`
> >>                  os_CODENAME=${ver#*|}
> >>                  os_RELEASE=${ver%|*}
> >> -                os_UPDATE=${os_RELEASE##*.}
> >> -                os_RELEASE=${os_RELEASE%.*}
> >> +                os_UPDATE=${os_RELEASE#*.}
> >> +                os_RELEASE=${os_RELEASE%%.*}
> >>                  break
> > 
> > This change is OK, but I don't know if this is what we want for the
> > other case above. I would be tempted to leave the lsb_release case as
> > is.
> 
> ?
> 
> Don't we want the resulting state of "get_distro()" to work the same
> whether you have lsb_release installed or not?
> 
> I wrote this patch quite a while ago, but I'm pretty sure that I tested
> it with the lsb package installed and not installed for C7 (and maybe C6
> as well) and with this patch I got the same results.
> 
> (Or to put it a different way: The only reason I even modified the
> lsb_release section is because I installed the lsb package and got
> strange results.)

The problem is that the lsb_release change would affect other distros too.
For example on Ubuntu, I get

sstabellini@kaball:~$ lsb_release -r -s
12.04

with the current scheme:
os_RELEASE=12.04
os_UPDATE=""

with the new scheme:
os_RELEASE=12
os_UPDATE=04

I don't think that's what we want: os_RELEASE should be the output of
lsb_release -r -s, after all -r stands for "release". What do you think?


But maybe if there are two dots in the release number then you can
extract the last number and that could be the update.
For example, if

sstabellini@kaball:~$ lsb_release -r -s
12.04.1

then I guess it could make sense to set os_RELEASE=12.04 and os_UPDATE=1.
Similarly for CentOS if lsb_release -r -s returns "7.1.1503", then we
could set os_RELEASE=7.1 and os_UPDATE=1503. Would that be good enough?

Re: [PATCH 4/5] raisin: Change update/release parsing OSes

[George Dunlap]

On 19/10/15 12:26, Stefano Stabellini wrote:
> On Mon, 19 Oct 2015, George Dunlap wrote:
>> On 16/10/15 14:49, Stefano Stabellini wrote:
>>> On Wed, 14 Oct 2015, George Dunlap wrote:
>>>> At the moment, something like 7.1.1503 will be parsed as RELEASE=7.1
>>>> UPDATE=1503.  Change the bash string so that RELEASE=7 UPDATE=1.1503
>>>> in this case.
>>>>
>>>> Also add an example CentOS 7 release string, and add the RELEASE /
>>>> UPDATE parsing to lsb_release as well.
>>>>
>>>> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
>>>> ---
>>>>  lib/common-functions.sh | 8 +++++---
>>>>  1 file changed, 5 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/lib/common-functions.sh b/lib/common-functions.sh
>>>> index a389054..1343dc8 100644
>>>> --- a/lib/common-functions.sh
>>>> +++ b/lib/common-functions.sh
>>>> @@ -103,13 +103,15 @@ function get_distro() {
>>>>          os_VENDOR=`lsb_release -i -s`
>>>>          os_RELEASE=`lsb_release -r -s`
>>>>          os_CODENAME=`lsb_release -c -s`
>>>> -        os_UPDATE=""
>>>> +        os_UPDATE=${os_RELEASE#*.}
>>>> +        os_RELEASE=${os_RELEASE%%.*}
>>>>      elif [[ -r /etc/redhat-release ]]
>>>>      then
>>>>          # Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>>>>          # Red Hat Enterprise Linux Server release 7.0 Beta (Maipo)
>>>>          # CentOS release 5.5 (Final)
>>>>          # CentOS Linux release 6.0 (Final)
>>>> +        # CentOS Linux release 7.1.1503 (Core)
>>>>          # Fedora release 16 (Verne)
>>>>          # XenServer release 6.2.0-70446c (xenenterprise)
>>>>          os_CODENAME=""
>>>> @@ -120,8 +122,8 @@ function get_distro() {
>>>>                  ver=`sed -e 's/^.* \([0-9].*\) (\(.*\)).*$/\1\|\2/' /etc/redhat-release`
>>>>                  os_CODENAME=${ver#*|}
>>>>                  os_RELEASE=${ver%|*}
>>>> -                os_UPDATE=${os_RELEASE##*.}
>>>> -                os_RELEASE=${os_RELEASE%.*}
>>>> +                os_UPDATE=${os_RELEASE#*.}
>>>> +                os_RELEASE=${os_RELEASE%%.*}
>>>>                  break
>>>
>>> This change is OK, but I don't know if this is what we want for the
>>> other case above. I would be tempted to leave the lsb_release case as
>>> is.
>>
>> ?
>>
>> Don't we want the resulting state of "get_distro()" to work the same
>> whether you have lsb_release installed or not?
>>
>> I wrote this patch quite a while ago, but I'm pretty sure that I tested
>> it with the lsb package installed and not installed for C7 (and maybe C6
>> as well) and with this patch I got the same results.
>>
>> (Or to put it a different way: The only reason I even modified the
>> lsb_release section is because I installed the lsb package and got
>> strange results.)
> 
> The problem is that the lsb_release change would affect other distros too.
> For example on Ubuntu, I get
> 
> sstabellini@kaball:~$ lsb_release -r -s
> 12.04
> 
> with the current scheme:
> os_RELEASE=12.04
> os_UPDATE=""
> 
> with the new scheme:
> os_RELEASE=12
> os_UPDATE=04
> 
> I don't think that's what we want: os_RELEASE should be the output of
> lsb_release -r -s, after all -r stands for "release". What do you think?
> 
> 
> But maybe if there are two dots in the release number then you can
> extract the last number and that could be the update.
> For example, if
> 
> sstabellini@kaball:~$ lsb_release -r -s
> 12.04.1
> 
> then I guess it could make sense to set os_RELEASE=12.04 and os_UPDATE=1.
> Similarly for CentOS if lsb_release -r -s returns "7.1.1503", then we
> could set os_RELEASE=7.1 and os_UPDATE=1503. Would that be good enough?

So the reason I wanted os_RELEASE in this case to be "7" or "6" was
because of the package rename issue with iasl|acpica-tools.  But
actually I've solved that using the "aliases" patch now (see 3/5), so in
fact I don't think anyone is using this information anymore.

So maybe I'll just drop this patch for now and we can sort things out
when we actually need it. :-)

 -George

[PATCH 5/5] raisin: Add XEN_CONFIG_EXTRA to config file

[George Dunlap]

Allowing the user to enable or disable specific functionality, such as
stubdoms.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
---
 components/xen        | 2 +-
 configs/config-4.5    | 4 ++++
 configs/config-4.6    | 4 ++++
 configs/config-master | 4 ++++
 4 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/components/xen b/components/xen
index 4c37cca..06806b5 100644
--- a/components/xen
+++ b/components/xen
@@ -53,7 +53,7 @@ function xen_build() {
         ovmf_opt="--enable-ovmf --with-system-ovmf="$BASEDIR"/ovmf-dir/ovmf.bin"
     fi
     ./configure --prefix=$PREFIX --with-system-qemu=$PREFIX/lib/xen/bin/qemu-system-i386 \
-        --disable-qemu-traditional --enable-rombios $seabios_opt $ovmf_opt
+        --disable-qemu-traditional --enable-rombios $seabios_opt $ovmf_opt $XEN_CONFIG_EXTRA
     $RAISIN_MAKE
     $RAISIN_MAKE install DESTDIR="$INST_DIR"
     cd "$BASEDIR"
diff --git a/configs/config-4.5 b/configs/config-4.5
index e3b92d5..1fe86c7 100644
--- a/configs/config-4.5
+++ b/configs/config-4.5
@@ -41,6 +41,10 @@ LIBVIRT_REVISION="origin/xen-tested-master"
 OVMF_REVISION="cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd"
 LINUX_REVISION="master"
 
+# Per-project options
+## Passed to "./configure" when building Xen.  Use to enable or disable specific features
+# XEN_CONFIG_EXTRA="--disable-stubdom"
+
 # Tests
 ## All tests: busybox-pv busybox-hvm
 ## ENABLED_TESTS is the list of test run by raise test
diff --git a/configs/config-4.6 b/configs/config-4.6
index ebd45e7..623d43c 100644
--- a/configs/config-4.6
+++ b/configs/config-4.6
@@ -41,6 +41,10 @@ LIBVIRT_REVISION="origin/xen-tested-master"
 OVMF_REVISION="cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd"
 LINUX_REVISION="master"
 
+# Per-project options
+## Passed to "./configure" when building Xen.  Use to enable or disable specific features
+# XEN_CONFIG_EXTRA="--disable-stubdom"
+
 # Tests
 ## All tests: busybox-pv busybox-hvm
 ## ENABLED_TESTS is the list of test run by raise test
diff --git a/configs/config-master b/configs/config-master
index b218708..7d2f822 100644
--- a/configs/config-master
+++ b/configs/config-master
@@ -40,6 +40,10 @@ LIBVIRT_REVISION="origin/xen-tested-master"
 OVMF_REVISION="origin/xen-tested-master"
 LINUX_REVISION="master"
 
+# Per-project options
+## Passed to "./configure" when building Xen.  Use to enable or disable specific features
+# XEN_CONFIG_EXTRA="--disable-stubdom"
+
 # Tests
 ## All tests: busybox-pv busybox-hvm
 ## ENABLED_TESTS is the list of test run by raise test
-- 
2.1.4

Re: [PATCH 5/5] raisin: Add XEN_CONFIG_EXTRA to config file

[Stefano Stabellini]

On Wed, 14 Oct 2015, George Dunlap wrote:
> Allowing the user to enable or disable specific functionality, such as
> stubdoms.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

I don't like this very much: if we want to disable stubdoms by default
with all configs, then I would prefer to simply add --disable-stubdom to
components/xen without introducing XEN_CONFIG_EXTRA.

Otherwise if we want to give users the chance to add an extra config
option, I would introduce a generic way to do that, so that people can
use it with any components they want, QEMU, libvirt, etc.


>  components/xen        | 2 +-
>  configs/config-4.5    | 4 ++++
>  configs/config-4.6    | 4 ++++
>  configs/config-master | 4 ++++
>  4 files changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/components/xen b/components/xen
> index 4c37cca..06806b5 100644
> --- a/components/xen
> +++ b/components/xen
> @@ -53,7 +53,7 @@ function xen_build() {
>          ovmf_opt="--enable-ovmf --with-system-ovmf="$BASEDIR"/ovmf-dir/ovmf.bin"
>      fi
>      ./configure --prefix=$PREFIX --with-system-qemu=$PREFIX/lib/xen/bin/qemu-system-i386 \
> -        --disable-qemu-traditional --enable-rombios $seabios_opt $ovmf_opt
> +        --disable-qemu-traditional --enable-rombios $seabios_opt $ovmf_opt $XEN_CONFIG_EXTRA
>      $RAISIN_MAKE
>      $RAISIN_MAKE install DESTDIR="$INST_DIR"
>      cd "$BASEDIR"
> diff --git a/configs/config-4.5 b/configs/config-4.5
> index e3b92d5..1fe86c7 100644
> --- a/configs/config-4.5
> +++ b/configs/config-4.5
> @@ -41,6 +41,10 @@ LIBVIRT_REVISION="origin/xen-tested-master"
>  OVMF_REVISION="cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd"
>  LINUX_REVISION="master"
>  
> +# Per-project options
> +## Passed to "./configure" when building Xen.  Use to enable or disable specific features
> +# XEN_CONFIG_EXTRA="--disable-stubdom"
> +
>  # Tests
>  ## All tests: busybox-pv busybox-hvm
>  ## ENABLED_TESTS is the list of test run by raise test
> diff --git a/configs/config-4.6 b/configs/config-4.6
> index ebd45e7..623d43c 100644
> --- a/configs/config-4.6
> +++ b/configs/config-4.6
> @@ -41,6 +41,10 @@ LIBVIRT_REVISION="origin/xen-tested-master"
>  OVMF_REVISION="cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd"
>  LINUX_REVISION="master"
>  
> +# Per-project options
> +## Passed to "./configure" when building Xen.  Use to enable or disable specific features
> +# XEN_CONFIG_EXTRA="--disable-stubdom"
> +
>  # Tests
>  ## All tests: busybox-pv busybox-hvm
>  ## ENABLED_TESTS is the list of test run by raise test
> diff --git a/configs/config-master b/configs/config-master
> index b218708..7d2f822 100644
> --- a/configs/config-master
> +++ b/configs/config-master
> @@ -40,6 +40,10 @@ LIBVIRT_REVISION="origin/xen-tested-master"
>  OVMF_REVISION="origin/xen-tested-master"
>  LINUX_REVISION="master"
>  
> +# Per-project options
> +## Passed to "./configure" when building Xen.  Use to enable or disable specific features
> +# XEN_CONFIG_EXTRA="--disable-stubdom"
> +
>  # Tests
>  ## All tests: busybox-pv busybox-hvm
>  ## ENABLED_TESTS is the list of test run by raise test
> -- 
> 2.1.4
> 

Re: [PATCH 5/5] raisin: Add XEN_CONFIG_EXTRA to config file

[George Dunlap]

On 16/10/15 14:53, Stefano Stabellini wrote:
> On Wed, 14 Oct 2015, George Dunlap wrote:
>> Allowing the user to enable or disable specific functionality, such as
>> stubdoms.
>>
>> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> I don't like this very much: if we want to disable stubdoms by default
> with all configs, then I would prefer to simply add --disable-stubdom to
> components/xen without introducing XEN_CONFIG_EXTRA.
> 
> Otherwise if we want to give users the chance to add an extra config
> option, I would introduce a generic way to do that, so that people can
> use it with any components they want, QEMU, libvirt, etc.

You did notice that this config option is disabled by default, right?  I
added the line commented-out as an example of the sort of thing you
might want to do.

I don't think we want to disable stubdoms by default across the board.

I wouldn't object to adding empty config variables to the other
components; I just don't have a good way to test them at the moment.

 -George

Re: [PATCH 5/5] raisin: Add XEN_CONFIG_EXTRA to config file

[Stefano Stabellini]

On Mon, 19 Oct 2015, George Dunlap wrote:
> On 16/10/15 14:53, Stefano Stabellini wrote:
> > On Wed, 14 Oct 2015, George Dunlap wrote:
> >> Allowing the user to enable or disable specific functionality, such as
> >> stubdoms.
> >>
> >> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> > 
> > I don't like this very much: if we want to disable stubdoms by default
> > with all configs, then I would prefer to simply add --disable-stubdom to
> > components/xen without introducing XEN_CONFIG_EXTRA.
> > 
> > Otherwise if we want to give users the chance to add an extra config
> > option, I would introduce a generic way to do that, so that people can
> > use it with any components they want, QEMU, libvirt, etc.
> 
> You did notice that this config option is disabled by default, right?  I
> added the line commented-out as an example of the sort of thing you
> might want to do.
> 
> I don't think we want to disable stubdoms by default across the board.
> 
> I wouldn't object to adding empty config variables to the other
> components; I just don't have a good way to test them at the moment.
 
What if we just add an environmental variable named as
COMPONENT_BUILD_CONFIGURE at the end of the configure line when
appropriate?  Of course it would need to be documented in the README.

Something like:


diff --git a/components/qemu b/components/qemu
index dce4ce0..0e57bdb 100644
--- a/components/qemu
+++ b/components/qemu
@@ -27,7 +27,7 @@ function qemu_build() {
         --disable-docs \
         --bindir=$PREFIX/lib/xen/bin \
         --datadir=$PREFIX/share/qemu-xen \
-        --disable-guest-agent
+        --disable-guest-agent $QEMU_BUILD_CONFIGURE
     $RAISIN_MAKE all
     $RAISIN_MAKE install DESTDIR="$INST_DIR"
     cd "$BASEDIR"
diff --git a/components/xen b/components/xen
index 6b700e5..01527ec 100644
--- a/components/xen
+++ b/components/xen
@@ -39,7 +39,7 @@ function xen_build() {
         ovmf_opt="--enable-ovmf --with-system-ovmf="$BASEDIR"/ovmf-dir/ovmf.bin"
     fi
     ./configure --prefix=$PREFIX --with-system-qemu=$PREFIX/lib/xen/bin/qemu-system-i386 \
-        --disable-qemu-traditional --enable-rombios $seabios_opt $ovmf_opt
+        --disable-qemu-traditional --enable-rombios $seabios_opt $ovmf_opt $XEN_BUILD_CONFIGURE
     $RAISIN_MAKE
     $RAISIN_MAKE install DESTDIR="$INST_DIR"
     cd "$BASEDIR"

Re: [PATCH 5/5] raisin: Add XEN_CONFIG_EXTRA to config file

[George Dunlap]

On 19/10/15 12:37, Stefano Stabellini wrote:
> On Mon, 19 Oct 2015, George Dunlap wrote:
>> On 16/10/15 14:53, Stefano Stabellini wrote:
>>> On Wed, 14 Oct 2015, George Dunlap wrote:
>>>> Allowing the user to enable or disable specific functionality, such as
>>>> stubdoms.
>>>>
>>>> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
>>>
>>> I don't like this very much: if we want to disable stubdoms by default
>>> with all configs, then I would prefer to simply add --disable-stubdom to
>>> components/xen without introducing XEN_CONFIG_EXTRA.
>>>
>>> Otherwise if we want to give users the chance to add an extra config
>>> option, I would introduce a generic way to do that, so that people can
>>> use it with any components they want, QEMU, libvirt, etc.
>>
>> You did notice that this config option is disabled by default, right?  I
>> added the line commented-out as an example of the sort of thing you
>> might want to do.
>>
>> I don't think we want to disable stubdoms by default across the board.
>>
>> I wouldn't object to adding empty config variables to the other
>> components; I just don't have a good way to test them at the moment.
>  
> What if we just add an environmental variable named as
> COMPONENT_BUILD_CONFIGURE at the end of the configure line when
> appropriate?  Of course it would need to be documented in the README.

Isn't this exactly the same as my patch, but
1) With a different name, and
2) No examples in the config files?

I don't mind #1, but #2 seems like the most logical place to document it.

 -George

> 
> Something like:
> 
> 
> diff --git a/components/qemu b/components/qemu
> index dce4ce0..0e57bdb 100644
> --- a/components/qemu
> +++ b/components/qemu
> @@ -27,7 +27,7 @@ function qemu_build() {
>          --disable-docs \
>          --bindir=$PREFIX/lib/xen/bin \
>          --datadir=$PREFIX/share/qemu-xen \
> -        --disable-guest-agent
> +        --disable-guest-agent $QEMU_BUILD_CONFIGURE
>      $RAISIN_MAKE all
>      $RAISIN_MAKE install DESTDIR="$INST_DIR"
>      cd "$BASEDIR"
> diff --git a/components/xen b/components/xen
> index 6b700e5..01527ec 100644
> --- a/components/xen
> +++ b/components/xen
> @@ -39,7 +39,7 @@ function xen_build() {
>          ovmf_opt="--enable-ovmf --with-system-ovmf="$BASEDIR"/ovmf-dir/ovmf.bin"
>      fi
>      ./configure --prefix=$PREFIX --with-system-qemu=$PREFIX/lib/xen/bin/qemu-system-i386 \
> -        --disable-qemu-traditional --enable-rombios $seabios_opt $ovmf_opt
> +        --disable-qemu-traditional --enable-rombios $seabios_opt $ovmf_opt $XEN_BUILD_CONFIGURE
>      $RAISIN_MAKE
>      $RAISIN_MAKE install DESTDIR="$INST_DIR"
>      cd "$BASEDIR"
> 

Re: [PATCH 5/5] raisin: Add XEN_CONFIG_EXTRA to config file

[Stefano Stabellini]

On Mon, 19 Oct 2015, George Dunlap wrote:
> On 19/10/15 12:37, Stefano Stabellini wrote:
> > On Mon, 19 Oct 2015, George Dunlap wrote:
> >> On 16/10/15 14:53, Stefano Stabellini wrote:
> >>> On Wed, 14 Oct 2015, George Dunlap wrote:
> >>>> Allowing the user to enable or disable specific functionality, such as
> >>>> stubdoms.
> >>>>
> >>>> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> >>>
> >>> I don't like this very much: if we want to disable stubdoms by default
> >>> with all configs, then I would prefer to simply add --disable-stubdom to
> >>> components/xen without introducing XEN_CONFIG_EXTRA.
> >>>
> >>> Otherwise if we want to give users the chance to add an extra config
> >>> option, I would introduce a generic way to do that, so that people can
> >>> use it with any components they want, QEMU, libvirt, etc.
> >>
> >> You did notice that this config option is disabled by default, right?  I
> >> added the line commented-out as an example of the sort of thing you
> >> might want to do.
> >>
> >> I don't think we want to disable stubdoms by default across the board.
> >>
> >> I wouldn't object to adding empty config variables to the other
> >> components; I just don't have a good way to test them at the moment.
> >  
> > What if we just add an environmental variable named as
> > COMPONENT_BUILD_CONFIGURE at the end of the configure line when
> > appropriate?  Of course it would need to be documented in the README.
> 
> Isn't this exactly the same as my patch, but
> 1) With a different name, and
> 2) No examples in the config files?
> 
> I don't mind #1, but #2 seems like the most logical place to document it.

OK :-)
Please don't make it xen specific though.



> 
> > 
> > Something like:
> > 
> > 
> > diff --git a/components/qemu b/components/qemu
> > index dce4ce0..0e57bdb 100644
> > --- a/components/qemu
> > +++ b/components/qemu
> > @@ -27,7 +27,7 @@ function qemu_build() {
> >          --disable-docs \
> >          --bindir=$PREFIX/lib/xen/bin \
> >          --datadir=$PREFIX/share/qemu-xen \
> > -        --disable-guest-agent
> > +        --disable-guest-agent $QEMU_BUILD_CONFIGURE
> >      $RAISIN_MAKE all
> >      $RAISIN_MAKE install DESTDIR="$INST_DIR"
> >      cd "$BASEDIR"
> > diff --git a/components/xen b/components/xen
> > index 6b700e5..01527ec 100644
> > --- a/components/xen
> > +++ b/components/xen
> > @@ -39,7 +39,7 @@ function xen_build() {
> >          ovmf_opt="--enable-ovmf --with-system-ovmf="$BASEDIR"/ovmf-dir/ovmf.bin"
> >      fi
> >      ./configure --prefix=$PREFIX --with-system-qemu=$PREFIX/lib/xen/bin/qemu-system-i386 \
> > -        --disable-qemu-traditional --enable-rombios $seabios_opt $ovmf_opt
> > +        --disable-qemu-traditional --enable-rombios $seabios_opt $ovmf_opt $XEN_BUILD_CONFIGURE
> >      $RAISIN_MAKE
> >      $RAISIN_MAKE install DESTDIR="$INST_DIR"
> >      cd "$BASEDIR"
> > 
>