11:25 a.m.
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(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | virtualization library http://libvirt.org/
12:31 p.m.
On Wed, Aug 28, 2013 at 11:25 AM, Daniel Veillard <veillard(a)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(a)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
12:13 p.m.
[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
12:18 p.m.
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
12:38 p.m.
On Thu, Aug 29, 2013 at 12:18 PM, Justin Clift <jclift(a)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.
--
Doug Goldstein
1:26 p.m.
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(a)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 :|
1:12 a.m.
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
1:02 p.m.
New subject: [libvirt] [Libvirt-announce] Entering freeze for libvirt-1.1.2
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
1:11 p.m.
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
8:48 a.m.
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
12:01 p.m.
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
12:08 p.m.
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
5:47 a.m.
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
6:32 a.m.
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...
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 :|
12:12 p.m.
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 :|
1:06 a.m.
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=experime...
Cheers,
-- Guido
thanks in advance !
Daniel
--
Daniel Veillard | Open Source and Standards, Red Hat
veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | virtualization library http://libvirt.org/
--
libvir-list mailing list
libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
7:58 a.m.
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
7:16 p.m.
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(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | virtualization library http://libvirt.org/
12:51 p.m.
New subject: [libvirt] [Libvirt-announce] Entering freeze for libvirt-1.1.2
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
10:13 p.m.
New subject: [libvirt] [Libvirt-announce] Entering freeze for libvirt-1.1.2
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
9:34 a.m.
New subject: [libvirt] Availability of release candidate 2 of libvirt 1.1.2
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(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | virtualization library http://libvirt.org/
3:17 p.m.
New subject: [libvirt] [Libvirt-announce] Availability of release candidate 2 of libvirt 1.1.2
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
4098
days inactive
4103
days old
21 comments
9 participants
participants (9)
-
Christophe Fergeau -
Daniel P. Berrange -
Daniel Veillard -
Doug Goldstein -
Eric Blake -
Guido Günther -
Justin Clift -
Kashyap Chamarthy -
Viktor Mihajlovski