[PATCH] docs: Fix virtiofsd.1 location

2020-02-12 Thread Miroslav Rezanina
Patch 6a7e2bbee5 docs: add virtiofsd(1) man page introduced new man
page virtiofsd.1. Unfortunately, wrong file location is used as
source for install command. This cause installation of docs fail.

Fixing wrong location so installation is successful.

Signed-off-by: Miroslav Rezanina 
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index f0e1a2f..62a367d 100644
--- a/Makefile
+++ b/Makefile
@@ -865,7 +865,7 @@ ifdef CONFIG_VIRTFS
$(INSTALL_DATA) $(MANUAL_BUILDDIR)/interop/virtfs-proxy-helper.1 
"$(DESTDIR)$(mandir)/man1"
 endif
 ifeq ($(CONFIG_LINUX)$(CONFIG_SECCOMP)$(CONFIG_LIBCAP_NG),yyy)
-   $(INSTALL_DATA) docs/interop/virtiofsd.1 "$(DESTDIR)$(mandir)/man1"
+   $(INSTALL_DATA) $(MANUAL_BUILDDIR)/interop/virtiofsd.1 
"$(DESTDIR)$(mandir)/man1"
 endif

 install-datadir:
-- 
1.8.3.1





Re: [PATCH] docs: Fix virtiofsd.1 location

2020-02-12 Thread Peter Maydell
On Wed, 12 Feb 2020 at 13:16, Miroslav Rezanina  wrote:
>
> Patch 6a7e2bbee5 docs: add virtiofsd(1) man page introduced new man
> page virtiofsd.1. Unfortunately, wrong file location is used as
> source for install command. This cause installation of docs fail.
>
> Fixing wrong location so installation is successful.
>
> Signed-off-by: Miroslav Rezanina 

Reviewed-by: Peter Maydell 

I noticed this in review of v1 of the patch
https://patchew.org/QEMU/20200127162514.56784-1-stefa...@redhat.com/
but missed that it hadn't been fixed in v2/v3.

thanks
-- PMM



Re: [PATCH] docs: Fix virtiofsd.1 location

2020-02-12 Thread Dr. David Alan Gilbert
* Peter Maydell (peter.mayd...@linaro.org) wrote:
> On Wed, 12 Feb 2020 at 13:16, Miroslav Rezanina  wrote:
> >
> > Patch 6a7e2bbee5 docs: add virtiofsd(1) man page introduced new man
> > page virtiofsd.1. Unfortunately, wrong file location is used as
> > source for install command. This cause installation of docs fail.
> >
> > Fixing wrong location so installation is successful.
> >
> > Signed-off-by: Miroslav Rezanina 
> 
> Reviewed-by: Peter Maydell 
> 
> I noticed this in review of v1 of the patch
> https://patchew.org/QEMU/20200127162514.56784-1-stefa...@redhat.com/
> but missed that it hadn't been fixed in v2/v3.

Oops thanks!

Does someone want to take this via build or trivial - I've not got
any more virtiofsd stuff currently queued.

Dave

> thanks
> -- PMM
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK




Re: [PATCH] docs: Fix virtiofsd.1 location

2020-02-12 Thread Daniel P . Berrangé
On Wed, Feb 12, 2020 at 02:18:19PM +, Peter Maydell wrote:
> On Wed, 12 Feb 2020 at 13:16, Miroslav Rezanina  wrote:
> >
> > Patch 6a7e2bbee5 docs: add virtiofsd(1) man page introduced new man
> > page virtiofsd.1. Unfortunately, wrong file location is used as
> > source for install command. This cause installation of docs fail.
> >
> > Fixing wrong location so installation is successful.
> >
> > Signed-off-by: Miroslav Rezanina 
> 
> Reviewed-by: Peter Maydell 
> 
> I noticed this in review of v1 of the patch
> https://patchew.org/QEMU/20200127162514.56784-1-stefa...@redhat.com/
> but missed that it hadn't been fixed in v2/v3.

How come the mistake didn't break any of our CI ?  Looks like it
should have failed due to non-existing source file


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|




Re: [PATCH] docs: Fix virtiofsd.1 location

2020-02-12 Thread Peter Maydell
On Wed, 12 Feb 2020 at 14:28, Daniel P. Berrangé  wrote:
>
> On Wed, Feb 12, 2020 at 02:18:19PM +, Peter Maydell wrote:
> > On Wed, 12 Feb 2020 at 13:16, Miroslav Rezanina  wrote:
> > >
> > > Patch 6a7e2bbee5 docs: add virtiofsd(1) man page introduced new man
> > > page virtiofsd.1. Unfortunately, wrong file location is used as
> > > source for install command. This cause installation of docs fail.
> > >
> > > Fixing wrong location so installation is successful.
> > >
> > > Signed-off-by: Miroslav Rezanina 
> >
> > Reviewed-by: Peter Maydell 
> >
> > I noticed this in review of v1 of the patch
> > https://patchew.org/QEMU/20200127162514.56784-1-stefa...@redhat.com/
> > but missed that it hadn't been fixed in v2/v3.
>
> How come the mistake didn't break any of our CI ?  Looks like it
> should have failed due to non-existing source file

I imagine all our CI setups use separate-build-dir and don't
test 'make install'. This only shows up if you do build-in-source-tree
and then 'make install'. (In a separate-build-dir setup, the
MANUAL_BUILDDIR is the same as the actual build dir,
which is the same as make's current working directory, so
forgetting it in the install rune doesn't matter. In a build from
the source tree, Sphinx requires the output to be to a
different directory than the source, so we have to create
a subdirectory to be the MANUAL_BUILDDIR.)

thanks
-- PMM



Re: [PATCH] docs: Fix virtiofsd.1 location

2020-02-12 Thread Philippe Mathieu-Daudé

On 2/12/20 5:02 PM, Peter Maydell wrote:

On Wed, 12 Feb 2020 at 14:28, Daniel P. Berrangé  wrote:


On Wed, Feb 12, 2020 at 02:18:19PM +, Peter Maydell wrote:

On Wed, 12 Feb 2020 at 13:16, Miroslav Rezanina  wrote:


Patch 6a7e2bbee5 docs: add virtiofsd(1) man page introduced new man
page virtiofsd.1. Unfortunately, wrong file location is used as
source for install command. This cause installation of docs fail.

Fixing wrong location so installation is successful.

Signed-off-by: Miroslav Rezanina 


Reviewed-by: Peter Maydell 

I noticed this in review of v1 of the patch
https://patchew.org/QEMU/20200127162514.56784-1-stefa...@redhat.com/
but missed that it hadn't been fixed in v2/v3.


How come the mistake didn't break any of our CI ?  Looks like it
should have failed due to non-existing source file


We stopped testing in-tree builds 2 months ago:

commit bc4486fb233573e77b6e9ad6d6379afb5e37ad8c
Author: Paolo Bonzini 
Date:   Wed Dec 11 15:33:49 2019 +0100

ci: build out-of-tree

Most developers are using out-of-tree builds and it was discussed 
in the past
to only allow those.  To prepare for the transition, use 
out-of-tree builds

in all continuous integration jobs.



I imagine all our CI setups use separate-build-dir and don't
test 'make install'. This only shows up if you do build-in-source-tree
and then 'make install'. (In a separate-build-dir setup, the
MANUAL_BUILDDIR is the same as the actual build dir,
which is the same as make's current working directory, so
forgetting it in the install rune doesn't matter. In a build from
the source tree, Sphinx requires the output to be to a
different directory than the source, so we have to create
a subdirectory to be the MANUAL_BUILDDIR.)

thanks
-- PMM






Re: [PATCH] docs: Fix virtiofsd.1 location

2020-02-12 Thread Peter Maydell
On Wed, 12 Feb 2020 at 16:51, Philippe Mathieu-Daudé  wrote:
> We stopped testing in-tree builds 2 months ago:
>
> commit bc4486fb233573e77b6e9ad6d6379afb5e37ad8c
> Author: Paolo Bonzini 
> Date:   Wed Dec 11 15:33:49 2019 +0100
>
>  ci: build out-of-tree
>
>  Most developers are using out-of-tree builds and it was discussed
> in the past
>  to only allow those.  To prepare for the transition, use
> out-of-tree builds
>  in all continuous integration jobs.

I'd missed that. Paolo, do you have a plan for following
through and actively forbidding in-tree-builds, if that's
the route we're taking ?

thanks
-- PMM



Re: [PATCH] docs: Fix virtiofsd.1 location

2020-02-13 Thread Paolo Bonzini


On 12/02/20 18:51, Peter Maydell wrote:
> On Wed, 12 Feb 2020 at 16:51, Philippe Mathieu-Daudé  
> wrote:
>> We stopped testing in-tree builds 2 months ago:
>>
>> commit bc4486fb233573e77b6e9ad6d6379afb5e37ad8c
>> Author: Paolo Bonzini 
>> Date:   Wed Dec 11 15:33:49 2019 +0100
>>
>>  ci: build out-of-tree
>>
>> Most developers are using out-of-tree builds and it was discussed 
>> in the past to only allow those.  To prepare for the transition,
>> use out-of-tree builds in all continuous integration jobs.
>
> I'd missed that. Paolo, do you have a plan for following
> through and actively forbidding in-tree-builds, if that's
> the route we're taking ?

I can follow up on that, yes.

Paolo