[libvirt] Entering freeze for libvirt-1.1.2
I am a day late but I finally tagged the release candidate 1 of 1.1.2 in git and push the tarball and rpms to the usual place: ftp://libvirt.org/libvirt/ so the plan is to have an rc2 candidate on friday and if everything looks good push the final release 1.1.2 on Monday. Please give it a try especially for potential portability issues, thanks in advance ! Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/
On Wed, Aug 28, 2013 at 11:25 AM, Daniel Veillard <veillard@redhat.com>wrote:
I am a day late but I finally tagged the release candidate 1 of 1.1.2 in git and push the tarball and rpms to the usual place:
ftp://libvirt.org/libvirt/
so the plan is to have an rc2 candidate on friday and if everything looks good push the final release 1.1.2 on Monday.
Please give it a try especially for potential portability issues,
thanks in advance !
Daniel
-- Daniel Veillard | Open Source and Standards, Red Hat veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/
master presently fails on Mac OS X with the following: Making all in src GEN locking/lock_daemon_dispatch_stubs.h GEN lxc/lxc_monitor_protocol.c unsigned hyper initpid; ^^^^^^^^^^^^^^^^^^^^^^^^^^ lxc/lxc_monitor_protocol.x, line 18: expected ';' cannot shutdown /usr/bin/rpcgen: at ./rpc/genprotocol.pl line 136. make[2]: *** [lxc/lxc_monitor_protocol.c] Error 1 I haven't been able to look into the issue but I'm guessing its going to need a bit more code manipulation with Perl. -- Doug Goldstein
[dropping libvirt-announce - aren't we setting reply-to on our announcements, so that replies are directed only to side lists?] On 08/28/2013 11:31 AM, Doug Goldstein wrote:
master presently fails on Mac OS X with the following:
Making all in src GEN locking/lock_daemon_dispatch_stubs.h GEN lxc/lxc_monitor_protocol.c unsigned hyper initpid; ^^^^^^^^^^^^^^^^^^^^^^^^^^ lxc/lxc_monitor_protocol.x, line 18: expected ';' cannot shutdown /usr/bin/rpcgen: at ./rpc/genprotocol.pl line 136. make[2]: *** [lxc/lxc_monitor_protocol.c] Error 1
On 08/28/2013 12:02 PM, Justin Clift wrote:
Passes a compile test on OSX 10.7. ;)
+ Justin
So, what's different between your two OSX installations that it passes for one but not the other? Also, I will point out that at least on my FreeBSD VM setup, rpcgen generates code that triggers a gcc aliasing warning, and thus fails during development (where -Werror is default) but where the tarball is marginally okay (because there -Werror is off so the warning just scrolls by). We really ought to figure out why different flavors of rpcgen are generating these problems, and whether we can enhance our src/rpc/genprotocol.pl to paper over the problems, or even decide to write the RPC code generation ourselves rather than relying on rpcgen. But I don't know that it will get done in time for 1.1.2; it is more of a long-standing "always been that way", and not a regression new to this release. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 29/08/2013, at 6:13 PM, Eric Blake wrote:
[dropping libvirt-announce - aren't we setting reply-to on our announcements, so that replies are directed only to side lists?]
Not so far. I'm neither for-nor-against doing so, so feel to change if it needed. :)
On 08/28/2013 11:31 AM, Doug Goldstein wrote:
master presently fails on Mac OS X with the following:
Making all in src GEN locking/lock_daemon_dispatch_stubs.h GEN lxc/lxc_monitor_protocol.c unsigned hyper initpid; ^^^^^^^^^^^^^^^^^^^^^^^^^^ lxc/lxc_monitor_protocol.x, line 18: expected ';' cannot shutdown /usr/bin/rpcgen: at ./rpc/genprotocol.pl line 136. make[2]: *** [lxc/lxc_monitor_protocol.c] Error 1
For an OSX 10.8 VM here, it's working with Homebrew. To make it work, I: * downloaded the libvirt-1.1.2-rc1.tar.gz tarball to the Homebrew cache directory * renamed it to libvirt-1.1.2.tar.gz * Updated the Homebrew "libvirt.rb" file to look for libvirt-1.1.2.tar.gz instead of libvirt-1.1.1.tar.gz (and updated the sha256sum to match) At that point, "brew install libvirt" works with the new tarball. So, definitely not a comprehensive test... but it does make it past general compilation. Doug, how are you compiling? + Justin -- Open Source and Standards @ Red Hat twitter.com/realjustinclift
On 29/08/2013, at 6:13 PM, Eric Blake wrote:
[dropping libvirt-announce - aren't we setting reply-to on our announcements, so that replies are directed only to side lists?]
Not so far. I'm neither for-nor-against doing so, so feel to change if it needed. :)
On 08/28/2013 11:31 AM, Doug Goldstein wrote:
master presently fails on Mac OS X with the following:
Making all in src GEN locking/lock_daemon_dispatch_stubs.h GEN lxc/lxc_monitor_protocol.c unsigned hyper initpid; ^^^^^^^^^^^^^^^^^^^^^^^^^^ lxc/lxc_monitor_protocol.x, line 18: expected ';' cannot shutdown /usr/bin/rpcgen: at ./rpc/genprotocol.pl line 136. make[2]: *** [lxc/lxc_monitor_protocol.c] Error 1
For an OSX 10.8 VM here, it's working with Homebrew.
To make it work, I:
* downloaded the libvirt-1.1.2-rc1.tar.gz tarball to the Homebrew cache directory * renamed it to libvirt-1.1.2.tar.gz * Updated the Homebrew "libvirt.rb" file to look for libvirt-1.1.2.tar.gz instead of libvirt-1.1.1.tar.gz (and updated the sha256sum to match)
At that point, "brew install libvirt" works with the new tarball.
So, definitely not a comprehensive test... but it does make it past general compilation.
Doug, how are you compiling?
That's the difference between our setups. I used the git tag instead of
On Thu, Aug 29, 2013 at 12:18 PM, Justin Clift <jclift@redhat.com> wrote: the tarball. If things work with the tarball generated on a Linux box then I guess that's fine by me. -- Doug Goldstein
On Thu, Aug 29, 2013 at 12:38:11PM -0500, Doug Goldstein wrote:
On Thu, Aug 29, 2013 at 12:18 PM, Justin Clift <jclift@redhat.com> wrote:
On 29/08/2013, at 6:13 PM, Eric Blake wrote:
[dropping libvirt-announce - aren't we setting reply-to on our announcements, so that replies are directed only to side lists?]
Not so far. I'm neither for-nor-against doing so, so feel to change if it needed. :)
On 08/28/2013 11:31 AM, Doug Goldstein wrote:
master presently fails on Mac OS X with the following:
Making all in src GEN locking/lock_daemon_dispatch_stubs.h GEN lxc/lxc_monitor_protocol.c unsigned hyper initpid; ^^^^^^^^^^^^^^^^^^^^^^^^^^ lxc/lxc_monitor_protocol.x, line 18: expected ';' cannot shutdown /usr/bin/rpcgen: at ./rpc/genprotocol.pl line 136. make[2]: *** [lxc/lxc_monitor_protocol.c] Error 1
For an OSX 10.8 VM here, it's working with Homebrew.
To make it work, I:
* downloaded the libvirt-1.1.2-rc1.tar.gz tarball to the Homebrew cache directory * renamed it to libvirt-1.1.2.tar.gz * Updated the Homebrew "libvirt.rb" file to look for libvirt-1.1.2.tar.gz instead of libvirt-1.1.1.tar.gz (and updated the sha256sum to match)
At that point, "brew install libvirt" works with the new tarball.
So, definitely not a comprehensive test... but it does make it past general compilation.
Doug, how are you compiling?
That's the difference between our setups. I used the git tag instead of the tarball. If things work with the tarball generated on a Linux box then I guess that's fine by me.
Yes, we only officially support creation of tar.gz archives on modern Linux platforms. The reason we saw this difference is that the RPC generated .c & .h files are included in the tar.gz, so builds from tar.gz don't use the broken OS-X rpcgen tool Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Hi Eric, On Thu, Aug 29, 2013 at 11:13:02AM -0600, Eric Blake wrote: [..snip..]
Also, I will point out that at least on my FreeBSD VM setup, rpcgen generates code that triggers a gcc aliasing warning, and thus fails during development (where -Werror is default) but where the tarball is marginally okay (because there -Werror is off so the warning just scrolls by). We really ought to figure out why different flavors of rpcgen are generating these problems, and whether we can enhance our src/rpc/genprotocol.pl to paper over the problems, or even decide to write the RPC code generation ourselves rather than relying on rpcgen. But I don't know that it will get done in time for 1.1.2; it is more of a long-standing "always been that way", and not a regression new to this release.
There's a similar problem on kFreeBSD (which uses glibc) where the rpcgen code uses different but compatible types: https://www.redhat.com/archives/libvir-list/2013-May/msg02057.html Since I haven't got around to look into this in more detail since May I doubt I'll get around to this anytime soon but in case somebody picks this up I'd be happy to test patches on kFreeBSD. Cheers, -- Guido
On 28/08/2013, at 5:25 PM, Daniel Veillard wrote:
I am a day late but I finally tagged the release candidate 1 of 1.1.2 in git and push the tarball and rpms to the usual place:
ftp://libvirt.org/libvirt/
so the plan is to have an rc2 candidate on friday and if everything looks good push the final release 1.1.2 on Monday.
Please give it a try especially for potential portability issues,
Passes a compile test on OSX 10.7. ;) + Justin -- Open Source and Standards @ Red Hat twitter.com/realjustinclift
On 08/28/2013 09:55 PM, Daniel Veillard wrote:
I am a day late but I finally tagged the release candidate 1 of 1.1.2 in git and push the tarball and rpms to the usual place:
ftp://libvirt.org/libvirt/
so the plan is to have an rc2 candidate on friday and if everything looks good push the final release 1.1.2 on Monday.
Please give it a try especially for potential portability issues,
thanks in advance !
Just tested (preliminary) on x86. Works fine: ------------------- $ git describe v1.1.2-rc1 $ ./autogen.sh $ make -j5 && make check [...] All 92 tests passed (3 tests were not run) $ sudo yum-builddep libvirt -y $ make rpm $ cd /home/kashyap/rpmbuild/RPMS/x86_64/ $ sudo yum localinstall libvirt-*1.1.1*.rpm $ sudo virsh version Compiled against library: libvirt 1.1.1 Using library: libvirt 1.1.1 Using API: QEMU 1.1.1 Running hypervisor: QEMU 1.4.0 ------------------- The above was run on a host where I already have 10 Fedora/RHEL guests running. libvirtd restarts fine, all guests running smoothly.
Daniel
-- /kashyap
On Thu, Aug 29, 2013 at 12:25:57AM +0800, Daniel Veillard wrote:
I am a day late but I finally tagged the release candidate 1 of 1.1.2 in git and push the tarball and rpms to the usual place:
ftp://libvirt.org/libvirt/
so the plan is to have an rc2 candidate on friday and if everything looks good push the final release 1.1.2 on Monday.
1.1.2rc1 works fine with Boxes on my fedora 19 box. Christophe
On 08/28/2013 06:25 PM, Daniel Veillard wrote:
I am a day late but I finally tagged the release candidate 1 of 1.1.2 in git and push the tarball and rpms to the usual place:
ftp://libvirt.org/libvirt/
so the plan is to have an rc2 candidate on friday and if everything looks good push the final release 1.1.2 on Monday.
Please give it a try especially for potential portability issues,
thanks in advance !
Daniel
I see make check fail on a machine not running systemd (Ubuntu 12.04), not overly concerned about that, but maybe this test should be skipped in non-systemd environments? TEST: virsystemdtest process 23356: arguments to dbus_message_set_reply_serial() were incorrect, assertion "reply_serial != 0" failed in file ../../dbus/dbus-message.c line 1010. This is normally a bug in some application using the D-Bus library. /bin/bash: line 5: 23356 Segmentation fault (core dumped) abs_top_builddir=`cd '..'; pwd` abs_top_srcdir=`cd '../..'; pwd` abs_builddir=`pwd` abs_srcdir=`cd '../../tests'; pwd` CONFIG_HEADER="`cd '..'; pwd`/config.h" PATH=" `cd '..'; pwd`/daemon:`cd '..'; pwd`/tools:`cd '..'; pwd`/tests:$PATH" SHELL="/bin/bash" LIBVIRT_DRIVER_DIR="/home/mihajlov/src/checkout-tuxgit/libvirt/build/src/.libs" LIBVIRT_AUTOSTART=0 LC_ALL=C VIR_TEST_EXPENSIVE=0 ${dir}$tst -- Mit freundlichen Grüßen/Kind Regards Viktor Mihajlovski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martina Köderitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
On 08/29/2013 11:01 AM, Viktor Mihajlovski wrote:
I see make check fail on a machine not running systemd (Ubuntu 12.04), not overly concerned about that, but maybe this test should be skipped in non-systemd environments?
The point of this test is to mock out the system calls, so that it should work even on systems that lack systemd. It passes on both RHEL 5 and RHEL 6, both of which lack systemd. So that's not the real problem.
TEST: virsystemdtest process 23356: arguments to dbus_message_set_reply_serial() were incorrect, assertion "reply_serial != 0" failed in file
We are already providing an LD_PRELOAD override of dbus_message_set_reply_serial as part of that test, which SHOULD be avoiding that assert (at least, it did so on both RHEL 5 and current Fedora) (see commit 524f52c). Can you do some debugging under gdb to see why the preload is not being used on Ubuntu's version of dbus?
../../dbus/dbus-message.c line 1010. This is normally a bug in some application using the D-Bus library. /bin/bash: line 5: 23356 Segmentation fault (core dumped) abs_top_builddir=`cd '..'; pwd` abs_top_srcdir=`cd '../..'; pwd` abs_builddir=`pwd` abs_srcdir=`cd '../../tests'; pwd` CONFIG_HEADER="`cd '..'; pwd`/config.h" PATH=" `cd '..'; pwd`/daemon:`cd '..'; pwd`/tools:`cd '..'; pwd`/tests:$PATH" SHELL="/bin/bash" LIBVIRT_DRIVER_DIR="/home/mihajlov/src/checkout-tuxgit/libvirt/build/src/.libs" LIBVIRT_AUTOSTART=0 LC_ALL=C VIR_TEST_EXPENSIVE=0 ${dir}$tst
-- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 08/29/2013 07:08 PM, Eric Blake wrote:
We are already providing an LD_PRELOAD override of dbus_message_set_reply_serial as part of that test, which SHOULD be avoiding that assert (at least, it did so on both RHEL 5 and current Fedora) (see commit 524f52c). Can you do some debugging under gdb to see why the preload is not being used on Ubuntu's version of dbus?
The mechanism itself is working fine, but looking at the backtrace it seems that dbus_message_set_reply_serial is called from within a function that's not part of the mock library: Breakpoint 1, 0x00007ffff5aaf8e0 in dbus_message_set_reply_serial () from /lib/x86_64-linux-gnu/libdbus-1.so.3 (gdb) bt #0 0x00007ffff5aaf8e0 in dbus_message_set_reply_serial () from /lib/x86_64-linux-gnu/libdbus-1.so.3 #1 0x00007ffff5ab2a28 in dbus_message_new_method_return () from /lib/x86_64-linux-gnu/libdbus-1.so.3 #2 0x00007ffff770c71f in virDBusCallMethod (conn=0x1, replyout=0x0, destination=<optimized out>, path=<optimized out>, iface=0x7ffff791c8f0 "org.freedesktop.machine1.Manager", member=<optimized out>, types=0x7ffff791c9cb "sayssusa(sv)") at ../../src/util/virdbus.c:1151 #3 0x00007ffff77459c1 in virSystemdCreateMachine (name=<optimized out>, drivername=0x411d3d "lxc", privileged=<optimized out>, uuid=0x7fffffffded0 "\001\001\001\001\002\002\002\002\003\003\003\003\004\004\004\004", rootdir=<optimized out>, pidleader=123, iscontainer=true, partition=0x411db2 "highpriority.slice") at ../../src/util/virsystemd.c:213 #4 0x00000000004031e9 in testCreateContainer (opaque=<optimized out>) at ../../tests/virsystemdtest.c:39 #5 0x0000000000403f9d in virtTestRun (title=<optimized out>, nloops=1, body=0x403150 <testCreateContainer>, data=0x0) at ../../tests/testutils.c:169 #6 0x0000000000402bc1 in mymain () at ../../tests/virsystemdtest.c:178 #7 0x000000000040468b in virtTestMain (argc=1, argv=<optimized out>, func=0x402b90 <mymain>) at ../../tests/testutils.c:772 #8 0x00000000004029e0 in main (argc=1, argv=0x7fffffffe168) at ../../tests/virsystemdtest.c:207 as can be seen here: ldd -r .libs/virsystemdmock.so undefined symbol: dbus_set_error (.libs/virsystemdmock.so) linux-vdso.so.1 => (0x00007fff69bb2000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd46ecf0000) /lib64/ld-linux-x86-64.so.2 (0x00007fd46f2d2000) undefined symbol: dbus_message_new_error (.libs/virsystemdmock.so) undefined symbol: dbus_message_new_method_return (.libs/virsystemdmock.so) although the callstack seems to have fallen prey to the optimizer, virDBusCallMethod calls the mock dbus_connection_send_with_reply_and_block which in turn calls the real dbus_message_new_method_return which again calls dbus_message_set_reply_serial, but the real one instead of the mock version. On RHEL it's calling the mock ...reply_serial. On other occcasions I have observed that libtool on Ubuntu behaves differently than on RHEL or Fedora and maybe that's why the LD_PRELOAD works differently for intra-library calls there. But here I am entering the realm of wild speculations... -- Mit freundlichen Grüßen/Kind Regards Viktor Mihajlovski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martina Köderitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
On Fri, Aug 30, 2013 at 12:47:09PM +0200, Viktor Mihajlovski wrote:
On 08/29/2013 07:08 PM, Eric Blake wrote:
We are already providing an LD_PRELOAD override of dbus_message_set_reply_serial as part of that test, which SHOULD be avoiding that assert (at least, it did so on both RHEL 5 and current Fedora) (see commit 524f52c). Can you do some debugging under gdb to see why the preload is not being used on Ubuntu's version of dbus?
The mechanism itself is working fine, but looking at the backtrace it seems that dbus_message_set_reply_serial is called from within a function that's not part of the mock library:
Breakpoint 1, 0x00007ffff5aaf8e0 in dbus_message_set_reply_serial () from /lib/x86_64-linux-gnu/libdbus-1.so.3 (gdb) bt #0 0x00007ffff5aaf8e0 in dbus_message_set_reply_serial () from /lib/x86_64-linux-gnu/libdbus-1.so.3 #1 0x00007ffff5ab2a28 in dbus_message_new_method_return () from /lib/x86_64-linux-gnu/libdbus-1.so.3 #2 0x00007ffff770c71f in virDBusCallMethod (conn=0x1, replyout=0x0, destination=<optimized out>, path=<optimized out>, iface=0x7ffff791c8f0 "org.freedesktop.machine1.Manager", member=<optimized out>, types=0x7ffff791c9cb "sayssusa(sv)") at ../../src/util/virdbus.c:1151 #3 0x00007ffff77459c1 in virSystemdCreateMachine (name=<optimized out>, drivername=0x411d3d "lxc", privileged=<optimized out>, uuid=0x7fffffffded0 "\001\001\001\001\002\002\002\002\003\003\003\003\004\004\004\004", rootdir=<optimized out>, pidleader=123, iscontainer=true, partition=0x411db2 "highpriority.slice") at ../../src/util/virsystemd.c:213 #4 0x00000000004031e9 in testCreateContainer (opaque=<optimized out>) at ../../tests/virsystemdtest.c:39 #5 0x0000000000403f9d in virtTestRun (title=<optimized out>, nloops=1, body=0x403150 <testCreateContainer>, data=0x0) at ../../tests/testutils.c:169 #6 0x0000000000402bc1 in mymain () at ../../tests/virsystemdtest.c:178 #7 0x000000000040468b in virtTestMain (argc=1, argv=<optimized out>, func=0x402b90 <mymain>) at ../../tests/testutils.c:772 #8 0x00000000004029e0 in main (argc=1, argv=0x7fffffffe168) at ../../tests/virsystemdtest.c:207
as can be seen here:
ldd -r .libs/virsystemdmock.so undefined symbol: dbus_set_error (.libs/virsystemdmock.so) linux-vdso.so.1 => (0x00007fff69bb2000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd46ecf0000) /lib64/ld-linux-x86-64.so.2 (0x00007fd46f2d2000) undefined symbol: dbus_message_new_error (.libs/virsystemdmock.so) undefined symbol: dbus_message_new_method_return (.libs/virsystemdmock.so)
although the callstack seems to have fallen prey to the optimizer, virDBusCallMethod calls the mock dbus_connection_send_with_reply_and_block which in turn calls the real dbus_message_new_method_return which again calls dbus_message_set_reply_serial, but the real one instead of the mock version. On RHEL it's calling the mock ...reply_serial.
On other occcasions I have observed that libtool on Ubuntu behaves differently than on RHEL or Fedora and maybe that's why the LD_PRELOAD works differently for intra-library calls there. But here I am entering the realm of wild speculations...
I found the build logs for libdbus on Ubuntu https://launchpadlibrarian.net/142327590/buildlog_ubuntu-raring-i386.dbus_1.... Notice that '-Bsymbolic-functions' is passed when linking libdbus. This isn't something upstream dbus do, so must be an ubuntu specific linker flag. This causes all function calls made by libdbus to any other function inside libdbus to be strictly bound at link time. This prevents you using an LD_PRELOAD libraries to replace them, which really, really sucks. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Thu, Aug 29, 2013 at 07:01:07PM +0200, Viktor Mihajlovski wrote:
On 08/28/2013 06:25 PM, Daniel Veillard wrote:
I am a day late but I finally tagged the release candidate 1 of 1.1.2 in git and push the tarball and rpms to the usual place:
ftp://libvirt.org/libvirt/
so the plan is to have an rc2 candidate on friday and if everything looks good push the final release 1.1.2 on Monday.
Please give it a try especially for potential portability issues,
thanks in advance !
Daniel
I see make check fail on a machine not running systemd (Ubuntu 12.04), not overly concerned about that, but maybe this test should be skipped in non-systemd environments?
The test has no dependancy on systemd being present / installed.
TEST: virsystemdtest process 23356: arguments to dbus_message_set_reply_serial() were incorrect, assertion "reply_serial != 0" failed in file ../../dbus/dbus-message.c line 1010. This is normally a bug in some application using the D-Bus library. /bin/bash: line 5: 23356 Segmentation fault (core dumped)
The dbus_message_set_reply_serial() method is replaced in the LD_PRELOAD library. Somehow the LD_PRELOAD isn't getting used in your test run. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Thu, Aug 29, 2013 at 12:25:57AM +0800, Daniel Veillard wrote:
I am a day late but I finally tagged the release candidate 1 of 1.1.2 in git and push the tarball and rpms to the usual place:
ftp://libvirt.org/libvirt/
so the plan is to have an rc2 candidate on friday and if everything looks good push the final release 1.1.2 on Monday.
Please give it a try especially for potential portability issues,
What built so far on the buildds looks good (after applying the minor fix for the augeas lense I sent in yesterday): https://buildd.debian.org/status/package.php?p=libvirt&suite=experimental Cheers, -- Guido
thanks in advance !
Daniel
-- Daniel Veillard | Open Source and Standards, Red Hat veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 08/28/2013 06:25 PM, Daniel Veillard wrote:
I am a day late but I finally tagged the release candidate 1 of 1.1.2 in git and push the tarball and rpms to the usual place:
ftp://libvirt.org/libvirt/
so the plan is to have an rc2 candidate on friday and if everything looks good push the final release 1.1.2 on Monday.
Please give it a try especially for potential portability issues,
thanks in advance !
Daniel
Briefly kicked the tires on s390, no issues seen so far. -- Mit freundlichen Grüßen/Kind Regards Viktor Mihajlovski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martina Köderitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
On Fri, Aug 30, 2013 at 02:58:35PM +0200, Viktor Mihajlovski wrote:
On 08/28/2013 06:25 PM, Daniel Veillard wrote:
I am a day late but I finally tagged the release candidate 1 of 1.1.2 in git and push the tarball and rpms to the usual place:
ftp://libvirt.org/libvirt/
so the plan is to have an rc2 candidate on friday and if everything looks good push the final release 1.1.2 on Monday.
Please give it a try especially for potential portability issues,
thanks in advance !
Daniel
Briefly kicked the tires on s390, no issues seen so far.
Okay, thanks :-) Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/
On 08/28/2013 10:25 AM, Daniel Veillard wrote:
I am a day late but I finally tagged the release candidate 1 of 1.1.2 in git and push the tarball and rpms to the usual place:
ftp://libvirt.org/libvirt/
so the plan is to have an rc2 candidate on friday and if everything looks good push the final release 1.1.2 on Monday.
Please give it a try especially for potential portability issues,
thanks in advance !
Daniel
Running ./autobuild.sh (which does a cross-compiling to mingw from Linux) fails to build the mingw rpm with this message: Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/eblake/rpmbuild/BUILDROOT/mingw-libvirt-1.1.1-1.fc19.eblake1377879911.x86_64 error: Installed (but unpackaged) file(s) found: /usr/i686-w64-mingw32/sys-root/mingw/bin/virt-login-shell.exe /usr/i686-w64-mingw32/sys-root/mingw/etc/libvirt/virt-login-shell.conf /usr/i686-w64-mingw32/sys-root/mingw/etc/libvirt/virtlockd.conf /usr/i686-w64-mingw32/sys-root/mingw/share/augeas/lenses/tests/test_virtlockd.aug /usr/i686-w64-mingw32/sys-root/mingw/share/augeas/lenses/virtlockd.aug /usr/i686-w64-mingw32/sys-root/mingw/share/man/man1/virt-login-shell.1 /usr/i686-w64-mingw32/sys-root/mingw/share/man/man8/virtlockd.8 /usr/x86_64-w64-mingw32/sys-root/mingw/bin/virt-login-shell.exe /usr/x86_64-w64-mingw32/sys-root/mingw/etc/libvirt/virt-login-shell.conf /usr/x86_64-w64-mingw32/sys-root/mingw/etc/libvirt/virtlockd.conf /usr/x86_64-w64-mingw32/sys-root/mingw/share/augeas/lenses/tests/test_virtlockd.aug /usr/x86_64-w64-mingw32/sys-root/mingw/share/augeas/lenses/virtlockd.aug /usr/x86_64-w64-mingw32/sys-root/mingw/share/man/man1/virt-login-shell.1 /usr/x86_64-w64-mingw32/sys-root/mingw/share/man/man8/virtlockd.8 Why are we even building a virt-login-shell.exe? virt-login-shell only makes sense for LXC, which is a Linux-only concept. virtlockd may make sense on mingw, so I'm not sure what needs to be done there, but it would be nice to get this fixed up before 1.1.2 goes out the door. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 08/30/2013 11:51 AM, Eric Blake wrote:
On 08/28/2013 10:25 AM, Daniel Veillard wrote:
I am a day late but I finally tagged the release candidate 1 of 1.1.2 in git and push the tarball and rpms to the usual place:
ftp://libvirt.org/libvirt/
so the plan is to have an rc2 candidate on friday and if everything looks good push the final release 1.1.2 on Monday.
Please give it a try especially for potential portability issues,
thanks in advance !
Daniel
Running ./autobuild.sh (which does a cross-compiling to mingw from Linux) fails to build the mingw rpm with this message:
Why are we even building a virt-login-shell.exe? virt-login-shell only makes sense for LXC, which is a Linux-only concept. virtlockd may make sense on mingw, so I'm not sure what needs to be done there, but it would be nice to get this fixed up before 1.1.2 goes out the door.
Solved; ./autobuild.sh on the latest master now runs to successful completion, including cross-compilation to mingw. There's still a report of mingw not building with winpthreads that I have not had a chance to investigate; I'm still in the process of tweaking my rawhide VM to test that, but ran out of time today. If it misses 1.1.2, it won't be the end of the world (we can always backport the patch when building the actual mingw-libvirt rpm if it misses this release). So from my end, I don't know of any release show-stoppers. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Oops I pushed on friday but forgot to finish sending the message ! Thanks everybody for the feedback, I have now pushed rc2 to the usual place as tarball and rpms: ftp://libvirt.org/libvirt/ and of course tagged it in git. Hopefully it will include the security fixes discussed earlier Works fine for my simple testing, Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/
On 31/08/2013, at 3:34 PM, Daniel Veillard wrote:
Oops I pushed on friday but forgot to finish sending the message !
Thanks everybody for the feedback, I have now pushed rc2 to the usual place as tarball and rpms:
ftp://libvirt.org/libvirt/
and of course tagged it in git. Hopefully it will include the security fixes discussed earlier
Works fine for my simple testing,
This one seems fine for simple compile testing on OSX 10.7 too. :) + Justin -- Open Source and Standards @ Red Hat twitter.com/realjustinclift
participants (9)
-
Christophe Fergeau -
Daniel P. Berrange -
Daniel Veillard -
Doug Goldstein -
Eric Blake -
Guido Günther -
Justin Clift -
Kashyap Chamarthy -
Viktor Mihajlovski