qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] .gitlab-ci.d/windows.yml: Enable native Windows symlink


From: Yonggang Luo
Subject: Re: [PATCH] .gitlab-ci.d/windows.yml: Enable native Windows symlink
Date: Wed, 27 Jul 2022 17:11:14 +0800

I've seen the cirrus ci always succeed, maybe using cirrus instead?

On Wed, Jul 27, 2022 at 5:03 PM Thomas Huth <thuth@redhat.com> wrote:
>
> On 27/07/2022 10.54, Daniel P. Berrangé wrote:
> > On Wed, Jul 27, 2022 at 02:02:48PM +0800, Bin Meng wrote:
> >> On Tue, Jul 26, 2022 at 9:38 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> >>>
> >>> On Mon, Jul 25, 2022 at 9:48 PM Alex Bennée <alex.bennee@linaro.org> wrote:
> >>>>
> >>>>
> >>>> Bin Meng <bmeng.cn@gmail.com> writes:
> >>>>
> >>>>> From: Bin Meng <bin.meng@windriver.com>
> >>>>>
> >>>>> The following error message was seen during the configure:
> >>>>>
> >>>>>    "ln: failed to create symbolic link
> >>>>>    'x86_64-softmmu/qemu-system-x86_64.exe': No such file or directory"
> >>>>>
> >>>>> By default the MSYS environment variable is not defined, so the runtime
> >>>>> behavior of winsymlinks is: if <target> does not exist, 'ln -s' fails.
> >>>>> At the configure phase, the qemu-system-x86_64.exe has not been built
> >>>>> so creation of the symbolic link fails hence the error message.
> >>>>>
> >>>>> Set winsymlinks to 'native' whose behavior is most similar to the
> >>>>> behavior of 'ln -s' on *nix, that is:
> >>>>>
> >>>>>    a) if native symlinks are enabled, and whether <target> exists
> >>>>>       or not, creates <destination> as a native Windows symlink;
> >>>>>    b) else if native symlinks are not enabled, and whether <target>
> >>>>>       exists or not, 'ln -s' creates as a Windows shortcut file.
> >>>>>
> >>>>> Signed-off-by: Bin Meng <bin.meng@windriver.com>
> >>>>
> >>>> I'm still seeing Windows build failures such as:
> >>>>
> >>>>    https://gitlab.com/stsquad/qemu/-/jobs/2765579269
> >>>
> >>> I've seen this one before. Looks like this one can be easily reproduced.
> >>>
> >>>>
> >>>> and
> >>>>
> >>>>    https://gitlab.com/stsquad/qemu/-/jobs/2765579267
> >>>
> >>> This one seems to be a random failure?
> >>>
> >>
> >> Saw another random failure today in the msys2-32bit build in CI.
> >>
> >> [313/1788] Generating texture-blit-vert.h with a custom command
> >> (wrapped by meson to capture output)
> >> FAILED: ui/shader/texture-blit-vert.h
> >> "C:/GitLab-Runner/builds/lbmeng/qemu/msys64/mingw32/bin/python3.exe"
> >> "C:/GitLab-Runner/builds/lbmeng/qemu/meson/meson.py" "--internal"
> >> "exe" "--capture" "ui/shader/texture-blit-vert.h" "--" "perl"
> >> "C:/GitLab-Runner/builds/lbmeng/qemu/scripts/shaderinclude.pl"
> >> "../ui/shader/texture-blit.vert"
> >> [314/1788] Generating texture-blit-flip-vert.h with a custom command
> >> (wrapped by meson to capture output)
> >> ninja: build stopped: subcommand failed.
> >> make: *** [Makefile:162: run-ninja] Error 1
> >
> > IMHO we need to just drop the msys jobs from GitLab. They are too
> > unreliable and causing frequent failed pipelines.
>
> IIRC they were working way more reliable 'till two or three months ago?
> Maybe this was introduced by the bump to the newest level of MSYS2 in commit
> 5c570ef2f154 ? Maybe we should upgrade or downgrade the MSYS2 version again?
>
>   Thomas
>


--
         此致

罗勇刚
Yours
    sincerely,
Yonggang Luo

reply via email to

[Prev in Thread] Current Thread [Next in Thread]