diff mbox series

maintainers: Add myself as a OpenBSD maintainer

Message ID 20180216164620.GA53727@humpty.home.comstyle.com
State New
Headers show
Series maintainers: Add myself as a OpenBSD maintainer | expand

Commit Message

Brad Smith Feb. 16, 2018, 4:46 p.m. UTC
Add myself as an OpenBSD maintainer and add OpenBSD as maintained.

Signed-off-by: Brad Smith <brad@comstyle.com>

Comments

Kamil Rytarowski Feb. 16, 2018, 5:12 p.m. UTC | #1
On 16.02.2018 17:46, Brad Smith wrote:
> Add myself as an OpenBSD maintainer and add OpenBSD as maintained.
> 
> Signed-off-by: Brad Smith <brad@comstyle.com>
> 

Reviewed-by: Kamil Rytarowski <n54@gmx.com>

Would you like to co-maintain with myself a merge-branch for BSD? Right
now I send patches through other developers and it does not always work
smoothly.

> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 57358a08e2..86329e274f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -386,6 +386,12 @@ M: Kamil Rytarowski <kamil@netbsd.org>
>  S: Maintained
>  K: ^Subject:.*(?i)NetBSD
>  
> +OPENBSD
> +L: qemu-devel@nongnu.org
> +M: Brad Smith <brad@comstyle.com>
> +S: Maintained
> +K: ^Subject:.*(?i)OpenBSD
> +
>  W32, W64
>  L: qemu-devel@nongnu.org
>  M: Stefan Weil <sw@weilnetz.de>
> diff --git a/configure b/configure
> index 913e14839d..850c46ebac 100755
> --- a/configure
> +++ b/configure
> @@ -760,6 +760,7 @@ OpenBSD)
>    audio_drv_list="sdl"
>    audio_possible_drivers="sdl"
>    HOST_VARIANT_DIR="openbsd"
> +  supported_os="yes"
>  ;;
>  Darwin)
>    bsd="yes"
>
Philippe Mathieu-Daudé Feb. 16, 2018, 5:30 p.m. UTC | #2
Hi Brad,

On 02/16/2018 01:46 PM, Brad Smith wrote:
> Add myself as an OpenBSD maintainer and add OpenBSD as maintained.
> 
> Signed-off-by: Brad Smith <brad@comstyle.com>
> 
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 57358a08e2..86329e274f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -386,6 +386,12 @@ M: Kamil Rytarowski <kamil@netbsd.org>
>  S: Maintained
>  K: ^Subject:.*(?i)NetBSD
>  
> +OPENBSD
> +L: qemu-devel@nongnu.org
> +M: Brad Smith <brad@comstyle.com>
> +S: Maintained
> +K: ^Subject:.*(?i)OpenBSD
> +

No problem here,

>  W32, W64
>  L: qemu-devel@nongnu.org
>  M: Stefan Weil <sw@weilnetz.de>
> diff --git a/configure b/configure
> index 913e14839d..850c46ebac 100755
> --- a/configure
> +++ b/configure
> @@ -760,6 +760,7 @@ OpenBSD)
>    audio_drv_list="sdl"
>    audio_possible_drivers="sdl"
>    HOST_VARIANT_DIR="openbsd"
> +  supported_os="yes"

But before announcing the host OS being supported again, I'd rather see
reproducible build/tests logs, in a (public - if possible) continuous
integration system. Else it is hard to notice when it get broken.

>  ;;
>  Darwin)
>    bsd="yes"
> 

Regards,

Phil.
Peter Maydell Feb. 16, 2018, 5:37 p.m. UTC | #3
On 16 February 2018 at 17:30, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> But before announcing the host OS being supported again, I'd rather see
> reproducible build/tests logs, in a (public - if possible) continuous
> integration system. Else it is hard to notice when it get broken.

I do include OpenBSD in my set of build/tests for merges.

thanks
-- PMM
Kamil Rytarowski Feb. 16, 2018, 5:41 p.m. UTC | #4
On 16.02.2018 18:30, Philippe Mathieu-Daudé wrote:
> But before announcing the host OS being supported again, I'd rather see
> reproducible build/tests logs, in a (public - if possible) continuous
> integration system. Else it is hard to notice when it get broken.
> 

This is already done for FreeBSD, NetBSD and OpenBSD.

CC: Fam who can confirm this.
Philippe Mathieu-Daudé Feb. 16, 2018, 5:44 p.m. UTC | #5
On 02/16/2018 02:41 PM, Kamil Rytarowski wrote:
> On 16.02.2018 18:30, Philippe Mathieu-Daudé wrote:
>> But before announcing the host OS being supported again, I'd rather see
>> reproducible build/tests logs, in a (public - if possible) continuous
>> integration system. Else it is hard to notice when it get broken.
>>
> 
> This is already done for FreeBSD, NetBSD and OpenBSD.

We have the ability to run those, but afaik no CI are using them.

$ make vm-test
vm-test: Test QEMU in preconfigured virtual machines

  vm-build-ubuntu.i386            - Build QEMU in ubuntu i386 VM
  vm-build-freebsd                - Build QEMU in FreeBSD VM
  vm-build-netbsd                 - Build QEMU in NetBSD VM
  vm-build-openbsd                - Build QEMU in OpenBSD VM

> 
> CC: Fam who can confirm this.
Daniel P. Berrangé Feb. 16, 2018, 5:44 p.m. UTC | #6
On Fri, Feb 16, 2018 at 05:37:32PM +0000, Peter Maydell wrote:
> On 16 February 2018 at 17:30, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> > But before announcing the host OS being supported again, I'd rather see
> > reproducible build/tests logs, in a (public - if possible) continuous
> > integration system. Else it is hard to notice when it get broken.
> 
> I do include OpenBSD in my set of build/tests for merges.

There's also "make vm-build-openbsd"  for devs who want to test easily in
an OpenBSD VM, or investigate brokeness.

Regards,
Daniel
Fam Zheng Feb. 23, 2018, 8:33 a.m. UTC | #7
On Fri, 02/16 14:44, Philippe Mathieu-Daudé wrote:
> On 02/16/2018 02:41 PM, Kamil Rytarowski wrote:
> > On 16.02.2018 18:30, Philippe Mathieu-Daudé wrote:
> >> But before announcing the host OS being supported again, I'd rather see
> >> reproducible build/tests logs, in a (public - if possible) continuous
> >> integration system. Else it is hard to notice when it get broken.
> >>
> > 
> > This is already done for FreeBSD, NetBSD and OpenBSD.
> 
> We have the ability to run those, but afaik no CI are using them.

That's right. I can try enabling them on patchew, but my gut feeling is that
these still need to be optimized (especially, enabling persisted ccache like our
docker tests, so it is reasonably efficient for our limited resources).

Fam
Peter Maydell Feb. 23, 2018, 2:41 p.m. UTC | #8
On 16 February 2018 at 16:46, Brad Smith <brad@comstyle.com> wrote:
> Add myself as an OpenBSD maintainer and add OpenBSD as maintained.
>
> Signed-off-by: Brad Smith <brad@comstyle.com>
>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 57358a08e2..86329e274f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -386,6 +386,12 @@ M: Kamil Rytarowski <kamil@netbsd.org>
>  S: Maintained
>  K: ^Subject:.*(?i)NetBSD
>
> +OPENBSD
> +L: qemu-devel@nongnu.org
> +M: Brad Smith <brad@comstyle.com>
> +S: Maintained
> +K: ^Subject:.*(?i)OpenBSD
> +
>  W32, W64
>  L: qemu-devel@nongnu.org
>  M: Stefan Weil <sw@weilnetz.de>
> diff --git a/configure b/configure
> index 913e14839d..850c46ebac 100755
> --- a/configure
> +++ b/configure
> @@ -760,6 +760,7 @@ OpenBSD)
>    audio_drv_list="sdl"
>    audio_possible_drivers="sdl"
>    HOST_VARIANT_DIR="openbsd"
> +  supported_os="yes"
>  ;;
>  Darwin)
>    bsd="yes"

Thanks for agreeing to help us with the BSD host maintenance.
I've applied this patch to master. If you and Kamil want to
maintain a subtree for doing pull requests for BSD host
patches that's fine with me; otherwise we can continue to
ad-hoc apply patches through whatever route is simplest.

thanks
-- PMM
Eric Blake March 19, 2018, 10:06 p.m. UTC | #9
On 02/16/2018 11:44 AM, Philippe Mathieu-Daudé wrote:
> On 02/16/2018 02:41 PM, Kamil Rytarowski wrote:
>> On 16.02.2018 18:30, Philippe Mathieu-Daudé wrote:
>>> But before announcing the host OS being supported again, I'd rather see
>>> reproducible build/tests logs, in a (public - if possible) continuous
>>> integration system. Else it is hard to notice when it get broken.
>>>
>>
>> This is already done for FreeBSD, NetBSD and OpenBSD.
> 
> We have the ability to run those, but afaik no CI are using them.
> 
> $ make vm-test
> vm-test: Test QEMU in preconfigured virtual machines
> 
>    vm-build-ubuntu.i386            - Build QEMU in ubuntu i386 VM
>    vm-build-freebsd                - Build QEMU in FreeBSD VM
>    vm-build-netbsd                 - Build QEMU in NetBSD VM
>    vm-build-openbsd                - Build QEMU in OpenBSD VM
> 
>>
>> CC: Fam who can confirm this.

Thanks for this; today was my first day trying the various vm-build- 
targets.

Question: is this expected behavior?

$ make vm-build-ubuntu.i386
     VM-IMAGE ubuntu.i386
...
Image resized.
debconf: unable to initialize frontend: Dialog
debconf: (TERM is not set, so the dialog frontend is not usable.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Readline
debconf: (This frontend requires a controlling tty.)
debconf: falling back to frontend: Teletype
dpkg-preconfigure: unable to re-open stdin:
Connection to 127.0.0.1 closed by remote host.
...
Cloning into 
'/home/eblake/qemu/vm-test-VoVkBv.tmp/data-5ba3c.tar.vroot/ui/keycodemapdb'...
sudo: unable to resolve host ubuntu-guest
make[1]: flex: Command not found
...
make[1]: flex: Command not found
Could not access KVM kernel module: No such file or directory
qemu-system-i386: failed to initialize KVM: No such file or directory
qemu-system-i386: Back to tcg accelerator

I'm wondering if the image initialized incorrectly, and as a result 
can't do as much as it's supposed to do, or runs way slower than it 
needs to?  The command eventually completed with status 0, but failed to 
find a 32-bit compile error in the rdma code, and the output log does 
not look like it actually attempted to compile anything in qemu (unless 
it did compile it, but the logs were not output to stdout/stderr).

make vm-build-freebsd was a lot faster at completing for me (but shows 
that we still have a lot of clang warnings about address of a packed 
struct member).
Fam Zheng March 21, 2018, 8:11 a.m. UTC | #10
On Mon, 03/19 17:06, Eric Blake wrote:
> On 02/16/2018 11:44 AM, Philippe Mathieu-Daudé wrote:
> > On 02/16/2018 02:41 PM, Kamil Rytarowski wrote:
> > > On 16.02.2018 18:30, Philippe Mathieu-Daudé wrote:
> > > > But before announcing the host OS being supported again, I'd rather see
> > > > reproducible build/tests logs, in a (public - if possible) continuous
> > > > integration system. Else it is hard to notice when it get broken.
> > > > 
> > > 
> > > This is already done for FreeBSD, NetBSD and OpenBSD.
> > 
> > We have the ability to run those, but afaik no CI are using them.
> > 
> > $ make vm-test
> > vm-test: Test QEMU in preconfigured virtual machines
> > 
> >    vm-build-ubuntu.i386            - Build QEMU in ubuntu i386 VM
> >    vm-build-freebsd                - Build QEMU in FreeBSD VM
> >    vm-build-netbsd                 - Build QEMU in NetBSD VM
> >    vm-build-openbsd                - Build QEMU in OpenBSD VM
> > 
> > > 
> > > CC: Fam who can confirm this.
> 
> Thanks for this; today was my first day trying the various vm-build-
> targets.
> 
> Question: is this expected behavior?
> 
> $ make vm-build-ubuntu.i386
>     VM-IMAGE ubuntu.i386
> ...
> Image resized.
> debconf: unable to initialize frontend: Dialog
> debconf: (TERM is not set, so the dialog frontend is not usable.)
> debconf: falling back to frontend: Readline
> debconf: unable to initialize frontend: Readline
> debconf: (This frontend requires a controlling tty.)
> debconf: falling back to frontend: Teletype
> dpkg-preconfigure: unable to re-open stdin:
> Connection to 127.0.0.1 closed by remote host.
> ...
> Cloning into '/home/eblake/qemu/vm-test-VoVkBv.tmp/data-5ba3c.tar.vroot/ui/keycodemapdb'...
> sudo: unable to resolve host ubuntu-guest
> make[1]: flex: Command not found
> ...
> make[1]: flex: Command not found
> Could not access KVM kernel module: No such file or directory
> qemu-system-i386: failed to initialize KVM: No such file or directory
> qemu-system-i386: Back to tcg accelerator
> 
> I'm wondering if the image initialized incorrectly, and as a result can't do
> as much as it's supposed to do, or runs way slower than it needs to?  The
> command eventually completed with status 0, but failed to find a 32-bit
> compile error in the rdma code, and the output log does not look like it
> actually attempted to compile anything in qemu (unless it did compile it,
> but the logs were not output to stdout/stderr).
> 
> make vm-build-freebsd was a lot faster at completing for me (but shows that
> we still have a lot of clang warnings about address of a packed struct
> member).
> 

Was it a clean repo? Did you try "rm -rf ~/.cache/qemu-vm"? This morning the
command worked for me from a clean env (on RHEL 7, using a QEMU built from
qemu.git), and I didn't see the errors/warnings you pasted. (BTW I don't
understand how sudo has anything to do with the dummy host name.)

Fam
Eric Blake March 21, 2018, 1:14 p.m. UTC | #11
On 03/21/2018 03:11 AM, Fam Zheng wrote:
>> Thanks for this; today was my first day trying the various vm-build-
>> targets.
>>
>> Question: is this expected behavior?
>>
>> $ make vm-build-ubuntu.i386
>>      VM-IMAGE ubuntu.i386
>> ...
>> Image resized.
>> debconf: unable to initialize frontend: Dialog
>> debconf: (TERM is not set, so the dialog frontend is not usable.)

>>
>> I'm wondering if the image initialized incorrectly, and as a result can't do
>> as much as it's supposed to do, or runs way slower than it needs to?  The
>> command eventually completed with status 0, but failed to find a 32-bit
>> compile error in the rdma code, and the output log does not look like it
>> actually attempted to compile anything in qemu (unless it did compile it,
>> but the logs were not output to stdout/stderr).
>>
>> make vm-build-freebsd was a lot faster at completing for me (but shows that
>> we still have a lot of clang warnings about address of a packed struct
>> member).
>>
> 
> Was it a clean repo? Did you try "rm -rf ~/.cache/qemu-vm"? This morning the
> command worked for me from a clean env (on RHEL 7, using a QEMU built from
> qemu.git), and I didn't see the errors/warnings you pasted. (BTW I don't
> understand how sudo has anything to do with the dummy host name.)

I repeated the test twice this morning after 'rm -rf ~/.cache/qemu-vm', 
first after 'rm tests/vm/ubuntu.i386.img' in an incremental tree, and 
second in a fresh git checkout.  Here's a full pastebin of the first try 
(I hit ^C after seeing it look the same as yesterday, even after the 
fresh redownload that took more than 10 minutes):
https://paste.fedoraproject.org/paste/p8Th7AroLAprGY03ffzGHA

The results are the same; debconf is somehow unable to connect to the 
guest, and as a result, the guest is not properly initialized with the 
additional packages it needs, and then everything else about the image 
is broken.

Then on the second try, I got a dreaded message about my /home being 
nearly full, (having multiple .img files in two different build 
directories pushed me over limits), and it died a much harder death due 
to ENOSPC.  Let me resize my /home and retry (thankfully I still have 
some disk space free to throw at the problem), and I'll report back if 
that makes a difference.
Fam Zheng March 21, 2018, 2:07 p.m. UTC | #12
On Wed, 03/21 08:14, Eric Blake wrote:
> On 03/21/2018 03:11 AM, Fam Zheng wrote:
> > > Thanks for this; today was my first day trying the various vm-build-
> > > targets.
> > > 
> > > Question: is this expected behavior?
> > > 
> > > $ make vm-build-ubuntu.i386
> > >      VM-IMAGE ubuntu.i386
> > > ...
> > > Image resized.
> > > debconf: unable to initialize frontend: Dialog
> > > debconf: (TERM is not set, so the dialog frontend is not usable.)
> 
> > > 
> > > I'm wondering if the image initialized incorrectly, and as a result can't do
> > > as much as it's supposed to do, or runs way slower than it needs to?  The
> > > command eventually completed with status 0, but failed to find a 32-bit
> > > compile error in the rdma code, and the output log does not look like it
> > > actually attempted to compile anything in qemu (unless it did compile it,
> > > but the logs were not output to stdout/stderr).
> > > 
> > > make vm-build-freebsd was a lot faster at completing for me (but shows that
> > > we still have a lot of clang warnings about address of a packed struct
> > > member).
> > > 
> > 
> > Was it a clean repo? Did you try "rm -rf ~/.cache/qemu-vm"? This morning the
> > command worked for me from a clean env (on RHEL 7, using a QEMU built from
> > qemu.git), and I didn't see the errors/warnings you pasted. (BTW I don't
> > understand how sudo has anything to do with the dummy host name.)
> 
> I repeated the test twice this morning after 'rm -rf ~/.cache/qemu-vm',
> first after 'rm tests/vm/ubuntu.i386.img' in an incremental tree, and second
> in a fresh git checkout.  Here's a full pastebin of the first try (I hit ^C
> after seeing it look the same as yesterday, even after the fresh redownload
> that took more than 10 minutes):
> https://paste.fedoraproject.org/paste/p8Th7AroLAprGY03ffzGHA
> 
> The results are the same; debconf is somehow unable to connect to the guest,
> and as a result, the guest is not properly initialized with the additional
> packages it needs, and then everything else about the image is broken.
> 
> Then on the second try, I got a dreaded message about my /home being nearly
> full, (having multiple .img files in two different build directories pushed
> me over limits), and it died a much harder death due to ENOSPC.  Let me
> resize my /home and retry (thankfully I still have some disk space free to
> throw at the problem), and I'll report back if that makes a difference.

Now I see the problem. I always use V=1 so stdout is different for the spawned
commands (qemu and ssh) in the script. I will send a patch tomorrow. Thanks!

Fam
diff mbox series

Patch

diff --git a/MAINTAINERS b/MAINTAINERS
index 57358a08e2..86329e274f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -386,6 +386,12 @@  M: Kamil Rytarowski <kamil@netbsd.org>
 S: Maintained
 K: ^Subject:.*(?i)NetBSD
 
+OPENBSD
+L: qemu-devel@nongnu.org
+M: Brad Smith <brad@comstyle.com>
+S: Maintained
+K: ^Subject:.*(?i)OpenBSD
+
 W32, W64
 L: qemu-devel@nongnu.org
 M: Stefan Weil <sw@weilnetz.de>
diff --git a/configure b/configure
index 913e14839d..850c46ebac 100755
--- a/configure
+++ b/configure
@@ -760,6 +760,7 @@  OpenBSD)
   audio_drv_list="sdl"
   audio_possible_drivers="sdl"
   HOST_VARIANT_DIR="openbsd"
+  supported_os="yes"
 ;;
 Darwin)
   bsd="yes"