[libvirt] Entering freeze for libvirt-1.2.4
As planned on Friday, I tagged the tree earlier today for Release Candidate 1, the tarball and rpms are available from the usual place: ftp://libvirt.org/libvirt/ Seems to work fine in my limited testing, but distcheck failed with xsltproc being unable to access ../../ . I don't think anything changed there on my side so it smells like a new problem. Otherwise looks good to me so far, with a bit of luck we can push 1.2.4 end of Friday or sometime next week-end, 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/
Hi, On Mon, Apr 28, 2014 at 03:38:40PM +0800, Daniel Veillard wrote:
As planned on Friday, I tagged the tree earlier today for Release Candidate 1, the tarball and rpms are available from the usual place:
ftp://libvirt.org/libvirt/
Seems to work fine in my limited testing, but distcheck failed with xsltproc being unable to access ../../ . I don't think anything changed there on my side so it smells like a new problem.
Otherwise looks good to me so far, with a bit of luck we can push 1.2.4 end of Friday or sometime next week-end,
I'm currently seeing some test failures on i386 Debian wheezy: virstoragetest -------------- 97) Chain lookup 27 ... index: expected 0, got 4294967295 FAILED qemucaps2xmltest ---------------- TEST: qemucaps2xmltest 1) all_1.6.0-1 ... Offset 295 Expect [ <domain type='kvm'> <emulator>/usr/bin/qemu-system-i386</emulator> </domain> <] Actual [<] ... FAILED 2) nodisksnapshot_1.6.0-1 ... Offset 295 Expect [ <domain type='kvm'> <emulator>/usr/bin/qemu-system-i386</emulator> </domain> <] Actual [<] ... FAILED The full log is at: http://honk.sigxcpu.org:8001/job/libvirt-check/2232/consoleFull I won't be able to investigate myself in the near future so I thought I at least report it. Cheers, -- Guido
On Mon, Apr 28, 2014 at 19:14:02 +0200, Guido Günther wrote:
Hi, On Mon, Apr 28, 2014 at 03:38:40PM +0800, Daniel Veillard wrote:
As planned on Friday, I tagged the tree earlier today for Release Candidate 1, the tarball and rpms are available from the usual place:
ftp://libvirt.org/libvirt/
Seems to work fine in my limited testing, but distcheck failed with xsltproc being unable to access ../../ . I don't think anything changed there on my side so it smells like a new problem.
Otherwise looks good to me so far, with a bit of luck we can push 1.2.4 end of Friday or sometime next week-end,
I'm currently seeing some test failures on i386 Debian wheezy:
virstoragetest --------------
97) Chain lookup 27 ... index: expected 0, got 4294967295 FAILED
Yeah, our virStrToLong_* APIs are not doing a very good job here. The problem is that virStrToLong_ui happily parses -1 as 4294967295 on systems where sizeof(unsigned long) == sizeof(unsigned int). I'm not sure what's the best solution for this. Should we parse the string with strtoull instead of strtoul to make it a little bit better since unsigned long long will always be bigger than unsigned int? Anyway, I hate strtou* for silently parsing negative numbers. Jirka
On 04/29/2014 01:42 AM, Jiri Denemark wrote:
I'm currently seeing some test failures on i386 Debian wheezy:
Thanks for doing 32-bit testing.
virstoragetest --------------
97) Chain lookup 27 ... index: expected 0, got 4294967295 FAILED
Yeah, our virStrToLong_* APIs are not doing a very good job here. The problem is that virStrToLong_ui happily parses -1 as 4294967295 on systems where sizeof(unsigned long) == sizeof(unsigned int).
We DO have places in our code base where we WANT to parse -1 as ULONG_MAX (it is a convenience of virsh to be able to have one spelling that works for both 32- and 64-bit hosts).
I'm not sure what's the best solution for this. Should we parse the string with strtoull instead of strtoul to make it a little bit better since unsigned long long will always be bigger than unsigned int? Anyway, I hate strtou* for silently parsing negative numbers.
Outright rejecting negative numbers by default in our strto* wrappers does not feel right; maybe we need to flavors of the unsigned wrappers, the normal one that accepts negatives, and a new stricter one that rejects negatives. At any rate, I'll investigate today and propose something. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
The tag is in the tree, and I have pushed tarball and signed rpms to the usual place: ftp://libvirt.org/libvirt/ That time no error with distcheck and my -limited- testing looks good So assuming no serious issue until Friday i may push that release on the 2nd or posisbly during the w.e. Give it a good try, hopefully it's all good 32bits test failure aside, 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/
participants (4)
-
Daniel Veillard -
Eric Blake -
Guido Günther -
Jiri Denemark