| Message ID | 20201103164604.2692357-3-philmd@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | ci: Move --without-default-devices job from Travis to GitLab | expand |
On Tue, Nov 03, 2020 at 05:46:03PM +0100, Philippe Mathieu-Daudé wrote: > We test './configure --without-default-devices' since commit > 20885b5b169 (".travis.yml: test that no-default-device builds > do not regress") in Travis-CI. > > As we prefer to use GitLab-CI, add the equivalent job there. > > One minor difference: the GitLab Ubuntu docker image has the > Xen devel packages installed. As it is automatically selected, > we need to disable it with the --disable-xen option, else the > build fails: > > /usr/bin/ld: libcommon.fa.p/hw_xen_xen-legacy-backend.c.o: in function `xen_be_register_common': > hw/xen/xen-legacy-backend.c:754: undefined reference to `xen_9pfs_ops' > /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x8): undefined reference to `local_ops' > /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x20): undefined reference to `synth_ops' > /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x38): undefined reference to `proxy_ops' > collect2: error: ld returned 1 exit status Surely this is a build bug we need to fix rather than ignore in CI ? Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 11/3/20 5:52 PM, Daniel P. Berrangé wrote: > On Tue, Nov 03, 2020 at 05:46:03PM +0100, Philippe Mathieu-Daudé wrote: >> We test './configure --without-default-devices' since commit >> 20885b5b169 (".travis.yml: test that no-default-device builds >> do not regress") in Travis-CI. >> >> As we prefer to use GitLab-CI, add the equivalent job there. >> >> One minor difference: the GitLab Ubuntu docker image has the >> Xen devel packages installed. As it is automatically selected, >> we need to disable it with the --disable-xen option, else the >> build fails: >> >> /usr/bin/ld: libcommon.fa.p/hw_xen_xen-legacy-backend.c.o: in function `xen_be_register_common': >> hw/xen/xen-legacy-backend.c:754: undefined reference to `xen_9pfs_ops' >> /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x8): undefined reference to `local_ops' >> /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x20): undefined reference to `synth_ops' >> /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x38): undefined reference to `proxy_ops' >> collect2: error: ld returned 1 exit status > > Surely this is a build bug we need to fix rather than ignore in CI ? Well it predates this series, so nobody really cared (thus I wonder if it makes sense to invest resources there). Anyway I can have a look after 5.2-rc1.
On 11/3/20 5:46 PM, Philippe Mathieu-Daudé wrote: > We test './configure --without-default-devices' since commit > 20885b5b169 (".travis.yml: test that no-default-device builds > do not regress") in Travis-CI. > > As we prefer to use GitLab-CI, add the equivalent job there. > > One minor difference: the GitLab Ubuntu docker image has the > Xen devel packages installed. As it is automatically selected, > we need to disable it with the --disable-xen option, else the > build fails: > > /usr/bin/ld: libcommon.fa.p/hw_xen_xen-legacy-backend.c.o: in function `xen_be_register_common': > hw/xen/xen-legacy-backend.c:754: undefined reference to `xen_9pfs_ops' > /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x8): undefined reference to `local_ops' > /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x20): undefined reference to `synth_ops' > /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x38): undefined reference to `proxy_ops' > collect2: error: ld returned 1 exit status > > Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> > --- > .gitlab-ci.yml | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml > index 3b15ae5c302..6ee098ec53c 100644 > --- a/.gitlab-ci.yml > +++ b/.gitlab-ci.yml > @@ -262,6 +262,17 @@ build-user-plugins: > MAKE_CHECK_ARGS: check-tcg > timeout: 1h 30m > > +build-system-ubuntu-without-default-devices: > + <<: *native_build_job_definition > + variables: > + IMAGE: ubuntu2004 > + CONFIGURE_ARGS: --without-default-devices --disable-user --disable-xen --disable-tools --disable-docs > + MAKE_CHECK_ARGS: check-build The part below is pointless, as no job consume these artifacts. I'll remove it in the next iteration. > + artifacts: > + expire_in: 2 days > + paths: > + - build > + > build-clang: > <<: *native_build_job_definition > variables: >
On Tue, Nov 03, 2020 at 06:01:12PM +0100, Philippe Mathieu-Daudé wrote: > On 11/3/20 5:52 PM, Daniel P. Berrangé wrote: > > On Tue, Nov 03, 2020 at 05:46:03PM +0100, Philippe Mathieu-Daudé wrote: > >> We test './configure --without-default-devices' since commit > >> 20885b5b169 (".travis.yml: test that no-default-device builds > >> do not regress") in Travis-CI. > >> > >> As we prefer to use GitLab-CI, add the equivalent job there. > >> > >> One minor difference: the GitLab Ubuntu docker image has the > >> Xen devel packages installed. As it is automatically selected, > >> we need to disable it with the --disable-xen option, else the > >> build fails: > >> > >> /usr/bin/ld: libcommon.fa.p/hw_xen_xen-legacy-backend.c.o: in function `xen_be_register_common': > >> hw/xen/xen-legacy-backend.c:754: undefined reference to `xen_9pfs_ops' > >> /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x8): undefined reference to `local_ops' > >> /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x20): undefined reference to `synth_ops' > >> /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x38): undefined reference to `proxy_ops' > >> collect2: error: ld returned 1 exit status > > > > Surely this is a build bug we need to fix rather than ignore in CI ? > > Well it predates this series, so nobody really cared > (thus I wonder if it makes sense to invest resources > there). > > Anyway I can have a look after 5.2-rc1. Can you just put a comment in the .gitlab-ci.yml file stating that the --disable-xen arg is a short term workaround that needs to be fixed properly Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
I forgot to Cc the 9pfs & Xen maintainers, doing it now ;) On 11/3/20 6:01 PM, Philippe Mathieu-Daudé wrote: > On 11/3/20 5:52 PM, Daniel P. Berrangé wrote: >> On Tue, Nov 03, 2020 at 05:46:03PM +0100, Philippe Mathieu-Daudé wrote: >>> We test './configure --without-default-devices' since commit >>> 20885b5b169 (".travis.yml: test that no-default-device builds >>> do not regress") in Travis-CI. >>> >>> As we prefer to use GitLab-CI, add the equivalent job there. >>> >>> One minor difference: the GitLab Ubuntu docker image has the >>> Xen devel packages installed. As it is automatically selected, >>> we need to disable it with the --disable-xen option, else the >>> build fails: >>> >>> /usr/bin/ld: libcommon.fa.p/hw_xen_xen-legacy-backend.c.o: in function `xen_be_register_common': >>> hw/xen/xen-legacy-backend.c:754: undefined reference to `xen_9pfs_ops' >>> /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x8): undefined reference to `local_ops' >>> /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x20): undefined reference to `synth_ops' >>> /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x38): undefined reference to `proxy_ops' >>> collect2: error: ld returned 1 exit status >> >> Surely this is a build bug we need to fix rather than ignore in CI ? > > Well it predates this series, so nobody really cared > (thus I wonder if it makes sense to invest resources > there). > > Anyway I can have a look after 5.2-rc1. >
On 03/11/2020 17.46, Philippe Mathieu-Daudé wrote: > We test './configure --without-default-devices' since commit > 20885b5b169 (".travis.yml: test that no-default-device builds > do not regress") in Travis-CI. > > As we prefer to use GitLab-CI, add the equivalent job there. > > One minor difference: the GitLab Ubuntu docker image has the > Xen devel packages installed. As it is automatically selected, > we need to disable it with the --disable-xen option, else the > build fails: > > /usr/bin/ld: libcommon.fa.p/hw_xen_xen-legacy-backend.c.o: in function `xen_be_register_common': > hw/xen/xen-legacy-backend.c:754: undefined reference to `xen_9pfs_ops' > /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x8): undefined reference to `local_ops' > /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x20): undefined reference to `synth_ops' > /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x38): undefined reference to `proxy_ops' > collect2: error: ld returned 1 exit status > > Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> > --- > .gitlab-ci.yml | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml > index 3b15ae5c302..6ee098ec53c 100644 > --- a/.gitlab-ci.yml > +++ b/.gitlab-ci.yml > @@ -262,6 +262,17 @@ build-user-plugins: > MAKE_CHECK_ARGS: check-tcg > timeout: 1h 30m > > +build-system-ubuntu-without-default-devices: > + <<: *native_build_job_definition > + variables: > + IMAGE: ubuntu2004 > + CONFIGURE_ARGS: --without-default-devices --disable-user --disable-xen --disable-tools --disable-docs > + MAKE_CHECK_ARGS: check-build AFAIK "check-build" is pretty much a no-op since the convertion to meson ... could you maybe replace with a set of qtest targets that work, to make sure that we do not regress here? E.g.: MAKE_CHECK_ARGS: check-qtest-avr check-qtestcris check-qtest-m68k check-qtest-microblaze check-qtest-mipsel check-qtest-moxie ... Thomas
On 11/3/20 7:43 PM, Thomas Huth wrote: > On 03/11/2020 17.46, Philippe Mathieu-Daudé wrote: >> We test './configure --without-default-devices' since commit >> 20885b5b169 (".travis.yml: test that no-default-device builds >> do not regress") in Travis-CI. >> >> As we prefer to use GitLab-CI, add the equivalent job there. >> >> One minor difference: the GitLab Ubuntu docker image has the >> Xen devel packages installed. As it is automatically selected, >> we need to disable it with the --disable-xen option, else the >> build fails: >> >> /usr/bin/ld: libcommon.fa.p/hw_xen_xen-legacy-backend.c.o: in function `xen_be_register_common': >> hw/xen/xen-legacy-backend.c:754: undefined reference to `xen_9pfs_ops' >> /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x8): undefined reference to `local_ops' >> /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x20): undefined reference to `synth_ops' >> /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x38): undefined reference to `proxy_ops' >> collect2: error: ld returned 1 exit status >> >> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> >> --- >> .gitlab-ci.yml | 11 +++++++++++ >> 1 file changed, 11 insertions(+) >> >> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml >> index 3b15ae5c302..6ee098ec53c 100644 >> --- a/.gitlab-ci.yml >> +++ b/.gitlab-ci.yml >> @@ -262,6 +262,17 @@ build-user-plugins: >> MAKE_CHECK_ARGS: check-tcg >> timeout: 1h 30m >> >> +build-system-ubuntu-without-default-devices: >> + <<: *native_build_job_definition >> + variables: >> + IMAGE: ubuntu2004 >> + CONFIGURE_ARGS: --without-default-devices --disable-user --disable-xen --disable-tools --disable-docs >> + MAKE_CHECK_ARGS: check-build > > AFAIK "check-build" is pretty much a no-op since the convertion to meson ... > could you maybe replace with a set of qtest targets that work, to make sure > that we do not regress here? E.g.: > > MAKE_CHECK_ARGS: check-qtest-avr check-qtestcris check-qtest-m68k > check-qtest-microblaze check-qtest-mipsel check-qtest-moxie ... qtests don't work with --without-default-devices, as we don't check for (un-)available devices. I'll try check-unit. Thanks, Phil.
On Tue, Nov 3, 2020 at 6:01 PM Philippe Mathieu-Daudé <philmd@redhat.com> wrote: > On 11/3/20 5:52 PM, Daniel P. Berrangé wrote: > > On Tue, Nov 03, 2020 at 05:46:03PM +0100, Philippe Mathieu-Daudé wrote: > >> We test './configure --without-default-devices' since commit > >> 20885b5b169 (".travis.yml: test that no-default-device builds > >> do not regress") in Travis-CI. > >> > >> One minor difference: the GitLab Ubuntu docker image has the > >> Xen devel packages installed. As it is automatically selected, > >> we need to disable it with the --disable-xen option, else the > >> build fails: > >> > >> /usr/bin/ld: libcommon.fa.p/hw_xen_xen-legacy-backend.c.o: in function `xen_be_register_common': > >> hw/xen/xen-legacy-backend.c:754: undefined reference to `xen_9pfs_ops' > >> /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x8): undefined reference to `local_ops' > >> /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x20): undefined reference to `synth_ops' > >> /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x38): undefined reference to `proxy_ops' All these symbols are defined in hw/9pfs/meson.build's fs_ss, which is conditional on CONFIG_9PFS. So: diff --git a/accel/Kconfig b/accel/Kconfig index 2ad94a3839..d24664d736 100644 --- a/accel/Kconfig +++ b/accel/Kconfig @@ -7,3 +7,4 @@ config KVM config XEN bool select FSDEV_9P if VIRTFS + select 9PFS if VIRTFS or alternatively (and I think better): diff --git a/hw/9pfs/Kconfig b/hw/9pfs/Kconfig index d3ebd73730..3ae5749661 100644 --- a/hw/9pfs/Kconfig +++ b/hw/9pfs/Kconfig @@ -2,12 +2,8 @@ config FSDEV_9P bool depends on VIRTFS -config 9PFS - bool - config VIRTIO_9P bool default y depends on VIRTFS && VIRTIO select FSDEV_9P - select 9PFS diff --git a/hw/9pfs/meson.build b/hw/9pfs/meson.build index cc09426212..99be5d9119 100644 --- a/hw/9pfs/meson.build +++ b/hw/9pfs/meson.build @@ -15,6 +15,6 @@ fs_ss.add(files( 'coxattr.c', )) fs_ss.add(when: 'CONFIG_XEN', if_true: files('xen-9p-backend.c')) -softmmu_ss.add_all(when: 'CONFIG_9PFS', if_true: fs_ss) +softmmu_ss.add_all(when: 'CONFIG_FSDEV_9P', if_true: fs_ss) specific_ss.add(when: 'CONFIG_VIRTIO_9P', if_true: files('virtio-9p-device.c')) Paolo
On 11/3/20 9:57 PM, Paolo Bonzini wrote: > On Tue, Nov 3, 2020 at 6:01 PM Philippe Mathieu-Daudé <philmd@redhat.com> wrote: >> On 11/3/20 5:52 PM, Daniel P. Berrangé wrote: >>> On Tue, Nov 03, 2020 at 05:46:03PM +0100, Philippe Mathieu-Daudé wrote: >>>> We test './configure --without-default-devices' since commit >>>> 20885b5b169 (".travis.yml: test that no-default-device builds >>>> do not regress") in Travis-CI. >>>> >>>> One minor difference: the GitLab Ubuntu docker image has the >>>> Xen devel packages installed. As it is automatically selected, >>>> we need to disable it with the --disable-xen option, else the >>>> build fails: >>>> >>>> /usr/bin/ld: libcommon.fa.p/hw_xen_xen-legacy-backend.c.o: in function `xen_be_register_common': >>>> hw/xen/xen-legacy-backend.c:754: undefined reference to `xen_9pfs_ops' >>>> /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x8): undefined reference to `local_ops' >>>> /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x20): undefined reference to `synth_ops' >>>> /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x38): undefined reference to `proxy_ops' > > All these symbols are defined in hw/9pfs/meson.build's fs_ss, which is > conditional on CONFIG_9PFS. So: > > diff --git a/accel/Kconfig b/accel/Kconfig > index 2ad94a3839..d24664d736 100644 > --- a/accel/Kconfig > +++ b/accel/Kconfig > @@ -7,3 +7,4 @@ config KVM > config XEN > bool > select FSDEV_9P if VIRTFS > + select 9PFS if VIRTFS Without this line ^ it works! Thanks :* Can you reply with your S-o-b? :) > > or alternatively (and I think better): > > diff --git a/hw/9pfs/Kconfig b/hw/9pfs/Kconfig > index d3ebd73730..3ae5749661 100644 > --- a/hw/9pfs/Kconfig > +++ b/hw/9pfs/Kconfig > @@ -2,12 +2,8 @@ config FSDEV_9P > bool > depends on VIRTFS > > -config 9PFS > - bool > - > config VIRTIO_9P > bool > default y > depends on VIRTFS && VIRTIO > select FSDEV_9P > - select 9PFS > diff --git a/hw/9pfs/meson.build b/hw/9pfs/meson.build > index cc09426212..99be5d9119 100644 > --- a/hw/9pfs/meson.build > +++ b/hw/9pfs/meson.build > @@ -15,6 +15,6 @@ fs_ss.add(files( > 'coxattr.c', > )) > fs_ss.add(when: 'CONFIG_XEN', if_true: files('xen-9p-backend.c')) > -softmmu_ss.add_all(when: 'CONFIG_9PFS', if_true: fs_ss) > +softmmu_ss.add_all(when: 'CONFIG_FSDEV_9P', if_true: fs_ss) > > specific_ss.add(when: 'CONFIG_VIRTIO_9P', if_true: files('virtio-9p-device.c')) > > Paolo >
On 03/11/20 22:07, Philippe Mathieu-Daudé wrote: >> diff --git a/accel/Kconfig b/accel/Kconfig >> index 2ad94a3839..d24664d736 100644 >> --- a/accel/Kconfig >> +++ b/accel/Kconfig >> @@ -7,3 +7,4 @@ config KVM >> config XEN >> bool >> select FSDEV_9P if VIRTFS >> + select 9PFS if VIRTFS > Without this line ^ it works! Thanks :* Without which line? (Also if both work I prefer the other one). Paolo
On Tue, 3 Nov 2020, Philippe Mathieu-Daudé wrote: > I forgot to Cc the 9pfs & Xen maintainers, doing it now ;) > > On 11/3/20 6:01 PM, Philippe Mathieu-Daudé wrote: > > On 11/3/20 5:52 PM, Daniel P. Berrangé wrote: > >> On Tue, Nov 03, 2020 at 05:46:03PM +0100, Philippe Mathieu-Daudé wrote: > >>> We test './configure --without-default-devices' since commit > >>> 20885b5b169 (".travis.yml: test that no-default-device builds > >>> do not regress") in Travis-CI. > >>> > >>> As we prefer to use GitLab-CI, add the equivalent job there. > >>> > >>> One minor difference: the GitLab Ubuntu docker image has the > >>> Xen devel packages installed. As it is automatically selected, > >>> we need to disable it with the --disable-xen option, else the > >>> build fails: > >>> > >>> /usr/bin/ld: libcommon.fa.p/hw_xen_xen-legacy-backend.c.o: in function `xen_be_register_common': > >>> hw/xen/xen-legacy-backend.c:754: undefined reference to `xen_9pfs_ops' > >>> /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x8): undefined reference to `local_ops' > >>> /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x20): undefined reference to `synth_ops' > >>> /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x38): undefined reference to `proxy_ops' > >>> collect2: error: ld returned 1 exit status > >> > >> Surely this is a build bug we need to fix rather than ignore in CI ? > > > > Well it predates this series, so nobody really cared > > (thus I wonder if it makes sense to invest resources > > there). > > > > Anyway I can have a look after 5.2-rc1. Actually I care about Xen and 9pfs support, it is one of the few combinations that I use regularly and it is even enabled in the Xilinx product I look after. But admittedly I don't test QEMU master as much as I should. With the recent changes to the build system it is not very suprising that there are some issues. It would be great to have a Xen and 9pfs test in the gitlab CI-loop. FYI I tried to build the latest QEMU on Alpine Linux 3.12 ARM64 and I get: ninja: unknown tool 'query' Even after rebuilding ninja master by hand. Any ideas? I don't know much about ninja. So I gave up on that and I spinned up a Debian Buster x86 container for this build. That one got past the "ninja: unknown tool 'query'" error. The build completed without problems to the end. Either way I can't reproduce the build error above.
On 04/11/2020 03.27, Stefano Stabellini wrote: [...] > Actually I care about Xen and 9pfs support, it is one of the few > combinations that I use regularly and it is even enabled in the Xilinx > product I look after. But admittedly I don't test QEMU master as much as > I should. With the recent changes to the build system it is not very > suprising that there are some issues. It would be great to have a Xen > and 9pfs test in the gitlab CI-loop. > > > FYI I tried to build the latest QEMU on Alpine Linux 3.12 ARM64 and I > get: > > ninja: unknown tool 'query' > > Even after rebuilding ninja master by hand. Any ideas? I don't know much > about ninja. > > > So I gave up on that and I spinned up a Debian Buster x86 container for > this build. That one got past the "ninja: unknown tool 'query'" error. > The build completed without problems to the end. > > Either way I can't reproduce the build error above. Did you run "configure" with "--without-default-devices" ? Thomas
On 03/11/2020 21.41, Philippe Mathieu-Daudé wrote: > On 11/3/20 7:43 PM, Thomas Huth wrote: >> On 03/11/2020 17.46, Philippe Mathieu-Daudé wrote: [...] >>> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml >>> index 3b15ae5c302..6ee098ec53c 100644 >>> --- a/.gitlab-ci.yml >>> +++ b/.gitlab-ci.yml >>> @@ -262,6 +262,17 @@ build-user-plugins: >>> MAKE_CHECK_ARGS: check-tcg >>> timeout: 1h 30m >>> >>> +build-system-ubuntu-without-default-devices: >>> + <<: *native_build_job_definition >>> + variables: >>> + IMAGE: ubuntu2004 >>> + CONFIGURE_ARGS: --without-default-devices --disable-user --disable-xen --disable-tools --disable-docs >>> + MAKE_CHECK_ARGS: check-build >> >> AFAIK "check-build" is pretty much a no-op since the convertion to meson ... >> could you maybe replace with a set of qtest targets that work, to make sure >> that we do not regress here? E.g.: >> >> MAKE_CHECK_ARGS: check-qtest-avr check-qtestcris check-qtest-m68k >> check-qtest-microblaze check-qtest-mipsel check-qtest-moxie ... > > qtests don't work with --without-default-devices, as we don't check > for (un-)available devices. Sure, "make check-qtest" does not work, I know. But some targets work fine, e.g. "make check-qtest-avr", and that's what I've suggested. By testing those targets, we can make sure that the qtests don't regress any further with --without-default-devices. > I'll try check-unit. I think that does not have much benefit since it should be independent of the devices and is tested in the other pipelines already? Thomas
Il mer 4 nov 2020, 03:27 Stefano Stabellini <sstabellini@kernel.org> ha scritto: > FYI I tried to build the latest QEMU on Alpine Linux 3.12 ARM64 and I > get: > > ninja: unknown tool 'query' > > Even after rebuilding ninja master by hand. Any ideas? I don't know much > about ninja. > Are you sure you have ninja installed and not its clone samurai (yes, I am serious)? I have contributed query support to samurai but it hasn't made it to a release yet. What is the output of "ninja -t list"? Paolo > > So I gave up on that and I spinned up a Debian Buster x86 container for > this build. That one got past the "ninja: unknown tool 'query'" error. > The build completed without problems to the end. > > Either way I can't reproduce the build error above. <div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il mer 4 nov 2020, 03:27 Stefano Stabellini <<a href="mailto:sstabellini@kernel.org">sstabellini@kernel.org</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">FYI I tried to build the latest QEMU on Alpine Linux 3.12 ARM64 and I<br> get:<br> <br> ninja: unknown tool 'query'<br> <br> Even after rebuilding ninja master by hand. Any ideas? I don't know much<br> about ninja.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Are you sure you have ninja installed and not its clone samurai (yes, I am serious)? I have contributed query support to samurai but it hasn't made it to a release yet.</div><div dir="auto"><br></div><div dir="auto">What is the output of "ninja -t list"?</div><div dir="auto"><br></div><div dir="auto">Paolo</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> <br> So I gave up on that and I spinned up a Debian Buster x86 container for<br> this build. That one got past the "ninja: unknown tool 'query'" error.<br> The build completed without problems to the end.<br> <br> Either way I can't reproduce the build error above.</blockquote></div></div></div>
On 11/4/20 7:21 AM, Thomas Huth wrote: > On 03/11/2020 21.41, Philippe Mathieu-Daudé wrote: >> On 11/3/20 7:43 PM, Thomas Huth wrote: >>> On 03/11/2020 17.46, Philippe Mathieu-Daudé wrote: > [...] >>>> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml >>>> index 3b15ae5c302..6ee098ec53c 100644 >>>> --- a/.gitlab-ci.yml >>>> +++ b/.gitlab-ci.yml >>>> @@ -262,6 +262,17 @@ build-user-plugins: >>>> MAKE_CHECK_ARGS: check-tcg >>>> timeout: 1h 30m >>>> >>>> +build-system-ubuntu-without-default-devices: >>>> + <<: *native_build_job_definition >>>> + variables: >>>> + IMAGE: ubuntu2004 >>>> + CONFIGURE_ARGS: --without-default-devices --disable-user --disable-xen --disable-tools --disable-docs >>>> + MAKE_CHECK_ARGS: check-build >>> >>> AFAIK "check-build" is pretty much a no-op since the convertion to meson ... >>> could you maybe replace with a set of qtest targets that work, to make sure >>> that we do not regress here? E.g.: >>> >>> MAKE_CHECK_ARGS: check-qtest-avr check-qtestcris check-qtest-m68k >>> check-qtest-microblaze check-qtest-mipsel check-qtest-moxie ... >> >> qtests don't work with --without-default-devices, as we don't check >> for (un-)available devices. > > Sure, "make check-qtest" does not work, I know. But some targets work fine, > e.g. "make check-qtest-avr", and that's what I've suggested. Yes, I tested that successfully yesterday late. > By testing > those targets, we can make sure that the qtests don't regress any further > with --without-default-devices. Yes, but I'm being wary to use it with the sole AVR target, because I don't want this target development to be limited by unrelated technical debts (in case we add optional device on an AVR board). > >> I'll try check-unit. > > I think that does not have much benefit since it should be independent of > the devices and is tested in the other pipelines already? Ah, good point. Regards, Phil.
On 11/3/20 10:12 PM, Paolo Bonzini wrote: > On 03/11/20 22:07, Philippe Mathieu-Daudé wrote: >>> diff --git a/accel/Kconfig b/accel/Kconfig >>> index 2ad94a3839..d24664d736 100644 >>> --- a/accel/Kconfig >>> +++ b/accel/Kconfig >>> @@ -7,3 +7,4 @@ config KVM >>> config XEN >>> bool >>> select FSDEV_9P if VIRTFS >>> + select 9PFS if VIRTFS >> Without this line ^ it works! Thanks :* > > Without which line? Not adding "select 9PFS if VIRTFS" (keeping the current "select FSDEV_9P if VIRTFS"). > > (Also if both work I prefer the other one). > > Paolo >
On 04/11/2020 09.32, Philippe Mathieu-Daudé wrote: > On 11/4/20 7:21 AM, Thomas Huth wrote: >> On 03/11/2020 21.41, Philippe Mathieu-Daudé wrote: >>> On 11/3/20 7:43 PM, Thomas Huth wrote: >>>> On 03/11/2020 17.46, Philippe Mathieu-Daudé wrote: >> [...] >>>>> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml >>>>> index 3b15ae5c302..6ee098ec53c 100644 >>>>> --- a/.gitlab-ci.yml >>>>> +++ b/.gitlab-ci.yml >>>>> @@ -262,6 +262,17 @@ build-user-plugins: >>>>> MAKE_CHECK_ARGS: check-tcg >>>>> timeout: 1h 30m >>>>> >>>>> +build-system-ubuntu-without-default-devices: >>>>> + <<: *native_build_job_definition >>>>> + variables: >>>>> + IMAGE: ubuntu2004 >>>>> + CONFIGURE_ARGS: --without-default-devices --disable-user --disable-xen --disable-tools --disable-docs >>>>> + MAKE_CHECK_ARGS: check-build >>>> >>>> AFAIK "check-build" is pretty much a no-op since the convertion to meson ... >>>> could you maybe replace with a set of qtest targets that work, to make sure >>>> that we do not regress here? E.g.: >>>> >>>> MAKE_CHECK_ARGS: check-qtest-avr check-qtestcris check-qtest-m68k >>>> check-qtest-microblaze check-qtest-mipsel check-qtest-moxie ... >>> >>> qtests don't work with --without-default-devices, as we don't check >>> for (un-)available devices. >> >> Sure, "make check-qtest" does not work, I know. But some targets work fine, >> e.g. "make check-qtest-avr", and that's what I've suggested. > > Yes, I tested that successfully yesterday late. > >> By testing >> those targets, we can make sure that the qtests don't regress any further >> with --without-default-devices. > > Yes, but I'm being wary to use it with the sole AVR target, because > I don't want this target development to be limited by unrelated > technical debts (in case we add optional device on an AVR board). If you feel uncomfortable with check-qtest-avr, you could also use check-qtest-m68k instead - I think that's fine for me (and hopefully also Laurent). Thomas
On Wed, 4 Nov 2020, Paolo Bonzini wrote: > Il mer 4 nov 2020, 03:27 Stefano Stabellini <sstabellini@kernel.org> ha scritto: > FYI I tried to build the latest QEMU on Alpine Linux 3.12 ARM64 and I > get: > > ninja: unknown tool 'query' > > Even after rebuilding ninja master by hand. Any ideas? I don't know much > about ninja. > > > Are you sure you have ninja installed and not its clone samurai (yes, I am serious)? I have contributed query support to samurai but it > hasn't made it to a release yet. > > What is the output of "ninja -t list"? I repeated all the steps to make sure. The first time I was using Samurai because Alpine Linux comes with it and not Ninja. Then, I removed Samurai and built and installed Ninja by hand from https://github.com/ninja-build/ninja and that actually works. Yesterday it was late and I was distracted by global events -- I must have failed to update Ninja appropriately. Sorry for the confusion.
On Wed, 4 Nov 2020, Thomas Huth wrote: > On 04/11/2020 03.27, Stefano Stabellini wrote: > [...] > > Actually I care about Xen and 9pfs support, it is one of the few > > combinations that I use regularly and it is even enabled in the Xilinx > > product I look after. But admittedly I don't test QEMU master as much as > > I should. With the recent changes to the build system it is not very > > suprising that there are some issues. It would be great to have a Xen > > and 9pfs test in the gitlab CI-loop. > > > > > > FYI I tried to build the latest QEMU on Alpine Linux 3.12 ARM64 and I > > get: > > > > ninja: unknown tool 'query' > > > > Even after rebuilding ninja master by hand. Any ideas? I don't know much > > about ninja. > > > > > > So I gave up on that and I spinned up a Debian Buster x86 container for > > this build. That one got past the "ninja: unknown tool 'query'" error. > > The build completed without problems to the end. > > > > Either way I can't reproduce the build error above. > > Did you run "configure" with "--without-default-devices" ? Yes, and still I can't repro the issue, strange. Anyway, I saw that Philippe managed to find and fix the issue with "hw/9pfs: Fix Kconfig dependency problem between 9pfs and Xen", so all sorted :)
Le jeu. 5 nov. 2020 05:28, Stefano Stabellini <sstabellini@kernel.org> a écrit : > On Wed, 4 Nov 2020, Thomas Huth wrote: > > On 04/11/2020 03.27, Stefano Stabellini wrote: > > [...] > > > Actually I care about Xen and 9pfs support, it is one of the few > > > combinations that I use regularly and it is even enabled in the Xilinx > > > product I look after. But admittedly I don't test QEMU master as much > as > > > I should. With the recent changes to the build system it is not very > > > suprising that there are some issues. It would be great to have a Xen > > > and 9pfs test in the gitlab CI-loop. > > > > > > > > > FYI I tried to build the latest QEMU on Alpine Linux 3.12 ARM64 and I > > > get: > > > > > > ninja: unknown tool 'query' > > > > > > Even after rebuilding ninja master by hand. Any ideas? I don't know > much > > > about ninja. > > > > > > > > > So I gave up on that and I spinned up a Debian Buster x86 container for > > > this build. That one got past the "ninja: unknown tool 'query'" error. > > > The build completed without problems to the end. > > > > > > Either way I can't reproduce the build error above. > > > > Did you run "configure" with "--without-default-devices" ? > > Yes, and still I can't repro the issue, strange. Anyway, I saw that > Philippe managed to find and fix the issue with "hw/9pfs: Fix Kconfig > dependency problem between 9pfs and Xen", so all sorted :) > Paolo figured the problem and sent a diff, I just forwarded it as a formal patch ;) > <div dir="auto"><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 5 nov. 2020 05:28, Stefano Stabellini <<a href="mailto:sstabellini@kernel.org">sstabellini@kernel.org</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, 4 Nov 2020, Thomas Huth wrote:<br> > On 04/11/2020 03.27, Stefano Stabellini wrote:<br> > [...]<br> > > Actually I care about Xen and 9pfs support, it is one of the few<br> > > combinations that I use regularly and it is even enabled in the Xilinx<br> > > product I look after. But admittedly I don't test QEMU master as much as<br> > > I should. With the recent changes to the build system it is not very<br> > > suprising that there are some issues. It would be great to have a Xen<br> > > and 9pfs test in the gitlab CI-loop.<br> > > <br> > > <br> > > FYI I tried to build the latest QEMU on Alpine Linux 3.12 ARM64 and I<br> > > get:<br> > > <br> > > ninja: unknown tool 'query'<br> > > <br> > > Even after rebuilding ninja master by hand. Any ideas? I don't know much<br> > > about ninja.<br> > > <br> > > <br> > > So I gave up on that and I spinned up a Debian Buster x86 container for<br> > > this build. That one got past the "ninja: unknown tool 'query'" error.<br> > > The build completed without problems to the end.<br> > > <br> > > Either way I can't reproduce the build error above.<br> > <br> > Did you run "configure" with "--without-default-devices" ?<br> <br> Yes, and still I can't repro the issue, strange. Anyway, I saw that<br> Philippe managed to find and fix the issue with "hw/9pfs: Fix Kconfig<br> dependency problem between 9pfs and Xen", so all sorted :)<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Paolo figured the problem and sent a diff, I just forwarded it as a formal patch ;)</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> </blockquote></div></div></div>
On 05/11/20 03:48, Stefano Stabellini wrote: > I repeated all the steps to make sure. The first time I was using > Samurai because Alpine Linux comes with it and not Ninja. Then, I > removed Samurai and built and installed Ninja by hand from > https://github.com/ninja-build/ninja and that actually works. Yesterday > it was late and I was distracted by global events -- I must have failed > to update Ninja appropriately. Sorry for the confusion. FWIW I sent an Alpine merge request to support "ninja -t query". We should add an Alpine container and pipeline once it's merged. Paolo
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 3b15ae5c302..6ee098ec53c 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -262,6 +262,17 @@ build-user-plugins: MAKE_CHECK_ARGS: check-tcg timeout: 1h 30m +build-system-ubuntu-without-default-devices: + <<: *native_build_job_definition + variables: + IMAGE: ubuntu2004 + CONFIGURE_ARGS: --without-default-devices --disable-user --disable-xen --disable-tools --disable-docs + MAKE_CHECK_ARGS: check-build + artifacts: + expire_in: 2 days + paths: + - build + build-clang: <<: *native_build_job_definition variables:
We test './configure --without-default-devices' since commit 20885b5b169 (".travis.yml: test that no-default-device builds do not regress") in Travis-CI. As we prefer to use GitLab-CI, add the equivalent job there. One minor difference: the GitLab Ubuntu docker image has the Xen devel packages installed. As it is automatically selected, we need to disable it with the --disable-xen option, else the build fails: /usr/bin/ld: libcommon.fa.p/hw_xen_xen-legacy-backend.c.o: in function `xen_be_register_common': hw/xen/xen-legacy-backend.c:754: undefined reference to `xen_9pfs_ops' /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x8): undefined reference to `local_ops' /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x20): undefined reference to `synth_ops' /usr/bin/ld: libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x38): undefined reference to `proxy_ops' collect2: error: ld returned 1 exit status Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> --- .gitlab-ci.yml | 11 +++++++++++ 1 file changed, 11 insertions(+)