| Message ID | 20200825062008.6502-1-kraxel@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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
> 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
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
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
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
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