Message ID | 20190502223007.29494-1-samuel.thibault@ens-lyon.org (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Thu, 2 May 2019 at 23:30, Samuel Thibault <samuel.thibault@ens-lyon.org> wrote: > > The following changes since commit 8482ff2eb3bb95020eb2f370a9b3ea26511e41df: > > Merge remote-tracking branch 'remotes/jnsnow/tags/bitmaps-pull-request' into staging (2019-05-02 12:04:51 +0100) > > are available in the Git repository at: > > https://people.debian.org/~sthibault/qemu.git tags/samuel-thibault > > for you to fetch changes up to 7c57bdd82026ba03f3158bbcd841afde7c2dc43a: > > build-sys: move slirp as git submodule project (2019-05-03 00:15:37 +0200) > > ---------------------------------------------------------------- > slirp: move slirp as git submodule project > > Marc-André Lureau (2): > build-sys: pass CFLAGS & LDFLAGS to subdir-slirp > build-sys: move slirp as git submodule project > > ---------------------------------------------------------------- > Marc-André Lureau (2): > build-sys: pass CFLAGS & LDFLAGS to subdir-slirp > build-sys: move slirp as git submodule project > Applied, thanks. Please update the changelog at https://wiki.qemu.org/ChangeLog/4.1 for any user-visible changes. -- PMM
On 5/3/19 2:54 PM, Peter Maydell wrote: > On Thu, 2 May 2019 at 23:30, Samuel Thibault > <samuel.thibault@ens-lyon.org> wrote: >> >> The following changes since commit 8482ff2eb3bb95020eb2f370a9b3ea26511e41df: >> >> Merge remote-tracking branch 'remotes/jnsnow/tags/bitmaps-pull-request' into staging (2019-05-02 12:04:51 +0100) >> >> are available in the Git repository at: >> >> https://people.debian.org/~sthibault/qemu.git tags/samuel-thibault >> >> for you to fetch changes up to 7c57bdd82026ba03f3158bbcd841afde7c2dc43a: >> >> build-sys: move slirp as git submodule project (2019-05-03 00:15:37 +0200) >> >> ---------------------------------------------------------------- >> slirp: move slirp as git submodule project >> >> Marc-André Lureau (2): >> build-sys: pass CFLAGS & LDFLAGS to subdir-slirp >> build-sys: move slirp as git submodule project >> >> ---------------------------------------------------------------- >> Marc-André Lureau (2): >> build-sys: pass CFLAGS & LDFLAGS to subdir-slirp >> build-sys: move slirp as git submodule project >> > > > Applied, thanks. TL;DR: You might need to run 'git submodule deinit --force slirp' if ou get errors after merging this. -- FYI I was running MinGW tests with "make docker-test-mingw@fedora SHOW_ENV=1 J=8 NETWORK=1" and ran "git pull" to refresh my local repo, and got: $ make docker-test-mingw@fedora SHOW_ENV=1 J=8 NETWORK=1 make[1]: Entering directory '/home/phil/source/qemu' GEN /home/phil/source/qemu/docker-src.2019-05-03-16.55.51.7157/qemu.tar slirp: unmerged (59a1b1f165458c2acb7ff0525b543945f7416225) fatal: git-write-tree: error building trees Cannot save the current index state Cloning into '/home/phil/source/qemu/docker-src.2019-05-03-16.55.51.7157/qemu.tar.vroot'... done. error: pathspec 'slirp:' did not match any file(s) known to git. error: pathspec 'needs' did not match any file(s) known to git. error: pathspec 'merge' did not match any file(s) known to git. failed to checkout slirp: needs merge revision tar: /var/tmp/qemu/qemu.tar: Cannot open: No such file or directory tar: Error is not recoverable: exiting now Failed to untar source tests/docker/Makefile.include:203: recipe for target 'docker-run' failed make[1]: *** [docker-run] Error 1 I don't run builds on this host (no tools installed) but everything via Docker, so (re-)running ./configure is not an option. $ git status Unmerged paths: (use "git reset HEAD <file>..." to unstage) (use "git add <file>..." to mark resolution) added by us: slirp $ ls -la slirp/ total 8 drwxr-xr-x 2 phil phil 4096 May 3 16:49 . drwxr-xr-x 56 phil phil 4096 May 3 16:55 .. $ git submodule status slirp U0000000000000000000000000000000000000000 slirp Daniel suggested on IRC to run: $ git submodule deinit --force slirp It worked fine after running it. Regards, Phil.
On Fri, 3 May 2019 at 16:05, Philippe Mathieu-Daudé <philmd@redhat.com> wrote: > FYI I was running MinGW tests with "make docker-test-mingw@fedora > SHOW_ENV=1 J=8 NETWORK=1" and ran "git pull" to refresh my local repo, > and got: > > $ make docker-test-mingw@fedora SHOW_ENV=1 J=8 NETWORK=1 > make[1]: Entering directory '/home/phil/source/qemu' > GEN > /home/phil/source/qemu/docker-src.2019-05-03-16.55.51.7157/qemu.tar > slirp: unmerged (59a1b1f165458c2acb7ff0525b543945f7416225) > fatal: git-write-tree: error building trees > Cannot save the current index state > Cloning into > '/home/phil/source/qemu/docker-src.2019-05-03-16.55.51.7157/qemu.tar.vroot'... > done. > error: pathspec 'slirp:' did not match any file(s) known to git. > error: pathspec 'needs' did not match any file(s) known to git. > error: pathspec 'merge' did not match any file(s) known to git. > failed to checkout slirp: needs merge revision > tar: /var/tmp/qemu/qemu.tar: Cannot open: No such file or directory > tar: Error is not recoverable: exiting now > Failed to untar source > tests/docker/Makefile.include:203: recipe for target 'docker-run' failed > make[1]: *** [docker-run] Error 1 This weird set of errors is demonstrating a bug in scripts/archive-source.sh where it is not checking for errors from git. Specifically it does: if git diff-index --quiet HEAD -- &>/dev/null then HEAD=HEAD else HEAD=$(git stash create) fi and git prints "slirp: needs merge revision", which we blindly put into the HEAD variable, and then later do: git checkout $HEAD which is what's causing the weird pathspec errors, because (a) we're trying to check out an error message and (b) our shell quoting is nonexistent and so we don't even treat it as a single argument... thanks -- PMM
On 5/2/19 5:30 PM, Samuel Thibault wrote: > The following changes since commit 8482ff2eb3bb95020eb2f370a9b3ea26511e41df: > > Merge remote-tracking branch 'remotes/jnsnow/tags/bitmaps-pull-request' into staging (2019-05-02 12:04:51 +0100) > > are available in the Git repository at: > > https://people.debian.org/~sthibault/qemu.git tags/samuel-thibault > > for you to fetch changes up to 7c57bdd82026ba03f3158bbcd841afde7c2dc43a: > > build-sys: move slirp as git submodule project (2019-05-03 00:15:37 +0200) > > ---------------------------------------------------------------- > slirp: move slirp as git submodule project > > Marc-André Lureau (2): > build-sys: pass CFLAGS & LDFLAGS to subdir-slirp > build-sys: move slirp as git submodule project > > ---------------------------------------------------------------- > Marc-André Lureau (2): > build-sys: pass CFLAGS & LDFLAGS to subdir-slirp > build-sys: move slirp as git submodule project After this series, an in-tree build is seeing a dirty tree, thanks to: > Changes not staged for commit: > (use "git add <file>..." to update what will be committed) > (use "git checkout -- <file>..." to discard changes in working directory) > (commit or discard the untracked or modified content in submodules) > > modified: slirp (untracked content) which in reality is due to: $ cd slirp/ $ git status HEAD detached at 59a1b1f Untracked files: (use "git add <file>..." to include in what will be committed) libslirp.a src/arp_table.d src/arp_table.o ... libslirp probably needs a .gitignore for *.a, *.o, *.d, and src/libslirp-version.h And actually getting it to apply during qemu's build will need another submodule update. In the meantime, where do we stand on our goal of disabling in-tree builds?
On Tue, May 07, 2019 at 09:11:09AM -0500, Eric Blake wrote: > On 5/2/19 5:30 PM, Samuel Thibault wrote: > > The following changes since commit 8482ff2eb3bb95020eb2f370a9b3ea26511e41df: > > > > Merge remote-tracking branch 'remotes/jnsnow/tags/bitmaps-pull-request' into staging (2019-05-02 12:04:51 +0100) > > > > are available in the Git repository at: > > > > https://people.debian.org/~sthibault/qemu.git tags/samuel-thibault > > > > for you to fetch changes up to 7c57bdd82026ba03f3158bbcd841afde7c2dc43a: > > > > build-sys: move slirp as git submodule project (2019-05-03 00:15:37 +0200) > > > > ---------------------------------------------------------------- > > slirp: move slirp as git submodule project > > > > Marc-André Lureau (2): > > build-sys: pass CFLAGS & LDFLAGS to subdir-slirp > > build-sys: move slirp as git submodule project > > > > ---------------------------------------------------------------- > > Marc-André Lureau (2): > > build-sys: pass CFLAGS & LDFLAGS to subdir-slirp > > build-sys: move slirp as git submodule project > > After this series, an in-tree build is seeing a dirty tree, thanks to: > > > Changes not staged for commit: > > (use "git add <file>..." to update what will be committed) > > (use "git checkout -- <file>..." to discard changes in working directory) > > (commit or discard the untracked or modified content in submodules) > > > > modified: slirp (untracked content) > > which in reality is due to: > > $ cd slirp/ > $ git status > HEAD detached at 59a1b1f > Untracked files: > (use "git add <file>..." to include in what will be committed) > > libslirp.a > src/arp_table.d > src/arp_table.o > ... > > libslirp probably needs a .gitignore for *.a, *.o, *.d, and > src/libslirp-version.h > > And actually getting it to apply during qemu's build will need another > submodule update. > > In the meantime, where do we stand on our goal of disabling in-tree builds? The view was largely positive when we discussed it. So I think it just needs someone to step up with a patch proposal, and at the start of the dev cycle is a good time for such a change i guess. Regards, Daniel
On Tue, 7 May 2019 at 15:19, Daniel P. Berrangé <berrange@redhat.com> wrote: > On Tue, May 07, 2019 at 09:11:09AM -0500, Eric Blake wrote: > > In the meantime, where do we stand on our goal of disabling in-tree builds? > > The view was largely positive when we discussed it. So I think it just > needs someone to step up with a patch proposal, and at the start of the > dev cycle is a good time for such a change i guess. Pitfalls to watch out for include checking whether any of: * the tests/vm scripting for the BSDs * various travis/etc CI configs * etc are currently using in-tree builds. Paolo will also need to update his coverity build config. thanks -- PMM
On 5/7/19 7:01 PM, Peter Maydell wrote: > On Tue, 7 May 2019 at 15:19, Daniel P. Berrangé <berrange@redhat.com> wrote: >> On Tue, May 07, 2019 at 09:11:09AM -0500, Eric Blake wrote: >>> In the meantime, where do we stand on our goal of disabling in-tree builds? >> >> The view was largely positive when we discussed it. So I think it just >> needs someone to step up with a patch proposal, and at the start of the >> dev cycle is a good time for such a change i guess. > > Pitfalls to watch out for include checking whether any of: > * the tests/vm scripting for the BSDs > * various travis/etc CI configs > * etc * most of roms/ > are currently using in-tree builds. > Paolo will also need to update his coverity build config. > > thanks > -- PMM >