9:52 p.m.
We are in freeze ! I tagged the release candidate 1 in git and
pushed signed tarball and rpms to the usual place:
ftp://libvirt.org/libvirt/
that looks fine with my very limited testing, but that's likely
not indicative of the actual stability :)
https://ci.centos.org/view/libvirt-project/ is rather positive
though someone should look at a potential FreeBSD portability issue
based on the report (or that could be that the Jenkins test need
a bit of attention)
Plan is to have RC2 on Friday and try to push 1.3.4 final from
airport in Sunday (so there is a little bit of risk there).
Please give it a try !
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/
5:48 a.m.
On Wed, 2016-04-27 at 10:52 +0800, Daniel Veillard wrote:
[...] someone should look at a potential FreeBSD portability issue
based on the report (or that could be that the Jenkins test need
a bit of attention)
I believe the libvirt-freebsd Jenkins job has been phased out
in favor of adding the FreeBSD build slave to the same
libvirt-daemon-build job used for Linux builds.
The downstream libvirt-daemon-syntax-check and
libvirt-daemon-check don't seem to have been updated to
reflect this change yet, nor have the libvirt-freebsd and
libvirt-freebsd-daemon-check jobs been removed.
CCing Suren and Roman so they can give their take on the matter,
but I'm fairly confident FreeBSD is doing just fine :)
--
Andrea Bolognani
Software Engineer - Virtualization Team
6:15 a.m.
Andrea Bolognani wrote:
On Wed, 2016-04-27 at 10:52 +0800, Daniel Veillard wrote:
>
> [...] someone should look at a potential FreeBSD portability issue
> based on the report (or that could be that the Jenkins test need
> a bit of attention)
I believe the libvirt-freebsd Jenkins job has been phased out
in favor of adding the FreeBSD build slave to the same
libvirt-daemon-build job used for Linux builds.
The downstream libvirt-daemon-syntax-check and
libvirt-daemon-check don't seem to have been updated to
reflect this change yet, nor have the libvirt-freebsd and
libvirt-freebsd-daemon-check jobs been removed.
CCing Suren and Roman so they can give their take on the matter,
but I'm fairly confident FreeBSD is doing just fine :)
Yeah, I'm not having any issues on FreeBSD so far, so I assume these
issues are related to Jenkins configuration.
However, there's at least one thing that's currently broken: the new
peer address feature, when running with ifconfig, uses Linux specific
syntax and in terms of peer address FreeBSD's ifconfig behaves
differently. I haven't started working on the fix so far. :(
Roman Bogorodskiy
9:52 a.m.
On 04/27/2016 07:15 AM, Roman Bogorodskiy wrote:
Andrea Bolognani wrote:
> On Wed, 2016-04-27 at 10:52 +0800, Daniel Veillard wrote:
>>
>> [...] someone should look at a potential FreeBSD portability issue
>> based on the report (or that could be that the Jenkins test need
>> a bit of attention)
> I believe the libvirt-freebsd Jenkins job has been phased out
> in favor of adding the FreeBSD build slave to the same
> libvirt-daemon-build job used for Linux builds.
>
> The downstream libvirt-daemon-syntax-check and
> libvirt-daemon-check don't seem to have been updated to
> reflect this change yet, nor have the libvirt-freebsd and
> libvirt-freebsd-daemon-check jobs been removed.
>
> CCing Suren and Roman so they can give their take on the matter,
> but I'm fairly confident FreeBSD is doing just fine :)
Yeah, I'm not having any issues on FreeBSD so far, so I assume these
issues are related to Jenkins configuration.
However, there's at least one thing that's currently broken: the new
peer address feature, when running with ifconfig, uses Linux specific
syntax and in terms of peer address FreeBSD's ifconfig behaves
differently. I haven't started working on the fix so far. :(
It is broken in other ways as well. I have a few patches for it that I
need to send. (For your problem, since the bhve driver doesn't support
setting the peer, I guess for now you could just log an error if peer
was set.)
But beyond that I think that "peer" may not be the best name for the new
attribute. The way it was added, the new attribute would indeed be
placed in the "peer" field of the netlink request for setting the IP
address, but in the case of qemu this was only because address and peer
were mixed up (see my mail about it from yesterday:
https://www.redhat.com/archives/libvir-list/2016-April/msg01663.html
That this mixup was able to get into the code implies that the name
"peer" is uninformative at best, and could be confusing ("peer" from
who's point of view?). I suggested that it be named "host" or
"hostAddress", but haven't gotten any upvotes so far. Can anyone come up
with a better name? (Basically if you have <ip address='A'
peer='B'/>,
then "A" is the IP address of the guest, and "B" is the IP address of
the host-end of that interface; for lxc veth interfaces, it does end up
that "address" is put in the address field and "peer" in the peer
field,
but for qemu it's exactly the opposite.) If we are going to change it,
it must be now before the first release containing the new
functionality. (I suppose as long as it was *heavily* documented that
the "peer" was from the point of view of the guest, that name would be
okay; something more self-documenting would lead to less confusion though).
8:37 a.m.
On Wed, Apr 27, 2016 at 10:52:35AM +0800, Daniel Veillard wrote:
We are in freeze ! I tagged the release candidate 1 in git and
pushed signed tarball and rpms to the usual place:
ftp://libvirt.org/libvirt/
that looks fine with my very limited testing, but that's likely
not indicative of the actual stability :)
https://ci.centos.org/view/libvirt-project/ is rather positive
though someone should look at a potential FreeBSD portability issue
based on the report (or that could be that the Jenkins test need
a bit of attention)
Plan is to have RC2 on Friday and try to push 1.3.4 final from
airport in Sunday (so there is a little bit of risk there).
Please give it a try !
I'm seeing a broken archive
$ tar zxf ../libvirt-1.3.4-rc1.tar.gz
gzip: stdin: unexpected end of file
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
with
c1d9602b5bb05e67f13ac141e3e987540467c632 ../libvirt-1.3.4-rc1.tar.gz
even after fetching the file again. Could anybody else check?
cheers,
-- Guido
9:03 a.m.
On Wed, 2016-04-27 at 15:37 +0200, Guido Günther wrote:
I'm seeing a broken archive
$ tar zxf ../libvirt-1.3.4-rc1.tar.gz
gzip: stdin: unexpected end of file
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
with
c1d9602b5bb05e67f13ac141e3e987540467c632 ../libvirt-1.3.4-rc1.tar.gz
even after fetching the file again. Could anybody else check?
Same here, even though the checksum is different.
The previous release archive weighs in at 29MB while this one
is just 9.3MB, so I guess the upload was interrupted.
--
Andrea Bolognani
Software Engineer - Virtualization Team
9:11 a.m.
On Wed, Apr 27, 2016 at 04:03:30PM +0200, Andrea Bolognani wrote:
On Wed, 2016-04-27 at 15:37 +0200, Guido Günther wrote:
>
> I'm seeing a broken archive
>
> $ tar zxf ../libvirt-1.3.4-rc1.tar.gz
>
> gzip: stdin: unexpected end of file
> tar: Unexpected EOF in archive
> tar: Unexpected EOF in archive
> tar: Error is not recoverable: exiting now
>
> with
>
> c1d9602b5bb05e67f13ac141e3e987540467c632 ../libvirt-1.3.4-rc1.tar.gz
>
> even after fetching the file again. Could anybody else check?
Same here, even though the checksum is different.
The previous release archive weighs in at 29MB while this one
is just 9.3MB, so I guess the upload was interrupted.
yup the rsync resumed at 45% of the archive <grin/>
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:10 a.m.
On Wed, Apr 27, 2016 at 03:37:47PM +0200, Guido Günther wrote:
On Wed, Apr 27, 2016 at 10:52:35AM +0800, Daniel Veillard wrote:
> We are in freeze ! I tagged the release candidate 1 in git and
> pushed signed tarball and rpms to the usual place:
>
> ftp://libvirt.org/libvirt/
>
>
> that looks fine with my very limited testing, but that's likely
> not indicative of the actual stability :)
> https://ci.centos.org/view/libvirt-project/ is rather positive
> though someone should look at a potential FreeBSD portability issue
> based on the report (or that could be that the Jenkins test need
> a bit of attention)
>
> Plan is to have RC2 on Friday and try to push 1.3.4 final from
> airport in Sunday (so there is a little bit of risk there).
>
> Please give it a try !
I'm seeing a broken archive
$ tar zxf ../libvirt-1.3.4-rc1.tar.gz
gzip: stdin: unexpected end of file
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
with
c1d9602b5bb05e67f13ac141e3e987540467c632 ../libvirt-1.3.4-rc1.tar.gz
even after fetching the file again. Could anybody else check?
cheers,
Hum, locally:
thinkpad2:~/libvirt -> md5sum libvirt-1.3.4-rc1.tar.gz
ce794c9344ea96d119e2c1a0c71775fa libvirt-1.3.4-rc1.tar.gz
thinkpad2:~/libvirt ->
on server
[root@libvirt libvirt]# md5sum libvirt-1.3.4-rc1.tar.gz
2c6d51a95b09678744c21b883789e666 libvirt-1.3.4-rc1.tar.gz
[root@libvirt libvirt]#
argh ... rsync -avP to clean up the mess and
[root@libvirt libvirt]# md5sum libvirt-1.3.4-rc1.tar.gz
ce794c9344ea96d119e2c1a0c71775fa libvirt-1.3.4-rc1.tar.gz
root@libvirt libvirt]# gpg --verify libvirt-1.3.4-rc1.tar.gz.asc
gpg: Signature made Wed 27 Apr 2016 03:36:37 AM CEST using DSA key ID DE95BC1F
gpg: Good signature from "Daniel Veillard (Red Hat work email)
<veillard(a)redhat.com>"
gpg: aka "Daniel Veillard <Daniel.Veillard(a)w3.org>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: C744 15BA 7C9C 7F78 F02E 1DC3 4606 B8A5 DE95 BC1F
[root@libvirt libvirt]#
should be all setC :-)
thanks for reporting this Guido !
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:42 a.m.
On Wed, Apr 27, 2016 at 10:10:47PM +0800, Daniel Veillard wrote:
On Wed, Apr 27, 2016 at 03:37:47PM +0200, Guido Günther wrote:
> On Wed, Apr 27, 2016 at 10:52:35AM +0800, Daniel Veillard wrote:
> > We are in freeze ! I tagged the release candidate 1 in git and
> > pushed signed tarball and rpms to the usual place:
> >
> > ftp://libvirt.org/libvirt/
> >
> >
> > that looks fine with my very limited testing, but that's likely
> > not indicative of the actual stability :)
> > https://ci.centos.org/view/libvirt-project/ is rather positive
> > though someone should look at a potential FreeBSD portability issue
> > based on the report (or that could be that the Jenkins test need
> > a bit of attention)
> >
> > Plan is to have RC2 on Friday and try to push 1.3.4 final from
> > airport in Sunday (so there is a little bit of risk there).
> >
> > Please give it a try !
>
> I'm seeing a broken archive
>
> $ tar zxf ../libvirt-1.3.4-rc1.tar.gz
>
> gzip: stdin: unexpected end of file
> tar: Unexpected EOF in archive
> tar: Unexpected EOF in archive
> tar: Error is not recoverable: exiting now
>
> with
>
> c1d9602b5bb05e67f13ac141e3e987540467c632 ../libvirt-1.3.4-rc1.tar.gz
>
> even after fetching the file again. Could anybody else check?
> cheers,
Hum, locally:
thinkpad2:~/libvirt -> md5sum libvirt-1.3.4-rc1.tar.gz
ce794c9344ea96d119e2c1a0c71775fa libvirt-1.3.4-rc1.tar.gz
thinkpad2:~/libvirt ->
on server
[root@libvirt libvirt]# md5sum libvirt-1.3.4-rc1.tar.gz
2c6d51a95b09678744c21b883789e666 libvirt-1.3.4-rc1.tar.gz
[root@libvirt libvirt]#
argh ... rsync -avP to clean up the mess and
[root@libvirt libvirt]# md5sum libvirt-1.3.4-rc1.tar.gz
ce794c9344ea96d119e2c1a0c71775fa libvirt-1.3.4-rc1.tar.gz
root@libvirt libvirt]# gpg --verify libvirt-1.3.4-rc1.tar.gz.asc
gpg: Signature made Wed 27 Apr 2016 03:36:37 AM CEST using DSA key ID DE95BC1F
gpg: Good signature from "Daniel Veillard (Red Hat work email)
<veillard(a)redhat.com>"
gpg: aka "Daniel Veillard <Daniel.Veillard(a)w3.org>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: C744 15BA 7C9C 7F78 F02E 1DC3 4606 B8A5 DE95 BC1F
[root@libvirt libvirt]#
should be all setC :-)
thanks for reporting this Guido !
Works now. Thanks!
-- Guido
8:10 p.m.
New subject: [libvirt] Availability of release candidate 2 of libvirt-1.3.4
This is tagged in git, signed tarball and rpms are uploaded
(hopefully correctly that time :) to the usual place:
ftp://libvirt.org/libvirt/
Again with my limited testing everything looks fine, and based
on current feedback it seems other people are happy with rc1.
Please test rc2, and if nothing serious is raised I will
try to push 1.3.4 final on Sunday,
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/
3130
days inactive
3132
days old
9 comments
5 participants
participants (5)
-
Andrea Bolognani -
Daniel Veillard -
Guido Günther -
Laine Stump -
Roman Bogorodskiy