From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Bin Meng <bmeng.cn@gmail.com>
Cc: "Alex Bennée" <alex.bennee@linaro.org>,
"Beraldo Leal" <bleal@redhat.com>,
"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
"Thomas Huth" <thuth@redhat.com>,
"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
"Bin Meng" <bin.meng@windriver.com>
Subject: Re: [PATCH] .gitlab-ci.d/windows.yml: Enable native Windows symlink
Date: Wed, 27 Jul 2022 09:54:58 +0100 [thread overview]
Message-ID: <YuD9YuSbmCbzo9kB@redhat.com> (raw)
In-Reply-To: <CAEUhbmWkVfjEgkg6uQ8cVVO7ipdiKuKeuco+fGNQ4zZdCnrA4Q@mail.gmail.com>
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.
With 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 :|
next prev parent reply other threads:[~2022-07-27 8:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-25 12:30 [PATCH] .gitlab-ci.d/windows.yml: Enable native Windows symlink Bin Meng
2022-07-25 13:47 ` Alex Bennée
2022-07-25 15:12 ` Thomas Huth
2022-07-26 1:38 ` Bin Meng
2022-07-27 6:02 ` Bin Meng
2022-07-27 8:54 ` Daniel P. Berrangé [this message]
2022-07-27 9:03 ` Thomas Huth
2022-07-27 9:11 ` 罗勇刚(Yonggang Luo)
2022-07-27 9:17 ` Thomas Huth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YuD9YuSbmCbzo9kB@redhat.com \
--to=berrange@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=bin.meng@windriver.com \
--cc=bleal@redhat.com \
--cc=bmeng.cn@gmail.com \
--cc=f4bug@amsat.org \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
--cc=wainersm@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.