Date   

[PATCH V2] ceph: set CXXFLAGS and CFLAGS

sakib.sajal@...
 

In oe-core, the commit:
a83623a54a Revert "cmake.bbclass: Set CXXFLAGS and CFLAGS"

drops compiler flags overrides for all cmake-based recipes,
causing the ceph compile to fail with the error:
ld: cannot find crtn.o: No such file or directory

collect2: error: ld returned 1 exit status

Add the override back for ceph to fix the build error.

Signed-off-by: Sakib Sajal <sakib.sajal@...>
---
recipes-extended/ceph/ceph_15.2.15.bb | 3 +++
1 file changed, 3 insertions(+)

diff --git a/recipes-extended/ceph/ceph_15.2.15.bb b/recipes-extended/ceph/ceph_15.2.15.bb
index c72953a..17dbcf3 100644
--- a/recipes-extended/ceph/ceph_15.2.15.bb
+++ b/recipes-extended/ceph/ceph_15.2.15.bb
@@ -66,6 +66,9 @@ EXTRA_OECMAKE = "-DWITH_MANPAGE=OFF \
-DWITH_REENTRANT_STRSIGNAL=ON \
"

+CXXFLAGS += "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}"
+CFLAGS += "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}"
+
export STAGING_DIR_HOST

do_configure:prepend () {
--
2.25.1


Re: [PATCH] ceph: set CXXFLAGS and CFLAGS

Bruce Ashfield
 



On Wed, Mar 16, 2022 at 12:22 PM Randy MacLeod <randy.macleod@...> wrote:
On 2022-03-16 11:20, sakib.sajal@... wrote:
> commit a83623a54a375d3ae9198a135b94379881a2b7a5 was added
> to oe-core which removes

The phrase:
    "was added ... which removes"
is awkward. As a student of Strunk and White, I suggest:

---
In oe-core, the commit:
    a83623a54a Revert "cmake.bbclass: Set CXXFLAGS and CFLAGS"

drops compiler flags overrides for all cmake-based recipes,
causing the ceph compile to fail with the error:
   ld: cannot find crtn.o: No such file or directory

   collect2: error: ld returned 1 exit status


Add the override back for ceph to fix the build error.

---

It's always good to include the key parts of the error log
so that someone can search the commit logs for help given
a keyword.

Bruce,

Did/does this error show up in your meta-virt testing?

I'm seeing it now as well. I've been working on a few things, so my testing against oe-core was at an older commit.

So the change is likely good, but I'm waiting for a v2 with Randy's suggested re-wording.

Bruce



> CXXFLAGS and CFLAGS causing
> compilation for ceph to fail.
>
> Set CXXFLAGS and CFLAGS to resolve the issue.
>
> Signed-off-by: Sakib Sajal <sakib.sajal@...>
> ---
>   recipes-extended/ceph/ceph_15.2.15.bb | 3 +++
>   1 file changed, 3 insertions(+)
>
> diff --git a/recipes-extended/ceph/ceph_15.2.15.bb b/recipes-extended/ceph/ceph_15.2.15.bb
> index c72953a..17dbcf3 100644
> --- a/recipes-extended/ceph/ceph_15.2.15.bb
> +++ b/recipes-extended/ceph/ceph_15.2.15.bb
> @@ -66,6 +66,9 @@ EXTRA_OECMAKE = "-DWITH_MANPAGE=OFF \
>                    -DWITH_REENTRANT_STRSIGNAL=ON \
>   "
>   
> +CXXFLAGS += "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}"
> +CFLAGS += "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}"

Does ceph need both of the _ARCH and _OPTIONS to be set?
Since the error is at link time, try adding only TOOLCHAIN_OPTIONS
as is done for:

recipes-core/runx/runx_git.bb

97:        export CFLAGS="${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS} ${CFLAGS}"

98:        export LDFLAGS="${TOOLCHAIN_OPTIONS} ${HOST_LD_ARCH} ${LDFLAGS}"




../Randy

> +
>   export STAGING_DIR_HOST
>   
>   do_configure:prepend () {
>
>
>
>
>


--
# Randy MacLeod
# Wind River Linux



--
- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


Re: Loading the module xen-gntdev on boot

Paulo Sherring
 

Hello Diego, Bertrand,
Just confirmed that by bringing these changes into hardknott, the
modules get correctly probed on bootup.

The xen.conf content, just for completeness:
xen-evtchn
xen-gntdev
xen-gntalloc
xen-blkback
xen-netback
xen-pciback
evtchn
gntdev
netbk
blkbk
xen-scsibk
usbbk
pciback

Thanks for the support :)
Kind regards, Paulo.

On Tue, Mar 22, 2022 at 3:30 PM Diego Sueiro <Diego.Sueiro@...> wrote:

The xen modules load from systemd was fixed in master as https://git.yoctoproject.org/meta-virtualization/commit/?id=44dad5105d408e7b6217600eba3672e72db0f42f and honister as https://git.yoctoproject.org/meta-virtualization/commit/?h=honister&id=6cde8f2ccbde5ecc9997cf727939a0ae5e0fe11d.

You might need to backport this to hardknott as well.

--
Diego Sueiro
Staff Software Developer - Automotive and Industrial Solutions (CE-OSS)

-----Original Message-----
From: meta-virtualization@... <meta-
virtualization@...> On Behalf Of Bertrand Marquis via
lists.yoctoproject.org
Sent: 22 March 2022 15:23
To: Paulo Sherring <pauloasherring@...>
Cc: meta-virtualization@...; nd <nd@...>; Bruce
Ashfield <bruce.ashfield@...>
Subject: Re: [meta-virtualization] Loading the module xen-gntdev on boot

Hi Paulo,

On 22 Mar 2022, at 16:01, Paulo Sherring <pauloasherring@...>
wrote:

Hi Bertrand,
One very important piece of information I missed to disclose: I am not
using runqemu, as it was not being properly set by the resulting
bitbake build (the resulting image was pointing to the kernel instead
of the xen binary).
This should not impact the module loading.


So, I am launching it "by hand":

./tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-nativ
e/usr/bin/qemu-system-aarch64
\
-nographic \
-machine virt,gic-version=3 \
-machine virtualization=true \
-cpu cortex-a57 -smp 4 -m 4G -machine type=virt \ -bios
./tmp/deploy/images/qemuarm64/u-boot-qemuarm64.bin \ -device
loader,file=./tmp/deploy/images/qemuarm64/xen-
qemuarm64,addr=0x4500000
0
\
-device
loader,file=./tmp/deploy/images/qemuarm64/Image--
5.10.103+git0+792f127
2dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x46000000
\
-device
loader,file=./tmp/deploy/images/qemuarm64/Image--
5.10.103+git0+792f127
2dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x48000000
\
-device loader,file=./virt.dtb,addr=0x44000000 \ -drive
id=disk0,file=./tmp/deploy/images/qemuarm64/xen-image-minimal-
qemuarm6
4.ext4,if=none,index=0,format=raw
\
-device virtio-blk-device,drive=disk0 \

And then stop it on u-boot, and setup the fdt:
## Dom0 only:
fdt addr 0x44000000
fdt resize
fdt set /chosen \#address-cells <1>
fdt set /chosen \#size-cells <1>
fdt set /chosen xen,xen-bootargs "dom0_mem=512M"
fdt mknod /chosen module@0
fdt set /chosen/module@0 compatible "xen,linux-zimage" "xen,multiboot-
module"
fdt set /chosen/module@0 reg <0x46000000 0x1373a00> fdt set
/chosen/module@0 bootargs "dom0_mem=512M root=/dev/vda rw
earlyprintk=serial,ttyAMA0 console=ttyAMA0,115200n8 earlycon=xenboot"
booti 0x45000000 - 0x44000000

Please find also some more information below:

On Tue, Mar 22, 2022 at 12:59 PM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

Hardknott is long term while honister is not but both are stable releases.

I am not quite sure I get your 4.14 pulling 4.16. The 4.14 recipe is building
the latest 4.14 version of Xen.
That was just me being silly. I was looking into xen_git.bb which
clearly is not the preferred provider. I am in fact using Xen 4.14, as
you pointed out. Sorry for the mistake.
From what I see modules to load are in a xen.conf in modules-load.d
generated by Xen tools compilation.
Gntdev is properly listed in the current xen source tree as one of the
default modules to actually load on boot.

Can you check the content of modules-load.d/xen.conf (somewhere in /etc
in your dom0 roots) ?
I have nothing there. But, I did have two hits when searching the rootfs:
/etc/tmpfiles.d/xen.conf
/lib/systemd/modules-load.d/xen.conf
This is the interesting file.
It shall be used by systemd on boot to load the modules required by Xen.
Please check if gntdev is listed there.

If yes then this is a systemd issue, if not this is a Xen issue which appear to be
solved in xen master and I will have to check in the 4.14 version used by Yocto
LTS.


Not sure if there there is some sort of startup script that was
supposed to move around these files or even if
systemd-modules-load.service would be supposed to be looking
elsewhere.
No the lib one is the right one for systemd.

Cheers
Bertrand

It could be that this was actually missing in the xen release you are building
or that systemd is not actually loading modules listed there.

Cheers
Bertrand
Cheers, Paulo.


Re: Loading the module xen-gntdev on boot

Diego Sueiro
 

The xen modules load from systemd was fixed in master as https://git.yoctoproject.org/meta-virtualization/commit/?id=44dad5105d408e7b6217600eba3672e72db0f42f and honister as https://git.yoctoproject.org/meta-virtualization/commit/?h=honister&id=6cde8f2ccbde5ecc9997cf727939a0ae5e0fe11d.

You might need to backport this to hardknott as well.

--
Diego Sueiro
Staff Software Developer - Automotive and Industrial Solutions (CE-OSS)

-----Original Message-----
From: meta-virtualization@... <meta-
virtualization@...> On Behalf Of Bertrand Marquis via
lists.yoctoproject.org
Sent: 22 March 2022 15:23
To: Paulo Sherring <pauloasherring@...>
Cc: meta-virtualization@...; nd <nd@...>; Bruce
Ashfield <bruce.ashfield@...>
Subject: Re: [meta-virtualization] Loading the module xen-gntdev on boot

Hi Paulo,

On 22 Mar 2022, at 16:01, Paulo Sherring <pauloasherring@...>
wrote:

Hi Bertrand,
One very important piece of information I missed to disclose: I am not
using runqemu, as it was not being properly set by the resulting
bitbake build (the resulting image was pointing to the kernel instead
of the xen binary).
This should not impact the module loading.


So, I am launching it "by hand":

./tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-nativ
e/usr/bin/qemu-system-aarch64
\
-nographic \
-machine virt,gic-version=3 \
-machine virtualization=true \
-cpu cortex-a57 -smp 4 -m 4G -machine type=virt \ -bios
./tmp/deploy/images/qemuarm64/u-boot-qemuarm64.bin \ -device
loader,file=./tmp/deploy/images/qemuarm64/xen-
qemuarm64,addr=0x4500000
0
\
-device
loader,file=./tmp/deploy/images/qemuarm64/Image--
5.10.103+git0+792f127
2dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x46000000
\
-device
loader,file=./tmp/deploy/images/qemuarm64/Image--
5.10.103+git0+792f127
2dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x48000000
\
-device loader,file=./virt.dtb,addr=0x44000000 \ -drive
id=disk0,file=./tmp/deploy/images/qemuarm64/xen-image-minimal-
qemuarm6
4.ext4,if=none,index=0,format=raw
\
-device virtio-blk-device,drive=disk0 \

And then stop it on u-boot, and setup the fdt:
## Dom0 only:
fdt addr 0x44000000
fdt resize
fdt set /chosen \#address-cells <1>
fdt set /chosen \#size-cells <1>
fdt set /chosen xen,xen-bootargs "dom0_mem=512M"
fdt mknod /chosen module@0
fdt set /chosen/module@0 compatible "xen,linux-zimage" "xen,multiboot-
module"
fdt set /chosen/module@0 reg <0x46000000 0x1373a00> fdt set
/chosen/module@0 bootargs "dom0_mem=512M root=/dev/vda rw
earlyprintk=serial,ttyAMA0 console=ttyAMA0,115200n8 earlycon=xenboot"
booti 0x45000000 - 0x44000000

Please find also some more information below:

On Tue, Mar 22, 2022 at 12:59 PM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

Hardknott is long term while honister is not but both are stable releases.

I am not quite sure I get your 4.14 pulling 4.16. The 4.14 recipe is building
the latest 4.14 version of Xen.
That was just me being silly. I was looking into xen_git.bb which
clearly is not the preferred provider. I am in fact using Xen 4.14, as
you pointed out. Sorry for the mistake.
From what I see modules to load are in a xen.conf in modules-load.d
generated by Xen tools compilation.
Gntdev is properly listed in the current xen source tree as one of the
default modules to actually load on boot.

Can you check the content of modules-load.d/xen.conf (somewhere in /etc
in your dom0 roots) ?
I have nothing there. But, I did have two hits when searching the rootfs:
/etc/tmpfiles.d/xen.conf
/lib/systemd/modules-load.d/xen.conf
This is the interesting file.
It shall be used by systemd on boot to load the modules required by Xen.
Please check if gntdev is listed there.

If yes then this is a systemd issue, if not this is a Xen issue which appear to be
solved in xen master and I will have to check in the 4.14 version used by Yocto
LTS.


Not sure if there there is some sort of startup script that was
supposed to move around these files or even if
systemd-modules-load.service would be supposed to be looking
elsewhere.
No the lib one is the right one for systemd.

Cheers
Bertrand

It could be that this was actually missing in the xen release you are building
or that systemd is not actually loading modules listed there.

Cheers
Bertrand
Cheers, Paulo.


Re: Loading the module xen-gntdev on boot

Bertrand Marquis
 

Hi Paulo,

On 22 Mar 2022, at 16:01, Paulo Sherring <pauloasherring@...> wrote:

Hi Bertrand,
One very important piece of information I missed to disclose: I am not
using runqemu,
as it was not being properly set by the resulting bitbake build (the
resulting image was
pointing to the kernel instead of the xen binary).
This should not impact the module loading.


So, I am launching it "by hand":

./tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/qemu-system-aarch64
\
-nographic \
-machine virt,gic-version=3 \
-machine virtualization=true \
-cpu cortex-a57 -smp 4 -m 4G -machine type=virt \
-bios ./tmp/deploy/images/qemuarm64/u-boot-qemuarm64.bin \
-device loader,file=./tmp/deploy/images/qemuarm64/xen-qemuarm64,addr=0x45000000
\
-device loader,file=./tmp/deploy/images/qemuarm64/Image--5.10.103+git0+792f1272dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x46000000
\
-device loader,file=./tmp/deploy/images/qemuarm64/Image--5.10.103+git0+792f1272dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x48000000
\
-device loader,file=./virt.dtb,addr=0x44000000 \
-drive id=disk0,file=./tmp/deploy/images/qemuarm64/xen-image-minimal-qemuarm64.ext4,if=none,index=0,format=raw
\
-device virtio-blk-device,drive=disk0 \

And then stop it on u-boot, and setup the fdt:
## Dom0 only:
fdt addr 0x44000000
fdt resize
fdt set /chosen \#address-cells <1>
fdt set /chosen \#size-cells <1>
fdt set /chosen xen,xen-bootargs "dom0_mem=512M"
fdt mknod /chosen module@0
fdt set /chosen/module@0 compatible "xen,linux-zimage" "xen,multiboot-module"
fdt set /chosen/module@0 reg <0x46000000 0x1373a00>
fdt set /chosen/module@0 bootargs "dom0_mem=512M root=/dev/vda rw
earlyprintk=serial,ttyAMA0 console=ttyAMA0,115200n8 earlycon=xenboot"
booti 0x45000000 - 0x44000000

Please find also some more information below:

On Tue, Mar 22, 2022 at 12:59 PM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

Hardknott is long term while honister is not but both are stable releases.

I am not quite sure I get your 4.14 pulling 4.16. The 4.14 recipe is building the latest 4.14 version of Xen.
That was just me being silly. I was looking into xen_git.bb which
clearly is not the preferred provider. I am in fact using Xen 4.14, as
you pointed out. Sorry for the mistake.
From what I see modules to load are in a xen.conf in modules-load.d generated by Xen tools compilation.
Gntdev is properly listed in the current xen source tree as one of the default modules to actually load on boot.

Can you check the content of modules-load.d/xen.conf (somewhere in /etc in your dom0 roots) ?
I have nothing there. But, I did have two hits when searching the rootfs:
/etc/tmpfiles.d/xen.conf
/lib/systemd/modules-load.d/xen.conf
This is the interesting file.
It shall be used by systemd on boot to load the modules required by Xen.
Please check if gntdev is listed there.

If yes then this is a systemd issue, if not this is a Xen issue which appear to be solved in xen master and I will have to check in the 4.14 version used by Yocto LTS.


Not sure if there there is some sort of startup script that was
supposed to move around these files
or even if systemd-modules-load.service would be supposed to be
looking elsewhere.
No the lib one is the right one for systemd.

Cheers
Bertrand

It could be that this was actually missing in the xen release you are building or that systemd is not actually loading modules listed there.

Cheers
Bertrand
Cheers, Paulo.


Re: Loading the module xen-gntdev on boot

Paulo Sherring
 

Hi Bertrand,
One very important piece of information I missed to disclose: I am not
using runqemu,
as it was not being properly set by the resulting bitbake build (the
resulting image was
pointing to the kernel instead of the xen binary).

So, I am launching it "by hand":

./tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/qemu-system-aarch64
\
-nographic \
-machine virt,gic-version=3 \
-machine virtualization=true \
-cpu cortex-a57 -smp 4 -m 4G -machine type=virt \
-bios ./tmp/deploy/images/qemuarm64/u-boot-qemuarm64.bin \
-device loader,file=./tmp/deploy/images/qemuarm64/xen-qemuarm64,addr=0x45000000
\
-device loader,file=./tmp/deploy/images/qemuarm64/Image--5.10.103+git0+792f1272dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x46000000
\
-device loader,file=./tmp/deploy/images/qemuarm64/Image--5.10.103+git0+792f1272dd_3aab5bb12b-r0-qemuarm64-20220317212819.bin,addr=0x48000000
\
-device loader,file=./virt.dtb,addr=0x44000000 \
-drive id=disk0,file=./tmp/deploy/images/qemuarm64/xen-image-minimal-qemuarm64.ext4,if=none,index=0,format=raw
\
-device virtio-blk-device,drive=disk0 \

And then stop it on u-boot, and setup the fdt:
## Dom0 only:
fdt addr 0x44000000
fdt resize
fdt set /chosen \#address-cells <1>
fdt set /chosen \#size-cells <1>
fdt set /chosen xen,xen-bootargs "dom0_mem=512M"
fdt mknod /chosen module@0
fdt set /chosen/module@0 compatible "xen,linux-zimage" "xen,multiboot-module"
fdt set /chosen/module@0 reg <0x46000000 0x1373a00>
fdt set /chosen/module@0 bootargs "dom0_mem=512M root=/dev/vda rw
earlyprintk=serial,ttyAMA0 console=ttyAMA0,115200n8 earlycon=xenboot"
booti 0x45000000 - 0x44000000

Please find also some more information below:

On Tue, Mar 22, 2022 at 12:59 PM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

Hardknott is long term while honister is not but both are stable releases.

I am not quite sure I get your 4.14 pulling 4.16. The 4.14 recipe is building the latest 4.14 version of Xen.
That was just me being silly. I was looking into xen_git.bb which
clearly is not the preferred provider. I am in fact using Xen 4.14, as
you pointed out. Sorry for the mistake.
From what I see modules to load are in a xen.conf in modules-load.d generated by Xen tools compilation.
Gntdev is properly listed in the current xen source tree as one of the default modules to actually load on boot.

Can you check the content of modules-load.d/xen.conf (somewhere in /etc in your dom0 roots) ?
I have nothing there. But, I did have two hits when searching the rootfs:
/etc/tmpfiles.d/xen.conf
/lib/systemd/modules-load.d/xen.conf
Not sure if there there is some sort of startup script that was
supposed to move around these files
or even if systemd-modules-load.service would be supposed to be
looking elsewhere.

It could be that this was actually missing in the xen release you are building or that systemd is not actually loading modules listed there.

Cheers
Bertrand
Cheers, Paulo.

____

On 22 Mar 2022, at 13:38, Paulo Sherring <pauloasherring@...> wrote:

Hello Bertrand,

On Tue, Mar 22, 2022 at 12:28 PM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

Please always keep the mailing list in as me asking the questions does not mean I will necessarily be the one working on this.
Oops, my mistake, sorry.

Please see some questions here after.

On 22 Mar 2022, at 12:03, Paulo Sherring <pauloasherring@...> wrote:

Hello Bertrand,

On Tue, Mar 22, 2022 at 10:44 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

On 22 Mar 2022, at 11:33, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:

Hello all,
I am a bit new to meta-virtualization and to the Xen project And to
virtualizations, so please bear with me :)
I've been trying to make use of the xen project, currently targeting
qemu (and later on, rpi4). After messing around, I was able to boot
dom0 and a domU.
But, I had to add the xen-gntdev to the `modules-load.d,` because
`xenstored` was failing to start, due to some missing connection,
probably brought up by xen-gntdev module.

As I am new to all this, I was just wondering if this is by design, or
this is an issue (and therefore, I should/could submit a patch).
No problem at all and thanks a lot for the feedback.
This should not happen and should be fixed.

Could you tell us what you are building (which image) and what parameters did you set in your local.conf ?
- Baseline is hardknott.
Any reason not to use honester ?
The main reason was that hardknott is tagged as a stable release and
it already includes xen 4.14 or latest (it is actually pulling 4.16),
which I wanted/will need for RPi4 support.


Re: Loading the module xen-gntdev on boot

Bertrand Marquis
 

Hi Paulo,

On 22 Mar 2022, at 13:38, Paulo Sherring <pauloasherring@...> wrote:

Hello Bertrand,

On Tue, Mar 22, 2022 at 12:28 PM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

Please always keep the mailing list in as me asking the questions does not mean I will necessarily be the one working on this.
Oops, my mistake, sorry.

Please see some questions here after.

On 22 Mar 2022, at 12:03, Paulo Sherring <pauloasherring@...> wrote:

Hello Bertrand,

On Tue, Mar 22, 2022 at 10:44 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

On 22 Mar 2022, at 11:33, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:

Hello all,
I am a bit new to meta-virtualization and to the Xen project And to
virtualizations, so please bear with me :)
I've been trying to make use of the xen project, currently targeting
qemu (and later on, rpi4). After messing around, I was able to boot
dom0 and a domU.
But, I had to add the xen-gntdev to the `modules-load.d,` because
`xenstored` was failing to start, due to some missing connection,
probably brought up by xen-gntdev module.

As I am new to all this, I was just wondering if this is by design, or
this is an issue (and therefore, I should/could submit a patch).
No problem at all and thanks a lot for the feedback.
This should not happen and should be fixed.

Could you tell us what you are building (which image) and what parameters did you set in your local.conf ?
- Baseline is hardknott.
Any reason not to use honester ?
The main reason was that hardknott is tagged as a stable release and
it already includes xen 4.14 or latest (it is actually pulling 4.16),
which I wanted/will need for RPi4 support.
Hardknott is long term while honister is not but both are stable releases.

I am not quite sure I get your 4.14 pulling 4.16. The 4.14 recipe is building the latest 4.14 version of Xen.

From what I see modules to load are in a xen.conf in modules-load.d generated by Xen tools compilation.
Gntdev is properly listed in the current xen source tree as one of the default modules to actually load on boot.

Can you check the content of modules-load.d/xen.conf (somewhere in /etc in your dom0 roots) ?

It could be that this was actually missing in the xen release you are building or that systemd is not actually loading modules listed there.

Cheers
Bertrand


Re: Loading the module xen-gntdev on boot

Paulo Sherring
 

Hello Bertrand,

On Tue, Mar 22, 2022 at 12:28 PM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

Please always keep the mailing list in as me asking the questions does not mean I will necessarily be the one working on this.
Oops, my mistake, sorry.

Please see some questions here after.

On 22 Mar 2022, at 12:03, Paulo Sherring <pauloasherring@...> wrote:

Hello Bertrand,

On Tue, Mar 22, 2022 at 10:44 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

On 22 Mar 2022, at 11:33, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:

Hello all,
I am a bit new to meta-virtualization and to the Xen project And to
virtualizations, so please bear with me :)
I've been trying to make use of the xen project, currently targeting
qemu (and later on, rpi4). After messing around, I was able to boot
dom0 and a domU.
But, I had to add the xen-gntdev to the `modules-load.d,` because
`xenstored` was failing to start, due to some missing connection,
probably brought up by xen-gntdev module.

As I am new to all this, I was just wondering if this is by design, or
this is an issue (and therefore, I should/could submit a patch).
No problem at all and thanks a lot for the feedback.
This should not happen and should be fixed.

Could you tell us what you are building (which image) and what parameters did you set in your local.conf ?
- Baseline is hardknott.
Any reason not to use honester ?
The main reason was that hardknott is tagged as a stable release and
it already includes xen 4.14 or latest (it is actually pulling 4.16),
which I wanted/will need for RPi4 support.

The rest of the configuration sounds about right.
I will check why gntdev is not in.

- Target image is xen-minimal-image (for the host)
- On local.conf, I have

require xen-host.conf
and the contents of such file is https://paste.debian.net/1235220/

(Also below, just in case the link expires:)

Thanks for the prompt answer.
Kind regards, Paulo.

## Machine Definitions:
MACHINE = "qemuarm64"

## Generate ext4 rootfs for manual handling:
IMAGE_FSTYPES:append = " ext4"

## Virtualization:
DISTRO_FEATURES:append = " virtualization xen"
IMAGE_INSTALL:append = " xen xen-tools"

## Kernel stuff:
IMAGE_INSTALL:append = " kernel-modules"

# Extra Packages:
EXTRA_IMAGE_FEATURES = "debug-tweaks"
EXTRA_IMAGE_FEATURES:append = " tools-sdk"
EXTRA_IMAGE_FEATURES:append = " tools-debug"
EXTRA_IMAGE_FEATURES:append = " eclipse-debug"
IMAGE_INSTALL:append = " nano findutils tree openssh"


## Wayland stuff
DISTRO_FEATURES:remove = " x11"
DISTRO_FEATURES:append = " opengl wayland pam"

## Systemd stuff
DISTRO_FEATURES:append = " systemd pam "
VIRTUAL-RUNTIME_init_manager = "systemd"
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
VIRTUAL-RUNTIME_initscripts = " systemd-compat-units"

## Connman:
IMAGE_INSTALL:append = " connman \
connman-client \
connman-static-ip \
"

EXTRA_IMAGEDEPENDS += "u-boot"
UBOOT_ELF = "u-boot"


IMAGE_INSTALL:append = " lvm2 bridge-utils"

## Extra space for fitting VMs:
IMAGE_ROOTFS_EXTRA_SPACE = "5242880"

Cheers
Bertrand
Thanks and kind regards, Paulo.


Re: Loading the module xen-gntdev on boot

Bertrand Marquis
 

Hi Paulo,

Please always keep the mailing list in as me asking the questions does not mean I will necessarily be the one working on this.

Please see some questions here after.

On 22 Mar 2022, at 12:03, Paulo Sherring <pauloasherring@...> wrote:

Hello Bertrand,

On Tue, Mar 22, 2022 at 10:44 AM Bertrand Marquis
<Bertrand.Marquis@...> wrote:

Hi Paulo,

On 22 Mar 2022, at 11:33, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:

Hello all,
I am a bit new to meta-virtualization and to the Xen project And to
virtualizations, so please bear with me :)
I've been trying to make use of the xen project, currently targeting
qemu (and later on, rpi4). After messing around, I was able to boot
dom0 and a domU.
But, I had to add the xen-gntdev to the `modules-load.d,` because
`xenstored` was failing to start, due to some missing connection,
probably brought up by xen-gntdev module.

As I am new to all this, I was just wondering if this is by design, or
this is an issue (and therefore, I should/could submit a patch).
No problem at all and thanks a lot for the feedback.
This should not happen and should be fixed.

Could you tell us what you are building (which image) and what parameters did you set in your local.conf ?
- Baseline is hardknott.
Any reason not to use honester ?

The rest of the configuration sounds about right.
I will check why gntdev is not in.

- Target image is xen-minimal-image (for the host)
- On local.conf, I have

require xen-host.conf
and the contents of such file is https://paste.debian.net/1235220/

(Also below, just in case the link expires:)

Thanks for the prompt answer.
Kind regards, Paulo.

## Machine Definitions:
MACHINE = "qemuarm64"

## Generate ext4 rootfs for manual handling:
IMAGE_FSTYPES:append = " ext4"

## Virtualization:
DISTRO_FEATURES:append = " virtualization xen"
IMAGE_INSTALL:append = " xen xen-tools"

## Kernel stuff:
IMAGE_INSTALL:append = " kernel-modules"

# Extra Packages:
EXTRA_IMAGE_FEATURES = "debug-tweaks"
EXTRA_IMAGE_FEATURES:append = " tools-sdk"
EXTRA_IMAGE_FEATURES:append = " tools-debug"
EXTRA_IMAGE_FEATURES:append = " eclipse-debug"
IMAGE_INSTALL:append = " nano findutils tree openssh"


## Wayland stuff
DISTRO_FEATURES:remove = " x11"
DISTRO_FEATURES:append = " opengl wayland pam"

## Systemd stuff
DISTRO_FEATURES:append = " systemd pam "
VIRTUAL-RUNTIME_init_manager = "systemd"
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
VIRTUAL-RUNTIME_initscripts = " systemd-compat-units"

## Connman:
IMAGE_INSTALL:append = " connman \
connman-client \
connman-static-ip \
"

EXTRA_IMAGEDEPENDS += "u-boot"
UBOOT_ELF = "u-boot"


IMAGE_INSTALL:append = " lvm2 bridge-utils"

## Extra space for fitting VMs:
IMAGE_ROOTFS_EXTRA_SPACE = "5242880"

Cheers
Bertrand


Re: Loading the module xen-gntdev on boot

Bertrand Marquis
 

Hi Paulo,

On 22 Mar 2022, at 11:33, Paulo Sherring via lists.yoctoproject.org <pauloasherring=gmail.com@...> wrote:

Hello all,
I am a bit new to meta-virtualization and to the Xen project And to
virtualizations, so please bear with me :)
I've been trying to make use of the xen project, currently targeting
qemu (and later on, rpi4). After messing around, I was able to boot
dom0 and a domU.
But, I had to add the xen-gntdev to the `modules-load.d,` because
`xenstored` was failing to start, due to some missing connection,
probably brought up by xen-gntdev module.

As I am new to all this, I was just wondering if this is by design, or
this is an issue (and therefore, I should/could submit a patch).
No problem at all and thanks a lot for the feedback.
This should not happen and should be fixed.

Could you tell us what you are building (which image) and what parameters did you set in your local.conf ?

Kind regards
Bertrand


Kind regards, Paulo


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Loading the module xen-gntdev on boot

Paulo Sherring
 

Hello all,
I am a bit new to meta-virtualization and to the Xen project And to
virtualizations, so please bear with me :)
I've been trying to make use of the xen project, currently targeting
qemu (and later on, rpi4). After messing around, I was able to boot
dom0 and a domU.
But, I had to add the xen-gntdev to the `modules-load.d,` because
`xenstored` was failing to start, due to some missing connection,
probably brought up by xen-gntdev module.

As I am new to all this, I was just wondering if this is by design, or
this is an issue (and therefore, I should/could submit a patch).

Kind regards, Paulo


Re: [PATCH] ceph: set CXXFLAGS and CFLAGS

Randy MacLeod
 

On 2022-03-16 11:20, sakib.sajal@... wrote:
commit a83623a54a375d3ae9198a135b94379881a2b7a5 was added
to oe-core which removes
The phrase:
"was added ... which removes"
is awkward. As a student of Strunk and White, I suggest:

---
In oe-core, the commit:
a83623a54a Revert "cmake.bbclass: Set CXXFLAGS and CFLAGS"

drops compiler flags overrides for all cmake-based recipes,
causing the ceph compile to fail with the error:
ld: cannot find crtn.o: No such file or directory

collect2: error: ld returned 1 exit status


Add the override back for ceph to fix the build error.

---

It's always good to include the key parts of the error log
so that someone can search the commit logs for help given
a keyword.

Bruce,

Did/does this error show up in your meta-virt testing?


CXXFLAGS and CFLAGS causing
compilation for ceph to fail.
Set CXXFLAGS and CFLAGS to resolve the issue.
Signed-off-by: Sakib Sajal <sakib.sajal@...>
---
recipes-extended/ceph/ceph_15.2.15.bb | 3 +++
1 file changed, 3 insertions(+)
diff --git a/recipes-extended/ceph/ceph_15.2.15.bb b/recipes-extended/ceph/ceph_15.2.15.bb
index c72953a..17dbcf3 100644
--- a/recipes-extended/ceph/ceph_15.2.15.bb
+++ b/recipes-extended/ceph/ceph_15.2.15.bb
@@ -66,6 +66,9 @@ EXTRA_OECMAKE = "-DWITH_MANPAGE=OFF \
-DWITH_REENTRANT_STRSIGNAL=ON \
"
+CXXFLAGS += "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}"
+CFLAGS += "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}"
Does ceph need both of the _ARCH and _OPTIONS to be set?
Since the error is at link time, try adding only TOOLCHAIN_OPTIONS
as is done for:

recipes-core/runx/runx_git.bb

97: export CFLAGS="${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS} ${CFLAGS}"

98: export LDFLAGS="${TOOLCHAIN_OPTIONS} ${HOST_LD_ARCH} ${LDFLAGS}"




../Randy

+
export STAGING_DIR_HOST
do_configure:prepend () {

--
# Randy MacLeod
# Wind River Linux


[PATCH] ceph: set CXXFLAGS and CFLAGS

sakib.sajal@...
 

commit a83623a54a375d3ae9198a135b94379881a2b7a5 was added
to oe-core which removes CXXFLAGS and CFLAGS causing
compilation for ceph to fail.

Set CXXFLAGS and CFLAGS to resolve the issue.

Signed-off-by: Sakib Sajal <sakib.sajal@...>
---
recipes-extended/ceph/ceph_15.2.15.bb | 3 +++
1 file changed, 3 insertions(+)

diff --git a/recipes-extended/ceph/ceph_15.2.15.bb b/recipes-extended/ceph/ceph_15.2.15.bb
index c72953a..17dbcf3 100644
--- a/recipes-extended/ceph/ceph_15.2.15.bb
+++ b/recipes-extended/ceph/ceph_15.2.15.bb
@@ -66,6 +66,9 @@ EXTRA_OECMAKE = "-DWITH_MANPAGE=OFF \
-DWITH_REENTRANT_STRSIGNAL=ON \
"

+CXXFLAGS += "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}"
+CFLAGS += "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}"
+
export STAGING_DIR_HOST

do_configure:prepend () {
--
2.33.0


Re: [PATCH] xen: Override CC and CPP in make command line

Bruce Ashfield
 



On Fri, Mar 11, 2022 at 3:57 AM Bertrand Marquis <Bertrand.Marquis@...> wrote:
Hi Bruce,

> On 10 Mar 2022, at 19:43, Bruce Ashfield via lists.yoctoproject.org <bruce.ashfield=gmail.com@...> wrote:
>
> I've merged the patch, if Christopher has any review comments or needs
> changes, we'll stack them on top.

Could this be also added in honister branch ?


No problem. I did the cherry pick.

Bruce

 
Thanks
Bertrand

>
> Bruce
>
> In message: [meta-virtualization] [PATCH] xen: Override CC and CPP in make command line
> on 09/03/2022 Bertrand Marquis wrote:
>
>> From: Michal Orzel <michal.orzel@...>
>>
>> After 4.16 release, Xen build system has been changed significantly.
>> When building latest status of Xen it was observed that commit
>> 317c98cb91 broke the hypervisor build on arm32 due to the change in
>> handling Rules.mk that xen.inc modifies to override CC and CPP.
>>
>> In order to fix the issue this patch moves overriding CC and CPP from
>> Rules.mk to make command line by adding them to EXTRA_OEMAKE:arm.
>>
>> Take the opportunity to bump SRCREV of xen_git.bb and xen-tools_git.bb
>> to the current status of master.
>>
>> Signed-off-by: Michal Orzel <michal.orzel@...>
>> ---
>> recipes-extended/xen/xen-hypervisor.inc | 8 ++++++++
>> recipes-extended/xen/xen-tools_git.bb   | 4 ++--
>> recipes-extended/xen/xen.inc            | 6 ------
>> recipes-extended/xen/xen_git.bb         | 4 ++--
>> 4 files changed, 12 insertions(+), 10 deletions(-)
>>
>> diff --git a/recipes-extended/xen/xen-hypervisor.inc b/recipes-extended/xen/xen-hypervisor.inc
>> index 81e361f..6f3d24d 100644
>> --- a/recipes-extended/xen/xen-hypervisor.inc
>> +++ b/recipes-extended/xen/xen-hypervisor.inc
>> @@ -48,6 +48,14 @@ do_configure() {
>>     fi
>> }
>>
>> +# The hypervisor binary for arm must not be built with the hard floating point
>> +# ABI. Override CC and CPP when invoking make so that they do not contain
>> +# TUNE_CCARGS.
>> +EXTRA_OEMAKE:arm += "CC='${CCACHE}${HOST_PREFIX}gcc ${TOOLCHAIN_OPTIONS} \
>> +                         ${CC_REPRODUCIBLE_OPTIONS}' \
>> +                     CPP='${CCACHE}${HOST_PREFIX}gcc -E ${TOOLCHAIN_OPTIONS} \
>> +                         ${CC_REPRODUCIBLE_OPTIONS}'"
>> +
>> do_compile() {
>>     oe_runmake xen PYTHON="${PYTHON}" \
>>                    EXTRA_CFLAGS_XEN_CORE="${EXTRA_CFLAGS_XEN_CORE}"
>> diff --git a/recipes-extended/xen/xen-tools_git.bb b/recipes-extended/xen/xen-tools_git.bb
>> index 8ff9c4c..e733f1d 100644
>> --- a/recipes-extended/xen/xen-tools_git.bb
>> +++ b/recipes-extended/xen/xen-tools_git.bb
>> @@ -1,5 +1,5 @@
>> -# master status on 2020-10-21
>> -SRCREV ?= "23ec1ebc8acbfd2bf06f6085a776f0db923f9fa9"
>> +# master status on 2022-03-08
>> +SRCREV ?= "9d4a44380d273de22d5753883cbf5581795ff24d"
>>
>> XEN_REL ?= "4.16"
>> XEN_BRANCH ?= "master"
>> diff --git a/recipes-extended/xen/xen.inc b/recipes-extended/xen/xen.inc
>> index 4df99bf..8b86de5 100644
>> --- a/recipes-extended/xen/xen.inc
>> +++ b/recipes-extended/xen/xen.inc
>> @@ -193,12 +193,6 @@ do_post_patch() {
>>     fi
>> }
>>
>> -do_post_patch:append:arm()  {
>> -    # The hypervisor binary must not be built with the hard floating point ABI.
>> -    echo "CC := \$(filter-out ${TUNE_CCARGS},\$(CC))" >> ${S}/xen/arch/arm/Rules.mk
>> -    echo "CPP := \$(filter-out ${TUNE_CCARGS},\$(CPP))" >> ${S}/xen/arch/arm/Rules.mk
>> -}
>> -
>> addtask post_patch after do_patch before do_configure
>>
>> # Allow all hypervisor settings in a defconfig
>> diff --git a/recipes-extended/xen/xen_git.bb b/recipes-extended/xen/xen_git.bb
>> index e014733..2fbfb54 100644
>> --- a/recipes-extended/xen/xen_git.bb
>> +++ b/recipes-extended/xen/xen_git.bb
>> @@ -1,5 +1,5 @@
>> -# master status on 2020-10-21
>> -SRCREV ?= "23ec1ebc8acbfd2bf06f6085a776f0db923f9fa9"
>> +# master status on 2022-03-08
>> +SRCREV ?= "9d4a44380d273de22d5753883cbf5581795ff24d"
>>
>> XEN_REL ?= "4.16"
>> XEN_BRANCH ?= "master"
>> --
>> 2.25.1
>>
>
>>
>>
>>
>
>
>
>



--
- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


Re: [PATCH] cloud-init: inherit setuptools3_legacy

Bruce Ashfield
 

merged

Bruce

On Thu, Mar 10, 2022 at 11:20 PM Tim Orling <ticotimo@...> wrote:
cloud-init still requires legacy setup.py behavior.

Signed-off-by: Tim Orling <tim.orling@...>
---
 recipes-extended/cloud-init/cloud-init_21.4.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-extended/cloud-init/cloud-init_21.4.bb b/recipes-extended/cloud-init/cloud-init_21.4.bb
index 37cf303..f549db9 100644
--- a/recipes-extended/cloud-init/cloud-init_21.4.bb
+++ b/recipes-extended/cloud-init/cloud-init_21.4.bb
@@ -22,7 +22,7 @@ do_install:append() {
 }

 inherit pkgconfig
-inherit setuptools3
+inherit setuptools3_legacy
 inherit update-rc.d
 inherit systemd

--
2.30.2






--
- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


Re: [PATCH] xen: Override CC and CPP in make command line

Bertrand Marquis
 

Hi Bruce,

On 10 Mar 2022, at 19:43, Bruce Ashfield via lists.yoctoproject.org <bruce.ashfield=gmail.com@...> wrote:

I've merged the patch, if Christopher has any review comments or needs
changes, we'll stack them on top.
Could this be also added in honister branch ?

Thanks
Bertrand


Bruce

In message: [meta-virtualization] [PATCH] xen: Override CC and CPP in make command line
on 09/03/2022 Bertrand Marquis wrote:

From: Michal Orzel <michal.orzel@...>

After 4.16 release, Xen build system has been changed significantly.
When building latest status of Xen it was observed that commit
317c98cb91 broke the hypervisor build on arm32 due to the change in
handling Rules.mk that xen.inc modifies to override CC and CPP.

In order to fix the issue this patch moves overriding CC and CPP from
Rules.mk to make command line by adding them to EXTRA_OEMAKE:arm.

Take the opportunity to bump SRCREV of xen_git.bb and xen-tools_git.bb
to the current status of master.

Signed-off-by: Michal Orzel <michal.orzel@...>
---
recipes-extended/xen/xen-hypervisor.inc | 8 ++++++++
recipes-extended/xen/xen-tools_git.bb | 4 ++--
recipes-extended/xen/xen.inc | 6 ------
recipes-extended/xen/xen_git.bb | 4 ++--
4 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/recipes-extended/xen/xen-hypervisor.inc b/recipes-extended/xen/xen-hypervisor.inc
index 81e361f..6f3d24d 100644
--- a/recipes-extended/xen/xen-hypervisor.inc
+++ b/recipes-extended/xen/xen-hypervisor.inc
@@ -48,6 +48,14 @@ do_configure() {
fi
}

+# The hypervisor binary for arm must not be built with the hard floating point
+# ABI. Override CC and CPP when invoking make so that they do not contain
+# TUNE_CCARGS.
+EXTRA_OEMAKE:arm += "CC='${CCACHE}${HOST_PREFIX}gcc ${TOOLCHAIN_OPTIONS} \
+ ${CC_REPRODUCIBLE_OPTIONS}' \
+ CPP='${CCACHE}${HOST_PREFIX}gcc -E ${TOOLCHAIN_OPTIONS} \
+ ${CC_REPRODUCIBLE_OPTIONS}'"
+
do_compile() {
oe_runmake xen PYTHON="${PYTHON}" \
EXTRA_CFLAGS_XEN_CORE="${EXTRA_CFLAGS_XEN_CORE}"
diff --git a/recipes-extended/xen/xen-tools_git.bb b/recipes-extended/xen/xen-tools_git.bb
index 8ff9c4c..e733f1d 100644
--- a/recipes-extended/xen/xen-tools_git.bb
+++ b/recipes-extended/xen/xen-tools_git.bb
@@ -1,5 +1,5 @@
-# master status on 2020-10-21
-SRCREV ?= "23ec1ebc8acbfd2bf06f6085a776f0db923f9fa9"
+# master status on 2022-03-08
+SRCREV ?= "9d4a44380d273de22d5753883cbf5581795ff24d"

XEN_REL ?= "4.16"
XEN_BRANCH ?= "master"
diff --git a/recipes-extended/xen/xen.inc b/recipes-extended/xen/xen.inc
index 4df99bf..8b86de5 100644
--- a/recipes-extended/xen/xen.inc
+++ b/recipes-extended/xen/xen.inc
@@ -193,12 +193,6 @@ do_post_patch() {
fi
}

-do_post_patch:append:arm() {
- # The hypervisor binary must not be built with the hard floating point ABI.
- echo "CC := \$(filter-out ${TUNE_CCARGS},\$(CC))" >> ${S}/xen/arch/arm/Rules.mk
- echo "CPP := \$(filter-out ${TUNE_CCARGS},\$(CPP))" >> ${S}/xen/arch/arm/Rules.mk
-}
-
addtask post_patch after do_patch before do_configure

# Allow all hypervisor settings in a defconfig
diff --git a/recipes-extended/xen/xen_git.bb b/recipes-extended/xen/xen_git.bb
index e014733..2fbfb54 100644
--- a/recipes-extended/xen/xen_git.bb
+++ b/recipes-extended/xen/xen_git.bb
@@ -1,5 +1,5 @@
-# master status on 2020-10-21
-SRCREV ?= "23ec1ebc8acbfd2bf06f6085a776f0db923f9fa9"
+# master status on 2022-03-08
+SRCREV ?= "9d4a44380d273de22d5753883cbf5581795ff24d"

XEN_REL ?= "4.16"
XEN_BRANCH ?= "master"
--
2.25.1





[PATCH] cloud-init: inherit setuptools3_legacy

Tim Orling
 

cloud-init still requires legacy setup.py behavior.

Signed-off-by: Tim Orling <tim.orling@...>
---
recipes-extended/cloud-init/cloud-init_21.4.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-extended/cloud-init/cloud-init_21.4.bb b/recipes-extended/cloud-init/cloud-init_21.4.bb
index 37cf303..f549db9 100644
--- a/recipes-extended/cloud-init/cloud-init_21.4.bb
+++ b/recipes-extended/cloud-init/cloud-init_21.4.bb
@@ -22,7 +22,7 @@ do_install:append() {
}

inherit pkgconfig
-inherit setuptools3
+inherit setuptools3_legacy
inherit update-rc.d
inherit systemd

--
2.30.2


Re: [meta-virt][PATCH 1/1] libvert: modify dependencies on lxc_protocol.h

Joe Slater
 

I have never seen the failure. This is from a build that did see it.

NOTE: recipe qemu-6.2.0-r0: task do_package_qa: Succeeded
NOTE: recipe libvirt-7.2.0-r0: task do_configure: Succeeded
NOTE: Running task 7977 of 8013 (/buildarea1/master-wr/build/Benchmark/customized_systemd/220308-063739/lxbuilds/builder_platform_up/intel-x86-64-preempt-rt-ovp-kvm/wrlinux/layers/meta-virtualization/recipes-extended/libvirt/libvirt_7.2.0.bb:do_compile)
NOTE: recipe libvirt-7.2.0-r0: task do_compile: Started
ERROR: libvirt-7.2.0-r0 do_compile: ExecutionError('/buildarea1/master-wr/build/Benchmark/customized_systemd/220308-063739/lxbuilds/builder_platform_up/intel-x86-64-preempt-rt-ovp-kvm/wrlinux/build/tmp-glibc/work/corei7-64-wrs-linux/libvirt/7.2.0-r0/temp/run.do_compile.3629283', 1, None, None)
Transferring /buildarea1/master-wr/build/Benchmark/customized_systemd/220308-063739/lxbuilds/builder_platform_up/intel-x86-64-preempt-rt-ovp-kvm/wrlinux/build/tmp-glibc/work/corei7-64-wrs-linux/libvirt/7.2.0-r0/temp/log.do_compile.3629283 to /buildarea1/master-wr/log/Benchmark/intel-x86-64/customized_systemd/builder_preempt-rt_ovp-kvm_OE_systemd/220308-063739/boottime/intel-x86-64_platform/builder.None.preemptrt.true.ovpkvm.lpgbuildcdcWASSP_LINUX_MASTER_WRtestcaseswrlinuxutilsfrags/errorlogs
ERROR: Logfile of failure stored in: /buildarea1/master-wr/build/Benchmark/customized_systemd/220308-063739/lxbuilds/builder_platform_up/intel-x86-64-preempt-rt-ovp-kvm/wrlinux/build/tmp-glibc/work/corei7-64-wrs-linux/libvirt/7.2.0-r0/temp/log.do_compile.3629283
Log data follows:
| DEBUG: Executing shell function do_compile
| [1/1274] Generating src/esx/virtesxgensources with a custom command
| [2/1274] Generating src/rpc/virkeepaliveprotocol.h with a custom command
| [3/1274] Generating src/rpc/virkeepaliveprotocol.c with a custom command
...
Wold-style-definition -Wopenmp-simd -Woverflow -Woverride-init -Wpacked-bitfield-compat -Wpacked-not-aligned -Wparentheses -Wpointer-arith -Wpointer-compare -Wpointer-sign -Wpointer-to-int-cast -Wpragmas -Wpsabi -Wrestrict -Wreturn-local-addr -Wreturn-type -Wscalar-storage-order -Wsequence-point -Wshadow -Wshift-count-negative -Wshift-count-overflow -Wshift-negative-value -Wsizeof-array-argument -Wsizeof-pointer-div -Wsizeof-pointer-memaccess -Wstrict-aliasing -Wstrict-prototypes -Wstringop-truncation -Wsuggest-attribute=cold -Wsuggest-attribute=const -Wsuggest-attribute=format -Wsuggest-attribute=noreturn -Wsuggest-attribute=pure -Wsuggest-final-methods -Wsuggest-final-types -Wswitch -Wswitch-bool -Wswitch-unreachable -Wsync-nand -Wtautological-compare -Wtrampolines -Wtrigraphs -Wtype-limits -Wuninitialized -Wunknown-pragmas -Wunused -Wunused-but-set-parameter -Wunused-but-set-variable -Wunused-function -Wunused-label -Wunused-local-typedefs -Wunused-parameter -Wunused-result -Wunused-value -Wunused-variable -Wvarargs -Wvariadic-macros -Wvector-operation-performance -Wvla -Wvolatile-register-var -Wwrite-strings -Walloc-size-larger-than=9223372036854775807 -Warray-bounds=2 -Wattribute-alias=2 -Wformat-overflow=2 -Wformat-truncation=2 -Wimplicit-fallthrough=5 -Wnormalized=nfc -Wshift-overflow=2 -Wstringop-overflow=2 -Wunused-const-variable=2 -Wno-sign-compare -Wno-cast-function-type -Wjump-misses-init -Wswitch-enum -Wno-format-nonliteral -Wno-format-truncation -Wframe-larger-than=4096 -fexceptions -fasynchronous-unwind-tables -fipa-pure-const -Wno-suggest-attribute=pure -Wno-suggest-attribute=const -fstack-protector-strong -Wdouble-promotion -O2 -pipe -g -feliminate-unused-debug-types -fmacro-prefix-map=/buildarea1/master-wr/build/Benchmark/customized_systemd/220308-063739/lxbuilds/builder_platform_up/intel-x86-64-preempt-rt-ovp-kvm/wrlinux/build/tmp-glibc/work/corei7-64-wrs-linux/libvirt/7.2.0-r0=/usr/src/debug/libvirt/7.2.0-r0 -fdebug-prefix-map=/buildarea1/master-wr/build/Benchmark/customized_systemd/220308-063739/lxbuilds/builder_platform_up/intel-x86-64-preempt-rt-ovp-kvm/wrlinux/build/tmp-glibc/work/corei7-64-wrs-linux/libvirt/7.2.0-r0=/usr/src/debug/libvirt/7.2.0-r0 -fdebug-prefix-map=/buildarea1/master-wr/build/Benchmark/customized_systemd/220308-063739/lxbuilds/builder_platform_up/intel-x86-64-preempt-rt-ovp-kvm/wrlinux/build/tmp-glibc/work/corei7-64-wrs-linux/libvirt/7.2.0-r0/recipe-sysroot= -fdebug-prefix-map=/buildarea1/master-wr/build/Benchmark/customized_systemd/220308-063739/lxbuilds/builder_platform_up/intel-x86-64-preempt-rt-ovp-kvm/wrlinux/build/tmp-glibc/work/corei7-64-wrs-linux/libvirt/7.2.0-r0/recipe-sysroot-native= -fPIE -pthread -DIN_LIBVIRT '-Dabs_top_builddir="/buildarea1/master-wr/build/Benchmark/customized_systemd/220308-063739/lxbuilds/builder_platform_up/intel-x86-64-preempt-rt-ovp-kvm/wrlinux/build/tmp-glibc/work/corei7-64-wrs-linux/libvirt/7.2.0-r0/build"' '-Dabs_top_srcdir="/buildarea1/master-wr/build/Benchmark/customized_systemd/220308-063739/lxbuilds/builder_platform_up/intel-x86-64-preempt-rt-ovp-kvm/wrlinux/build/tmp-glibc/work/corei7-64-wrs-linux/libvirt/7.2.0-r0/libvirt-7.2.0"' '-DDAEMON_NAME="virtstoraged"' '-DMODULE_NAME="storage"' -MD -MQ src/virtstoraged.p/remote_remote_daemon.c.o -MF src/virtstoraged.p/remote_remote_daemon.c.o.d -o src/virtstoraged.p/remote_remote_daemon.c.o -c ../libvirt-7.2.0/src/remote/remote_daemon.c
| In file included from ../libvirt-7.2.0/src/remote/remote_daemon.c:39:
| ../libvirt-7.2.0/src/remote/remote_daemon.h:29:10: fatal error: lxc_protocol.h: No such file or directory
| 29 | #include "lxc_protocol.h"
| | ^~~~~~~~~~~~~~~~
| compilation terminated.
| [293/1274] Compiling C object src/admin/libvirt_admin_driver.a.p/meson-generated_.._admin_protocol.c.o
| [294/1274] Linking static target src/node_device/libvirt_driver_nodedev_impl.a
| [295/1274] Compiling C object src/admin/libvirt_admin_driver.a.p/admin_server.c.o
| [296/1274] Linking static target src/security/libvirt_security_manager.a
| [297/1274] Compiling C object src/openvz/libvirt_openvz.a.p/openvz_conf.c.o
| [298/1274] Compiling C object src/qemu/libvirt_driver_qemu_impl.a.p/qemu_alias.c.o
| [299/1274] Compiling C object src/esx/libvirt_driver_esx.a.p/esx_network_driver.c.o
| [300/1274] Compiling C object src/hypervisor/libvirt_hypervisor.a.p/virhostdev.c.o
| [301/1274] Compiling C object src/qemu/libvirt_driver_qemu_impl.a.p/qemu_interop_config.c.o
| [302/1274] Compiling C object src/admin/libvirt_admin_driver.a.p/admin_server_dispatch.c.o
| [303/1274] Compiling C object src/lxc/libvirt_driver_lxc_impl.a.p/lxc_monitor.c.o
| [304/1274] Compiling C object src/qemu/libvirt_driver_qemu_impl.a.p/qemu_hostdev.c.o
| [305/1274] Compiling C object src/lxc/libvirt_driver_lxc_impl.a.p/lxc_hostdev.c.o
| [306/1274] Compiling C object src/qemu/libvirt_driver_qemu_impl.a.p/qemu_virtiofs.c.o
| [307/1274] Compiling C object src/esx/libvirt_driver_esx.a.p/esx_storage_backend_iscsi.c.o
| [308/1274] Compiling C object src/qemu/libvirt_driver_qemu_impl.a.p/qemu_qapi.c.o
...

You have to look at the ninja.build file to see that remote_daemon.c.o is not dependent on lxc_protocol.h
existing. But, remote_driver.c.o does have the dependency.

I haven't sent it upstream yet.

Joe

-----Original Message-----
From: Bruce Ashfield <bruce.ashfield@...>
Sent: Thursday, March 10, 2022 11:42 AM
To: Slater, Joseph <joe.slater@...>
Cc: meta-virtualization@...; MacLeod, Randy
<Randy.MacLeod@...>
Subject: Re: [meta-virtualization] [meta-virt][PATCH 1/1] libvert: modify
dependencies on lxc_protocol.h

s/libvert/libvirt/

In message: [meta-virtualization] [meta-virt][PATCH 1/1] libvert: modify
dependencies on lxc_protocol.h on 10/03/2022 Joe Slater wrote:

src/remote/meson.build does not create a dependency on the generated
lxc_protocol.h for remote_daemon.c. Restructure how this file is
generated to allow the dependency.
Can you document the configuration (i.e. packageconfigs, etc) that are causing
this ? I'm not seeing the same thing, so something different is going on.


Signed-off-by: Joe Slater <joe.slater@...>
---
.../libvirt/libvirt/lxc_protocol.patch | 104 ++++++++++++++++++
recipes-extended/libvirt/libvirt_7.2.0.bb | 1 +
2 files changed, 105 insertions(+)
create mode 100644
recipes-extended/libvirt/libvirt/lxc_protocol.patch

diff --git a/recipes-extended/libvirt/libvirt/lxc_protocol.patch
b/recipes-extended/libvirt/libvirt/lxc_protocol.patch
new file mode 100644
index 00000000..595c3fe4
--- /dev/null
+++ b/recipes-extended/libvirt/libvirt/lxc_protocol.patch
@@ -0,0 +1,104 @@
+From 38af66c1a9c4cdeb256eeaf563c6807757c370ce Mon Sep 17 00:00:00
+2001
+From: Joe Slater <joe.slater@...>
+Date: Wed, 9 Mar 2022 23:17:33 +0000
+Subject: [PATCH] working commit
+
+remote_daemon.c and others need the generated header lxc_protocol.h,
+but do not have it as a dependency in meson.build. This means that
+builds will randomly (ok, very occasionally) fail. Restructure how
+the header is built so that remote_daemon can have it as a dependency.
+
+Upstream-Status: Pending
Is there a link to the upstream submission ? That way we can follow along ?

Bruce

+
+Signed-off-by: Joe Slater <joe.slater@...>
+
+---
+ src/remote/meson.build | 48
+++++++++++++++++++++++++------------------
+ 1 file changed, 28 insertions(+), 20 deletions(-)
+
+diff --git a/src/remote/meson.build b/src/remote/meson.build index
+0a18826..31a30ee 100644
+--- a/src/remote/meson.build
++++ b/src/remote/meson.build
+@@ -1,27 +1,11 @@
+-remote_driver_sources = [
+- 'remote_driver.c',
+- 'remote_sockets.c',
+-]
+-
+-remote_driver_generated = []
++remote_xxx_generated = []
+
+ foreach name : [ 'remote', 'qemu', 'lxc' ]
+- client_bodies_h = '@0@...'.format(name)
+ protocol_c = '@0@...'.format(name)
+ protocol_h = '@0@...'.format(name)
+ protocol_x = '@0@...'.format(name)
+
+- remote_driver_generated += custom_target(
+- client_bodies_h,
+- input: protocol_x,
+- output: client_bodies_h,
+- command: [
+- gendispatch_prog, '--mode=client', name, name.to_upper(), '@INPUT@',
+- ],
+- capture: true,
+- )
+-
+- remote_driver_generated += custom_target(
++ remote_xxx_generated += custom_target(
+ protocol_h,
+ input: protocol_x,
+ output: protocol_h,
+@@ -30,7 +14,7 @@ foreach name : [ 'remote', 'qemu', 'lxc' ]
+ ],
+ )
+
+- remote_driver_generated += custom_target(
++ remote_xxx_generated += custom_target(
+ protocol_c,
+ input: protocol_x,
+ output: protocol_c,
+@@ -42,6 +26,30 @@ foreach name : [ 'remote', 'qemu', 'lxc' ]
+ rpc_probe_files += files(protocol_x) endforeach
+
++
++remote_driver_sources = [
++ 'remote_driver.c',
++ 'remote_sockets.c',
++]
++
++remote_driver_generated =remote_xxx_generated
++
++foreach name : [ 'remote', 'qemu', 'lxc' ]
++ client_bodies_h = '@0@...'.format(name)
++ protocol_x = '@0@...'.format(name)
++
++ remote_driver_generated += custom_target(
++ client_bodies_h,
++ input: protocol_x,
++ output: client_bodies_h,
++ command: [
++ gendispatch_prog, '--mode=client', name, name.to_upper(),
'@INPUT@',
++ ],
++ capture: true,
++ )
++
++endforeach
++
+ remote_daemon_sources = files(
+ 'remote_daemon.c',
+ 'remote_daemon_config.c',
+@@ -49,7 +57,7 @@ remote_daemon_sources = files(
+ 'remote_daemon_stream.c',
+ )
+
+-remote_daemon_generated = []
++remote_daemon_generated = remote_xxx_generated
+
+ virt_ssh_helper_sources = files(
+ 'remote_sockets.c',
+--
+2.32.0
+
diff --git a/recipes-extended/libvirt/libvirt_7.2.0.bb
b/recipes-extended/libvirt/libvirt_7.2.0.bb
index 5ad7d59e..04c66eb5 100644
--- a/recipes-extended/libvirt/libvirt_7.2.0.bb
+++ b/recipes-extended/libvirt/libvirt_7.2.0.bb
@@ -31,6 +31,7 @@ SRC_URI = "http://libvirt.org/sources/libvirt-
${PV}.tar.xz;name=libvirt \
file://0002-meson-Fix-compatibility-with-Meson-0.58.patch \
file://0001-security-fix-SELinux-label-generation-logic.patch \

file://0001-storage_driver-Unlock-object-on-ACL-fail-in-storageP.patch
\
+ file://lxc_protocol.patch \
"

SRC_URI[libvirt.md5sum] = "92044b629216e44adce63224970a54a3"
--
2.35.1



Re: [meta-cloud-services][PATCH] layer.conf: Update to kirkstone namespace

Bruce Ashfield
 

merged.

Bruce

In message: [meta-virtualization][meta-cloud-services][PATCH] layer.conf: Update to kirkstone namespace
on 10/03/2022 wangmy wrote:

Signed-off-by: Wang Mingyu <wangmy@...>
---
meta-openstack/conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-openstack/conf/layer.conf b/meta-openstack/conf/layer.conf
index bd5a8ac7..b112030f 100644
--- a/meta-openstack/conf/layer.conf
+++ b/meta-openstack/conf/layer.conf
@@ -7,7 +7,7 @@ BBFILES += "${LAYERDIR}/recipes*/*/*.bb ${LAYERDIR}/recipes*/*/*.bbappend"
BBFILE_COLLECTIONS += "openstack-layer"
BBFILE_PATTERN_openstack-layer := "^${LAYERDIR}/"
BBFILE_PRIORITY_openstack-layer = "5"
-LAYERSERIES_COMPAT_openstack-layer = "honister"
+LAYERSERIES_COMPAT_openstack-layer = "kirkstone"
BB_DANGLINGAPPENDS_WARNONLY ?= "true"

LAYERDEPENDS_openstack-layer = " \
--
2.25.1



Re: [PATCH] xen: Override CC and CPP in make command line

Bruce Ashfield
 

I've merged the patch, if Christopher has any review comments or needs
changes, we'll stack them on top.

Bruce

In message: [meta-virtualization] [PATCH] xen: Override CC and CPP in make command line
on 09/03/2022 Bertrand Marquis wrote:

From: Michal Orzel <michal.orzel@...>

After 4.16 release, Xen build system has been changed significantly.
When building latest status of Xen it was observed that commit
317c98cb91 broke the hypervisor build on arm32 due to the change in
handling Rules.mk that xen.inc modifies to override CC and CPP.

In order to fix the issue this patch moves overriding CC and CPP from
Rules.mk to make command line by adding them to EXTRA_OEMAKE:arm.

Take the opportunity to bump SRCREV of xen_git.bb and xen-tools_git.bb
to the current status of master.

Signed-off-by: Michal Orzel <michal.orzel@...>
---
recipes-extended/xen/xen-hypervisor.inc | 8 ++++++++
recipes-extended/xen/xen-tools_git.bb | 4 ++--
recipes-extended/xen/xen.inc | 6 ------
recipes-extended/xen/xen_git.bb | 4 ++--
4 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/recipes-extended/xen/xen-hypervisor.inc b/recipes-extended/xen/xen-hypervisor.inc
index 81e361f..6f3d24d 100644
--- a/recipes-extended/xen/xen-hypervisor.inc
+++ b/recipes-extended/xen/xen-hypervisor.inc
@@ -48,6 +48,14 @@ do_configure() {
fi
}

+# The hypervisor binary for arm must not be built with the hard floating point
+# ABI. Override CC and CPP when invoking make so that they do not contain
+# TUNE_CCARGS.
+EXTRA_OEMAKE:arm += "CC='${CCACHE}${HOST_PREFIX}gcc ${TOOLCHAIN_OPTIONS} \
+ ${CC_REPRODUCIBLE_OPTIONS}' \
+ CPP='${CCACHE}${HOST_PREFIX}gcc -E ${TOOLCHAIN_OPTIONS} \
+ ${CC_REPRODUCIBLE_OPTIONS}'"
+
do_compile() {
oe_runmake xen PYTHON="${PYTHON}" \
EXTRA_CFLAGS_XEN_CORE="${EXTRA_CFLAGS_XEN_CORE}"
diff --git a/recipes-extended/xen/xen-tools_git.bb b/recipes-extended/xen/xen-tools_git.bb
index 8ff9c4c..e733f1d 100644
--- a/recipes-extended/xen/xen-tools_git.bb
+++ b/recipes-extended/xen/xen-tools_git.bb
@@ -1,5 +1,5 @@
-# master status on 2020-10-21
-SRCREV ?= "23ec1ebc8acbfd2bf06f6085a776f0db923f9fa9"
+# master status on 2022-03-08
+SRCREV ?= "9d4a44380d273de22d5753883cbf5581795ff24d"

XEN_REL ?= "4.16"
XEN_BRANCH ?= "master"
diff --git a/recipes-extended/xen/xen.inc b/recipes-extended/xen/xen.inc
index 4df99bf..8b86de5 100644
--- a/recipes-extended/xen/xen.inc
+++ b/recipes-extended/xen/xen.inc
@@ -193,12 +193,6 @@ do_post_patch() {
fi
}

-do_post_patch:append:arm() {
- # The hypervisor binary must not be built with the hard floating point ABI.
- echo "CC := \$(filter-out ${TUNE_CCARGS},\$(CC))" >> ${S}/xen/arch/arm/Rules.mk
- echo "CPP := \$(filter-out ${TUNE_CCARGS},\$(CPP))" >> ${S}/xen/arch/arm/Rules.mk
-}
-
addtask post_patch after do_patch before do_configure

# Allow all hypervisor settings in a defconfig
diff --git a/recipes-extended/xen/xen_git.bb b/recipes-extended/xen/xen_git.bb
index e014733..2fbfb54 100644
--- a/recipes-extended/xen/xen_git.bb
+++ b/recipes-extended/xen/xen_git.bb
@@ -1,5 +1,5 @@
-# master status on 2020-10-21
-SRCREV ?= "23ec1ebc8acbfd2bf06f6085a776f0db923f9fa9"
+# master status on 2022-03-08
+SRCREV ?= "9d4a44380d273de22d5753883cbf5581795ff24d"

XEN_REL ?= "4.16"
XEN_BRANCH ?= "master"
--
2.25.1


441 - 460 of 7539