qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/4] configure: Avoid using libssh deprecated AP


From: Andrea Bolognani
Subject: Re: [Qemu-devel] [PATCH 2/4] configure: Avoid using libssh deprecated API
Date: Wed, 14 Aug 2019 16:51:48 +0200
User-agent: Evolution 3.32.4 (3.32.4-1.fc30)

On Wed, 2019-08-14 at 16:15 +0200, Philippe Mathieu-Daudé wrote:
> On 8/14/19 3:27 PM, Andrea Bolognani wrote:
> > On Wed, 2019-08-14 at 14:15 +0200, Philippe Mathieu-Daudé wrote:
> > > The libssh packaged by a distribution can predate version 0.8,
> > > but still provides the newer API introduced after version 0.7.
> > > 
> > > Using the deprecated API leads to build failure, as on Ubuntu 18.04:
> > > 
> > >     CC      block/ssh.o
> > >   block/ssh.c: In function 'check_host_key_hash':
> > >   block/ssh.c:444:5: error: 'ssh_get_publickey' is deprecated 
> > > [-Werror=deprecated-declarations]
> > >        r = ssh_get_publickey(s->session, &pubkey);
> > >        ^
> > >   In file included from block/ssh.c:27:0:
> > >   /usr/include/libssh/libssh.h:489:31: note: declared here
> > >    SSH_DEPRECATED LIBSSH_API int ssh_get_publickey(ssh_session session, 
> > > ssh_key *key);
> > >                                  ^~~~~~~~~~~~~~~~~
> > >   rules.mak:69: recipe for target 'block/ssh.o' failed
> > >   make: *** [block/ssh.o] Error 1
> > > 
> > > Fix by using the newer API if available.
> > > 
> > > Suggested-by: Andrea Bolognani <address@hidden>
> > > Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
> > > ---
> > >  block/ssh.c | 2 +-
> > >  configure   | 7 +++++++
> > >  2 files changed, 8 insertions(+), 1 deletion(-)
> > 
> > Did I really suggest this? I have no recollection of doing so, or
> > even getting involved with libssh support in QEMU at all for that
> > matter.
> 
> I took this suggestion from
> https://www.redhat.com/archives/libvir-list/2018-May/msg00597.html

I see :)

I feel like adding a Suggested-by because of something that was
posted on an unrelated project's mailing list is stretching the
definition of the tag a bit, so if you end up having to respin I
think it would be reasonable to drop it, but honestly it's not a
big deal either way: I was just curious.

-- 
Andrea Bolognani / Red Hat / Virtualization




reply via email to

[Prev in Thread] Current Thread [Next in Thread]