11:38 a.m.
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(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | virtualization library http://libvirt.org/
9:14 p.m.
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
11:42 a.m.
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
5:14 p.m.
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
11:12 a.m.
New subject: [libvirt] Availability of libvirt-1.2.4 Release Candidate 2
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(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | virtualization library http://libvirt.org/
4007
days inactive
4009
days old
4 comments
4 participants
participants (4)
-
Daniel Veillard -
Eric Blake -
Guido Günther -
Jiri Denemark