On Thu, Jul 13, 2023 at 10:51:15AM +0800, Bin Meng wrote:
On Thu, Jul 13, 2023 at 10:04 AM Tom Rini trini@konsulko.com wrote:
Move up to the latest tagged release of QEMU
I have the same patch in my local tree :)
Signed-off-by: Tom Rini trini@konsulko.com
tools/docker/Dockerfile | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/tools/docker/Dockerfile b/tools/docker/Dockerfile index aa54e2689fb5..733099684be6 100644 --- a/tools/docker/Dockerfile +++ b/tools/docker/Dockerfile @@ -77,6 +77,7 @@ RUN apt-get update && apt-get install -y \ libsdl1.2-dev \ libsdl2-dev \ libseccomp-dev \
libslirp-dev \ libssl-dev \ libtool \ libudev-dev \@@ -175,13 +176,11 @@ RUN git clone git://git.savannah.gnu.org/grub.git /tmp/grub && \
RUN git clone https://gitlab.com/qemu-project/qemu.git /tmp/qemu && \ cd /tmp/qemu && \
git checkout v6.1.0 && \
git checkout v8.0.3 && \ # config user.name and user.email to make 'git am' happy git config user.name u-boot && \ git config user.email u-boot@denx.de && \
# manually apply the bug fix for QEMU 6.1.0 Xilinx Zynq UART emulation codeswget -O - http://patchwork.ozlabs.org/project/qemu-devel/patch/20210823020813.25192-2-bmeng.cn@gmail.com/mbox/ | git am && \./configure --prefix=/opt/qemu --target-list="aarch64-softmmu,arm-softmmu,i386-softmmu,m68k-softmmu,mips-softmmu,mips64-softmmu,mips64el-softmmu,mipsel-softmmu,ppc-softmmu,riscv32-softmmu,riscv64-softmmu,sh4-softmmu,x86_64-softmmu,xtensa-softmmu" && \
./configure --prefix=/opt/qemu --target-list="aarch64-softmmu,arm-softmmu,i386-softmmu,m68k-softmmu,mips-softmmu,mips64-softmmu,mips64el-softmmu,mipsel-softmmu,ppc-softmmu,riscv32-softmmu,riscv64-softmmu,sh4-softmmu,x86_64-softmmu,xtensa-softmmu" --enable-slirp && \--enable-slirp is not necessary as libslirp-dev is installed as a dependency which will be automatically figured out
I thought about it, and I first tripped in to "no libslirp, no user netdev, CI fails". I then spelled out we need the library and configure failed, and then ah, right, we need libslirp-dev installed. So I was thinking about being explicit about this flag as we specify the user netdev in a number of cases and this means if something changes in the future we'll get a failure here, rather than later on when testing the image. Does that make sense? Or do you still think I should drop the flag here?