From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42009) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnvOr-00052g-GB for qemu-devel@nongnu.org; Sun, 18 Oct 2015 17:21:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZnvOo-0006Eq-7v for qemu-devel@nongnu.org; Sun, 18 Oct 2015 17:21:53 -0400 Received: from mail-vk0-f43.google.com ([209.85.213.43]:33944) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnvOo-0006Em-3t for qemu-devel@nongnu.org; Sun, 18 Oct 2015 17:21:50 -0400 Received: by vkat63 with SMTP id t63so94347924vka.1 for ; Sun, 18 Oct 2015 14:21:49 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1445101160-13772-1-git-send-email-mdroth@linux.vnet.ibm.com> References: <1445101160-13772-1-git-send-email-mdroth@linux.vnet.ibm.com> From: Peter Maydell Date: Sun, 18 Oct 2015 22:21:30 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PULL v3 00/13] qemu-ga patch queue List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth Cc: QEMU Developers On 17 October 2015 at 17:59, Michael Roth wrote= : > Hi Peter, > > Please note that 'glib-compat: add 2.38/2.40/2.46 asserts' is also in > Marc-Andr=C3=A9's recent ivshmem PULL. The 2 versions of the patches are = identical, > but let me know if you'd prefer a re-send/re-base later. > > The following changes since commit 6d57410a79d51d92673c54f26624b44f27fa62= 14: > > Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-201= 51016' into staging (2015-10-17 12:31:33 +0100) > > are available in the git repository at: > > > git://github.com/mdroth/qemu.git tags/qga-pull-2015-10-14-v3-tag > > for you to fetch changes up to ed9f1986d19c2d21667a14b875b2ac8b8a19b8a5: > > qga: fix uninitialized value warning for win32 (2015-10-17 11:24:27 -05= 00) > > ---------------------------------------------------------------- > qemu-ga patch queue > > * add unit tests for qemu-ga > * add guest-exec support for posix/w32 guests > * added 'qemu-ga' target for w32. this allows us to do full MSI build, > without overloading 'qemu-ga.exe' target with uneeded dependencies. > * number of s/g_new/g_malloc/ conversions for qga > > v2: > * commit message and qapi documentation spelling fixes > * rename 'inp-data' guest-exec param to 'input-data' > > v3: > * fix OSX build errors for test-qga by using PRId64 > format in place of glib's, and dropping use of G_SPAWN_DEFAULT > macro for glib 2.22 compat > * fix win32 build warnings for 32-bit builds by avoid int casts > of process HANDLEs Still seeing failures, I'm afraid. OSX assertion failures: GTESTER tests/test-qga ** ERROR:/Users/pm215/src/qemu-for-merges/tests/libqtest.c:238:void socket_send(int, const char *, size_t): assertion failed (len !=3D -1): (-1 !=3D -1) GTester: last random seed: R02S96655a200709f74b72ea42792cd65e8e (repeated about 10 times). Test failures on 64-bit ARM: TEST: tests/test-qga... (pid=3D22454) /qga/sync-delimited: OK /qga/sync: OK /qga/ping: OK /qga/info: OK /qga/network-get-interfaces: OK /qga/get-vcpus: OK /qga/get-fsinfo: OK /qga/get-memory-block-info: ** ERROR:/home/petmay01/qemu/tests/test-qga.c:294:test_qga_get_memory_block_in= fo: assertion failed ret: GenericError open("/sys/devices/system/memory/"): No such file or directory FAIL GTester: last random seed: R02S6aa3e1f8b691a9900d2ea9945e79869d (pid=3D22458) /qga/get-memory-blocks: ** ERROR:/home/petmay01/qemu/tests/test-qga.c:313:test_qga_get_memory_blocks: assertion failed ret: GenericError Can't open directory"/sys/devices/system/memory/" : No such file or directory FAIL GTester: last random seed: R02S978afb04187410dc690a8b7d6d236793 (pid=3D22461) /qga/file-ops: OK /qga/get-time: OK /qga/invalid-cmd: OK /qga/fsfreeze-status: OK /qga/blacklist: OK /qga/config: OK FAIL: tests/test-qga make: *** [check-tests/test-qga] Error 1 Not sure why it's complaining, /sys/devices/system/memory/ does exist on this box. Ditto on 32-bit ARM, though that's not surprising as it's just a chroot on an equivalently-configured machine to the 64-bit build. thanks -- PMM