mbox

[PULL,0/3] Fixes 20200825 patches

Message ID 20200825062008.6502-1-kraxel@redhat.com
State New
Headers show

Pull-request

git://git.kraxel.org/qemu tags/fixes-20200825-pull-request

Message

Gerd Hoffmann Aug. 25, 2020, 6:20 a.m. UTC
The following changes since commit 30aa19446d82358a30eac3b556b4d6641e00b7c1:

  Merge remote-tracking branch 'remotes/cschoenebeck/tags/pull-9p-20200812' into staging (2020-08-24 16:39:53 +0100)

are available in the Git repository at:

  git://git.kraxel.org/qemu tags/fixes-20200825-pull-request

for you to fetch changes up to 9755c94a50c8b845ad133a6e660f55ca131b9c7a:

  meson: avoid compiling qemu-keymap by default (2020-08-25 08:12:19 +0200)

----------------------------------------------------------------
meson: keymap fixes

----------------------------------------------------------------

Gerd Hoffmann (1):
  meson: drop keymaps symlink

Laurent Vivier (2):
  meson: move xkbcommon to meson
  meson: avoid compiling qemu-keymap by default

 configure         | 31 +++++--------------------------
 meson_options.txt |  1 +
 meson.build       | 16 +++++++++++-----
 ui/meson.build    |  2 +-
 4 files changed, 18 insertions(+), 32 deletions(-)

Comments

Peter Maydell Aug. 25, 2020, 12:59 p.m. UTC | #1
On Tue, 25 Aug 2020 at 07:22, Gerd Hoffmann <kraxel@redhat.com> wrote:
>
> The following changes since commit 30aa19446d82358a30eac3b556b4d6641e00b7c1:
>
>   Merge remote-tracking branch 'remotes/cschoenebeck/tags/pull-9p-20200812' into staging (2020-08-24 16:39:53 +0100)
>
> are available in the Git repository at:
>
>   git://git.kraxel.org/qemu tags/fixes-20200825-pull-request
>
> for you to fetch changes up to 9755c94a50c8b845ad133a6e660f55ca131b9c7a:
>
>   meson: avoid compiling qemu-keymap by default (2020-08-25 08:12:19 +0200)
>
> ----------------------------------------------------------------
> meson: keymap fixes
>
> ----------------------------------------------------------------



Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/5.2
for any user-visible changes.

-- PMM
Thomas Huth Aug. 27, 2020, 7:20 a.m. UTC | #2
On 25/08/2020 08.20, Gerd Hoffmann wrote:
> The following changes since commit 30aa19446d82358a30eac3b556b4d6641e00b7c1:
> 
>   Merge remote-tracking branch 'remotes/cschoenebeck/tags/pull-9p-20200812' into staging (2020-08-24 16:39:53 +0100)
> 
> are available in the Git repository at:
> 
>   git://git.kraxel.org/qemu tags/fixes-20200825-pull-request
> 
> for you to fetch changes up to 9755c94a50c8b845ad133a6e660f55ca131b9c7a:
> 
>   meson: avoid compiling qemu-keymap by default (2020-08-25 08:12:19 +0200)
> 
> ----------------------------------------------------------------
> meson: keymap fixes
> 
> ----------------------------------------------------------------

 Hi Gerd,

if I've got that right, something in this pull request broke the gitlab
CI, see:

 https://gitlab.com/qemu-project/qemu/-/jobs/702680909

216 (33/45)
tests/acceptance/vnc.py:Vnc.test_change_password_requires_a_password:
ERROR: Unexpected empty reply from server (0.08 s)
217 (34/45) tests/acceptance/vnc.py:Vnc.test_change_password:  ERROR:
Unexpected empty reply from server (0.06 s)

Peter, what is still missing that you could use the gitlab CI as gating
tests, too?

 Thomas
Gerd Hoffmann Aug. 27, 2020, 9:28 a.m. UTC | #3
> if I've got that right, something in this pull request broke the gitlab
> CI, see:
> 
>  https://gitlab.com/qemu-project/qemu/-/jobs/702680909
> 
> 216 (33/45)
> tests/acceptance/vnc.py:Vnc.test_change_password_requires_a_password:
> ERROR: Unexpected empty reply from server (0.08 s)
> 217 (34/45) tests/acceptance/vnc.py:Vnc.test_change_password:  ERROR:
> Unexpected empty reply from server (0.06 s)

Yep, qemu is upset b/c the en-us keymap isn't there.

Seems we handle the 'no qemu-keymap present + start from build
directory' case not correctly.  I guess with the symlink being
gone now we should just copy the files from the source tree.

https://gitlab.com/kraxel/qemu/-/commit/1e29c4518e7b69d09bb22e071376ddeb151d0970
https://gitlab.com/kraxel/qemu/-/pipelines/182575761

lets see how it is going ...

take care,
  Gerd
Peter Maydell Aug. 27, 2020, 10:23 a.m. UTC | #4
On Thu, 27 Aug 2020 at 08:20, Thomas Huth <thuth@redhat.com> wrote:
> Peter, what is still missing that you could use the gitlab CI as gating
> tests, too?

I think we're waiting on a respin of the scripts from
Cleber, aren't we?

Also we need figure out how to handle the conflict between
"gitlab's git repo is mirrored (by perodic push?) from
git.qemu.org" and "test by pushing to the gitlab staging
branch", because the former overwrites the changes that
the latter makes.

thanks
-- PMM
Gerd Hoffmann Aug. 28, 2020, 5:13 a.m. UTC | #5
On Thu, Aug 27, 2020 at 11:23:58AM +0100, Peter Maydell wrote:
> On Thu, 27 Aug 2020 at 08:20, Thomas Huth <thuth@redhat.com> wrote:
> > Peter, what is still missing that you could use the gitlab CI as gating
> > tests, too?
> 
> I think we're waiting on a respin of the scripts from
> Cleber, aren't we?
> 
> Also we need figure out how to handle the conflict between
> "gitlab's git repo is mirrored (by perodic push?) from
> git.qemu.org" and "test by pushing to the gitlab staging
> branch", because the former overwrites the changes that
> the latter makes.

Pushing to a qemu fork runs CI too, so the staging branch doesn't have
to live in the official qemu-project repo.

take care,
  Gerd
Peter Maydell Aug. 28, 2020, 4:29 p.m. UTC | #6
On Fri, 28 Aug 2020 at 06:13, Gerd Hoffmann <kraxel@redhat.com> wrote:
> On Thu, Aug 27, 2020 at 11:23:58AM +0100, Peter Maydell wrote:
> >
> > Also we need figure out how to handle the conflict between
> > "gitlab's git repo is mirrored (by perodic push?) from
> > git.qemu.org" and "test by pushing to the gitlab staging
> > branch", because the former overwrites the changes that
> > the latter makes.
>
> Pushing to a qemu fork runs CI too, so the staging branch doesn't have
> to live in the official qemu-project repo.

We aren't going to let the project's gitlab runners (the aarch64,
s390x, etc systems) run just anybody's CI jobs, because they're
a very limited resource: they will only run for things pushed
to the official repo.

thanks
-- PMM
Daniel P. Berrangé Aug. 28, 2020, 4:40 p.m. UTC | #7
On Fri, Aug 28, 2020 at 05:29:44PM +0100, Peter Maydell wrote:
> On Fri, 28 Aug 2020 at 06:13, Gerd Hoffmann <kraxel@redhat.com> wrote:
> > On Thu, Aug 27, 2020 at 11:23:58AM +0100, Peter Maydell wrote:
> > >
> > > Also we need figure out how to handle the conflict between
> > > "gitlab's git repo is mirrored (by perodic push?) from
> > > git.qemu.org" and "test by pushing to the gitlab staging
> > > branch", because the former overwrites the changes that
> > > the latter makes.
> >
> > Pushing to a qemu fork runs CI too, so the staging branch doesn't have
> > to live in the official qemu-project repo.
> 
> We aren't going to let the project's gitlab runners (the aarch64,
> s390x, etc systems) run just anybody's CI jobs, because they're
> a very limited resource: they will only run for things pushed
> to the official repo.

Runners are registered to the project, so we could create a separate
gitlab.com/qemu-project/qemu-staging  repo just for purpose of CI
and that would have access to the runners.

I don't know how the mirroring is setup currently, but if we use
GitLab's own pull based mirroring, you can configure it to only
mirror protected branches.  We could thus mark "master" and any
stable branches as protected.  GitLab should then mirror those,
without overwriting any other branches you have. So that ought
to let you create a staging branch in the main repo.


Regards,
Daniel