QEMU-Devel Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH] configure: Check bzip2 is available
@ 2019-11-08 10:28 Philippe Mathieu-Daudé
  2019-11-08 10:31 ` Daniel P. Berrangé
                   ` (2 more replies)
  0 siblings, 3 replies; 16+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-11-08 10:28 UTC (permalink / raw)
  To: Laszlo Ersek, qemu-devel
  Cc: qemu-trivial, Philippe Mathieu-Daudé,
	Thomas Huth, Daniel P . Berrange, Wainer dos Santos Moschetta

The bzip2 tool is not included in default installations.
On freshly installed systems, ./configure succeeds but 'make'
might fail later:

    BUNZIP2 pc-bios/edk2-i386-secure-code.fd.bz2
  /bin/sh: bzip2: command not found
  make: *** [Makefile:305: pc-bios/edk2-i386-secure-code.fd] Error 127
  make: *** Deleting file 'pc-bios/edk2-i386-secure-code.fd'
  make: *** Waiting for unfinished jobs....

Add a check in ./configure to warn the user if bzip2 is missing.

Fixes: 536d2173b2b
Reported-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
---
 configure | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/configure b/configure
index efe165edf9..9957e913e8 100755
--- a/configure
+++ b/configure
@@ -1851,6 +1851,13 @@ python_version=$($python -c 'import sys; print("%d.%d.%d" % (sys.version_info[0]
 # Suppress writing compiled files
 python="$python -B"
 
+# Some firmware binaries are compressed with bzip2
+if has bzip2; then
+  :
+else
+  error_exit "bzip2 program not found. Please install it"
+fi
+
 # Check that the C compiler works. Doing this here before testing
 # the host CPU ensures that we had a valid CC to autodetect the
 # $cpu var (and we should bail right here if that's not the case).
-- 
2.21.0



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH] configure: Check bzip2 is available
  2019-11-08 10:28 [PATCH] configure: Check bzip2 is available Philippe Mathieu-Daudé
@ 2019-11-08 10:31 ` Daniel P. Berrangé
  2019-11-08 10:34 ` Thomas Huth
  2019-11-08 11:01 ` Laszlo Ersek
  2 siblings, 0 replies; 16+ messages in thread
From: Daniel P. Berrangé @ 2019-11-08 10:31 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé
  Cc: qemu-trivial, Thomas Huth, Laszlo Ersek, qemu-devel,
	Wainer dos Santos Moschetta

On Fri, Nov 08, 2019 at 11:28:05AM +0100, Philippe Mathieu-Daudé wrote:
> The bzip2 tool is not included in default installations.
> On freshly installed systems, ./configure succeeds but 'make'
> might fail later:
> 
>     BUNZIP2 pc-bios/edk2-i386-secure-code.fd.bz2
>   /bin/sh: bzip2: command not found
>   make: *** [Makefile:305: pc-bios/edk2-i386-secure-code.fd] Error 127
>   make: *** Deleting file 'pc-bios/edk2-i386-secure-code.fd'
>   make: *** Waiting for unfinished jobs....
> 
> Add a check in ./configure to warn the user if bzip2 is missing.
> 
> Fixes: 536d2173b2b
> Reported-by: Thomas Huth <thuth@redhat.com>
> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> ---
>  configure | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/configure b/configure
> index efe165edf9..9957e913e8 100755
> --- a/configure
> +++ b/configure
> @@ -1851,6 +1851,13 @@ python_version=$($python -c 'import sys; print("%d.%d.%d" % (sys.version_info[0]
>  # Suppress writing compiled files
>  python="$python -B"
>  
> +# Some firmware binaries are compressed with bzip2
> +if has bzip2; then
> +  :
> +else
> +  error_exit "bzip2 program not found. Please install it"
> +fi

Nitpick, I'd phrase this as

   "The bzip2 program is required for building QEMU"

Either way though

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>


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 :|



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH] configure: Check bzip2 is available
  2019-11-08 10:28 [PATCH] configure: Check bzip2 is available Philippe Mathieu-Daudé
  2019-11-08 10:31 ` Daniel P. Berrangé
@ 2019-11-08 10:34 ` Thomas Huth
  2019-11-08 10:42   ` Philippe Mathieu-Daudé
  2019-11-08 11:01 ` Laszlo Ersek
  2 siblings, 1 reply; 16+ messages in thread
From: Thomas Huth @ 2019-11-08 10:34 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé, Laszlo Ersek, qemu-devel
  Cc: qemu-trivial, Daniel P . Berrange, Wainer dos Santos Moschetta

On 08/11/2019 11.28, Philippe Mathieu-Daudé wrote:
> The bzip2 tool is not included in default installations.
> On freshly installed systems, ./configure succeeds but 'make'
> might fail later:
> 
>      BUNZIP2 pc-bios/edk2-i386-secure-code.fd.bz2
>    /bin/sh: bzip2: command not found
>    make: *** [Makefile:305: pc-bios/edk2-i386-secure-code.fd] Error 127
>    make: *** Deleting file 'pc-bios/edk2-i386-secure-code.fd'
>    make: *** Waiting for unfinished jobs....
> 
> Add a check in ./configure to warn the user if bzip2 is missing.
> 
> Fixes: 536d2173b2b
> Reported-by: Thomas Huth <thuth@redhat.com>
> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> ---
>   configure | 7 +++++++
>   1 file changed, 7 insertions(+)
> 
> diff --git a/configure b/configure
> index efe165edf9..9957e913e8 100755
> --- a/configure
> +++ b/configure
> @@ -1851,6 +1851,13 @@ python_version=$($python -c 'import sys; print("%d.%d.%d" % (sys.version_info[0]
>   # Suppress writing compiled files
>   python="$python -B"
>   
> +# Some firmware binaries are compressed with bzip2
> +if has bzip2; then
> +  :
> +else
> +  error_exit "bzip2 program not found. Please install it"
> +fi

It's only required for the edk2 binaries, isn't it? So should this maybe 
also check whether we build any of the i386-softmmu, x86_64-softmmu 
arm-softmmu or aarch64-softmmu targets and pass otherwise?

  Thomas



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH] configure: Check bzip2 is available
  2019-11-08 10:34 ` Thomas Huth
@ 2019-11-08 10:42   ` Philippe Mathieu-Daudé
  2019-11-08 11:39     ` Laszlo Ersek
  0 siblings, 1 reply; 16+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-11-08 10:42 UTC (permalink / raw)
  To: Thomas Huth, Laszlo Ersek, qemu-devel
  Cc: qemu-trivial, Daniel P . Berrange, Wainer dos Santos Moschetta

On 11/8/19 11:34 AM, Thomas Huth wrote:
> On 08/11/2019 11.28, Philippe Mathieu-Daudé wrote:
>> The bzip2 tool is not included in default installations.
>> On freshly installed systems, ./configure succeeds but 'make'
>> might fail later:
>>
>>      BUNZIP2 pc-bios/edk2-i386-secure-code.fd.bz2
>>    /bin/sh: bzip2: command not found
>>    make: *** [Makefile:305: pc-bios/edk2-i386-secure-code.fd] Error 127
>>    make: *** Deleting file 'pc-bios/edk2-i386-secure-code.fd'
>>    make: *** Waiting for unfinished jobs....
>>
>> Add a check in ./configure to warn the user if bzip2 is missing.
>>
>> Fixes: 536d2173b2b
>> Reported-by: Thomas Huth <thuth@redhat.com>
>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>> ---
>>   configure | 7 +++++++
>>   1 file changed, 7 insertions(+)
>>
>> diff --git a/configure b/configure
>> index efe165edf9..9957e913e8 100755
>> --- a/configure
>> +++ b/configure
>> @@ -1851,6 +1851,13 @@ python_version=$($python -c 'import sys; 
>> print("%d.%d.%d" % (sys.version_info[0]
>>   # Suppress writing compiled files
>>   python="$python -B"
>> +# Some firmware binaries are compressed with bzip2
>> +if has bzip2; then
>> +  :
>> +else
>> +  error_exit "bzip2 program not found. Please install it"
>> +fi
> 
> It's only required for the edk2 binaries, isn't it? So should this maybe 
> also check whether we build any of the i386-softmmu, x86_64-softmmu 
> arm-softmmu or aarch64-softmmu targets and pass otherwise?

I have this on my TODO somewhere, because we extract the edk2 firmwares 
even if we only build MIPS/PowerPC.


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH] configure: Check bzip2 is available
  2019-11-08 10:28 [PATCH] configure: Check bzip2 is available Philippe Mathieu-Daudé
  2019-11-08 10:31 ` Daniel P. Berrangé
  2019-11-08 10:34 ` Thomas Huth
@ 2019-11-08 11:01 ` Laszlo Ersek
  2019-11-08 11:05   ` Daniel P. Berrangé
                     ` (2 more replies)
  2 siblings, 3 replies; 16+ messages in thread
From: Laszlo Ersek @ 2019-11-08 11:01 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé, qemu-devel
  Cc: qemu-trivial, Thomas Huth, Daniel P . Berrange,
	Wainer dos Santos Moschetta

On 11/08/19 11:28, Philippe Mathieu-Daudé wrote:
> The bzip2 tool is not included in default installations.
> On freshly installed systems, ./configure succeeds but 'make'
> might fail later:
> 
>     BUNZIP2 pc-bios/edk2-i386-secure-code.fd.bz2
>   /bin/sh: bzip2: command not found
>   make: *** [Makefile:305: pc-bios/edk2-i386-secure-code.fd] Error 127
>   make: *** Deleting file 'pc-bios/edk2-i386-secure-code.fd'
>   make: *** Waiting for unfinished jobs....
> 
> Add a check in ./configure to warn the user if bzip2 is missing.

We've come full circle. Let me explain:

> 
> Fixes: 536d2173b2b

So this makes me kinda grumpy. If you look at the v3 posting of the patch that would later become commit 536d2173b2b:

  http://mid.mail-archive.com/20190321113408.19929-8-lersek@redhat.com

you see the following note in the changelog:

    - compress FD files with bzip2 rather than xz, so that decompression at
      "make install" time succeed on older build OSes too [Peter]

So I couldn't use xz because that was "too new" for some build OSes, but now we also can't take bzip2 for granted because that's "too old" for some other build OSes? This is ridiculous.

To be clear, my disagreement is only with the "Fixes" tag. For me, "Fixes" stands for something that, in retrospect, can be proven to have been a bug at the time the code was *originally* committed. But, at the time, taking "bzip2" for granted was *not* a bug. The conditions / circumstances have changed more recently, and the assumption about bzip2 has been invalidated *after* adding a dependency on bzip2.

Nonetheless, thank you for adapting the code to the potential absence of bzip2. Can you perhaps go in some details in the commit message, near "not included in default installations" and "freshly installed systems"? If we can, we should identify the exact distro release where this problem has been encountered (and I wouldn't mind a link to the BZ or ticket under which people agreed to remove bzip2 from the default package set).

Reviewed-by: Laszlo Ersek <lersek@redhat.com>

Thanks
Laszlo

> Reported-by: Thomas Huth <thuth@redhat.com>
> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> ---
>  configure | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/configure b/configure
> index efe165edf9..9957e913e8 100755
> --- a/configure
> +++ b/configure
> @@ -1851,6 +1851,13 @@ python_version=$($python -c 'import sys; print("%d.%d.%d" % (sys.version_info[0]
>  # Suppress writing compiled files
>  python="$python -B"
>  
> +# Some firmware binaries are compressed with bzip2
> +if has bzip2; then
> +  :
> +else
> +  error_exit "bzip2 program not found. Please install it"
> +fi
> +
>  # Check that the C compiler works. Doing this here before testing
>  # the host CPU ensures that we had a valid CC to autodetect the
>  # $cpu var (and we should bail right here if that's not the case).
> 



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH] configure: Check bzip2 is available
  2019-11-08 11:01 ` Laszlo Ersek
@ 2019-11-08 11:05   ` Daniel P. Berrangé
  2019-11-08 11:54   ` Philippe Mathieu-Daudé
  2019-11-08 15:43   ` Eric Blake
  2 siblings, 0 replies; 16+ messages in thread
From: Daniel P. Berrangé @ 2019-11-08 11:05 UTC (permalink / raw)
  To: Laszlo Ersek
  Cc: qemu-trivial, Thomas Huth, Philippe Mathieu-Daudé,
	qemu-devel, Wainer dos Santos Moschetta

On Fri, Nov 08, 2019 at 12:01:16PM +0100, Laszlo Ersek wrote:
> On 11/08/19 11:28, Philippe Mathieu-Daudé wrote:
> > The bzip2 tool is not included in default installations.
> > On freshly installed systems, ./configure succeeds but 'make'
> > might fail later:
> > 
> >     BUNZIP2 pc-bios/edk2-i386-secure-code.fd.bz2
> >   /bin/sh: bzip2: command not found
> >   make: *** [Makefile:305: pc-bios/edk2-i386-secure-code.fd] Error 127
> >   make: *** Deleting file 'pc-bios/edk2-i386-secure-code.fd'
> >   make: *** Waiting for unfinished jobs....
> > 
> > Add a check in ./configure to warn the user if bzip2 is missing.
> 
> We've come full circle. Let me explain:
> 
> > 
> > Fixes: 536d2173b2b
> 
> So this makes me kinda grumpy. If you look at the v3 posting of the patch that would later become commit 536d2173b2b:
> 
>   http://mid.mail-archive.com/20190321113408.19929-8-lersek@redhat.com
> 
> you see the following note in the changelog:
> 
>     - compress FD files with bzip2 rather than xz, so that decompression at
>       "make install" time succeed on older build OSes too [Peter]
> 
> So I couldn't use xz because that was "too new" for some build OSes, but now we also can't take bzip2 for granted because that's "too old" for some other build OSes? This is ridiculous.

We're not saying bzip2 is too old / missing from the OS. Every OS we care
about has bzip2. The problem is that a minimal installation migt not have
installed it. This kind of problem is increasingly common with use of
minimal container images for example. So we're just ensuring we validate
that what we want is actuall present.

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 :|



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH] configure: Check bzip2 is available
  2019-11-08 10:42   ` Philippe Mathieu-Daudé
@ 2019-11-08 11:39     ` Laszlo Ersek
  2019-11-08 11:58       ` Philippe Mathieu-Daudé
  2019-11-08 12:03       ` Thomas Huth
  0 siblings, 2 replies; 16+ messages in thread
From: Laszlo Ersek @ 2019-11-08 11:39 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé, Thomas Huth, qemu-devel
  Cc: qemu-trivial, Daniel P . Berrange, Wainer dos Santos Moschetta

On 11/08/19 11:42, Philippe Mathieu-Daudé wrote:
> On 11/8/19 11:34 AM, Thomas Huth wrote:
>> On 08/11/2019 11.28, Philippe Mathieu-Daudé wrote:
>>> The bzip2 tool is not included in default installations.
>>> On freshly installed systems, ./configure succeeds but 'make'
>>> might fail later:
>>>
>>>      BUNZIP2 pc-bios/edk2-i386-secure-code.fd.bz2
>>>    /bin/sh: bzip2: command not found
>>>    make: *** [Makefile:305: pc-bios/edk2-i386-secure-code.fd] Error 127
>>>    make: *** Deleting file 'pc-bios/edk2-i386-secure-code.fd'
>>>    make: *** Waiting for unfinished jobs....
>>>
>>> Add a check in ./configure to warn the user if bzip2 is missing.
>>>
>>> Fixes: 536d2173b2b
>>> Reported-by: Thomas Huth <thuth@redhat.com>
>>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>>> ---
>>>   configure | 7 +++++++
>>>   1 file changed, 7 insertions(+)
>>>
>>> diff --git a/configure b/configure
>>> index efe165edf9..9957e913e8 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -1851,6 +1851,13 @@ python_version=$($python -c 'import sys;
>>> print("%d.%d.%d" % (sys.version_info[0]
>>>   # Suppress writing compiled files
>>>   python="$python -B"
>>> +# Some firmware binaries are compressed with bzip2
>>> +if has bzip2; then
>>> +  :
>>> +else
>>> +  error_exit "bzip2 program not found. Please install it"
>>> +fi
>>
>> It's only required for the edk2 binaries, isn't it? So should this
>> maybe also check whether we build any of the i386-softmmu,
>> x86_64-softmmu arm-softmmu or aarch64-softmmu targets and pass otherwise?
> 
> I have this on my TODO somewhere, because we extract the edk2 firmwares
> even if we only build MIPS/PowerPC.

But that applies to all of "BLOBS" in the root-level Makefile, doesn't
it? We also install, say, "vgabios-qxl.bin", when only the MIPS/PowerPC
system emulators are built. The only aspect that's specific to edk2
binaries is that they are kept compressed until installation time, to
save space in the git repo and in the source tarball.

I'm reminded of the "external QEMU blob / firmware repo" idea.

Thanks
Laszlo



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH] configure: Check bzip2 is available
  2019-11-08 11:01 ` Laszlo Ersek
  2019-11-08 11:05   ` Daniel P. Berrangé
@ 2019-11-08 11:54   ` Philippe Mathieu-Daudé
  2019-11-08 11:57     ` Thomas Huth
  2019-11-08 15:43   ` Eric Blake
  2 siblings, 1 reply; 16+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-11-08 11:54 UTC (permalink / raw)
  To: Laszlo Ersek, qemu-devel
  Cc: qemu-trivial, Thomas Huth, Daniel P . Berrange,
	Wainer dos Santos Moschetta

On 11/8/19 12:01 PM, Laszlo Ersek wrote:
> On 11/08/19 11:28, Philippe Mathieu-Daudé wrote:
>> The bzip2 tool is not included in default installations.
>> On freshly installed systems, ./configure succeeds but 'make'
>> might fail later:
>>
>>      BUNZIP2 pc-bios/edk2-i386-secure-code.fd.bz2
>>    /bin/sh: bzip2: command not found
>>    make: *** [Makefile:305: pc-bios/edk2-i386-secure-code.fd] Error 127
>>    make: *** Deleting file 'pc-bios/edk2-i386-secure-code.fd'
>>    make: *** Waiting for unfinished jobs....
>>
>> Add a check in ./configure to warn the user if bzip2 is missing.
> 
> We've come full circle. Let me explain:
> 
>>
>> Fixes: 536d2173b2b
> 
> So this makes me kinda grumpy. If you look at the v3 posting of the patch that would later become commit 536d2173b2b:
> 
>    http://mid.mail-archive.com/20190321113408.19929-8-lersek@redhat.com
> 
> you see the following note in the changelog:
> 
>      - compress FD files with bzip2 rather than xz, so that decompression at
>        "make install" time succeed on older build OSes too [Peter]
> 
> So I couldn't use xz because that was "too new" for some build OSes, but now we also can't take bzip2 for granted because that's "too old" for some other build OSes? This is ridiculous.
> 
> To be clear, my disagreement is only with the "Fixes" tag. For me, "Fixes" stands for something that, in retrospect, can be proven to have been a bug at the time the code was *originally* committed. But, at the time, taking "bzip2" for granted was *not* a bug. The conditions / circumstances have changed more recently, and the assumption about bzip2 has been invalidated *after* adding a dependency on bzip2.
> 
> Nonetheless, thank you for adapting the code to the potential absence of bzip2. Can you perhaps go in some details in the commit message, near "not included in default installations" and "freshly installed systems"? If we can, we should identify the exact distro release where this problem has been encountered (and I wouldn't mind a link to the BZ or ticket under which people agreed to remove bzip2 from the default package set).

I am just reading this and already sent a v2.

I can amend these details. Thomas, what distro release were you using?

> 
> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
> 
> Thanks
> Laszlo
> 
>> Reported-by: Thomas Huth <thuth@redhat.com>
>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>> ---
>>   configure | 7 +++++++
>>   1 file changed, 7 insertions(+)
>>
>> diff --git a/configure b/configure
>> index efe165edf9..9957e913e8 100755
>> --- a/configure
>> +++ b/configure
>> @@ -1851,6 +1851,13 @@ python_version=$($python -c 'import sys; print("%d.%d.%d" % (sys.version_info[0]
>>   # Suppress writing compiled files
>>   python="$python -B"
>>   
>> +# Some firmware binaries are compressed with bzip2
>> +if has bzip2; then
>> +  :
>> +else
>> +  error_exit "bzip2 program not found. Please install it"
>> +fi
>> +
>>   # Check that the C compiler works. Doing this here before testing
>>   # the host CPU ensures that we had a valid CC to autodetect the
>>   # $cpu var (and we should bail right here if that's not the case).
>>
> 


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH] configure: Check bzip2 is available
  2019-11-08 11:54   ` Philippe Mathieu-Daudé
@ 2019-11-08 11:57     ` Thomas Huth
  0 siblings, 0 replies; 16+ messages in thread
From: Thomas Huth @ 2019-11-08 11:57 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé, Laszlo Ersek, qemu-devel
  Cc: qemu-trivial, Daniel P . Berrange, Wainer dos Santos Moschetta

On 08/11/2019 12.54, Philippe Mathieu-Daudé wrote:
> On 11/8/19 12:01 PM, Laszlo Ersek wrote:
>> On 11/08/19 11:28, Philippe Mathieu-Daudé wrote:
>>> The bzip2 tool is not included in default installations.
>>> On freshly installed systems, ./configure succeeds but 'make'
>>> might fail later:
>>>
>>>      BUNZIP2 pc-bios/edk2-i386-secure-code.fd.bz2
>>>    /bin/sh: bzip2: command not found
>>>    make: *** [Makefile:305: pc-bios/edk2-i386-secure-code.fd] Error 127
>>>    make: *** Deleting file 'pc-bios/edk2-i386-secure-code.fd'
>>>    make: *** Waiting for unfinished jobs....
>>>
>>> Add a check in ./configure to warn the user if bzip2 is missing.
>>
>> We've come full circle. Let me explain:
>>
>>>
>>> Fixes: 536d2173b2b
>>
>> So this makes me kinda grumpy. If you look at the v3 posting of the 
>> patch that would later become commit 536d2173b2b:
>>
>>    http://mid.mail-archive.com/20190321113408.19929-8-lersek@redhat.com
>>
>> you see the following note in the changelog:
>>
>>      - compress FD files with bzip2 rather than xz, so that 
>> decompression at
>>        "make install" time succeed on older build OSes too [Peter]
>>
>> So I couldn't use xz because that was "too new" for some build OSes, 
>> but now we also can't take bzip2 for granted because that's "too old" 
>> for some other build OSes? This is ridiculous.
>>
>> To be clear, my disagreement is only with the "Fixes" tag. For me, 
>> "Fixes" stands for something that, in retrospect, can be proven to 
>> have been a bug at the time the code was *originally* committed. But, 
>> at the time, taking "bzip2" for granted was *not* a bug. The 
>> conditions / circumstances have changed more recently, and the 
>> assumption about bzip2 has been invalidated *after* adding a 
>> dependency on bzip2.
>>
>> Nonetheless, thank you for adapting the code to the potential absence 
>> of bzip2. Can you perhaps go in some details in the commit message, 
>> near "not included in default installations" and "freshly installed 
>> systems"? If we can, we should identify the exact distro release where 
>> this problem has been encountered (and I wouldn't mind a link to the 
>> BZ or ticket under which people agreed to remove bzip2 from the 
>> default package set).
> 
> I am just reading this and already sent a v2.
> 
> I can amend these details. Thomas, what distro release were you using?

I encountered this problem with a freshly installed Fedora 31.

  Thomas



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH] configure: Check bzip2 is available
  2019-11-08 11:39     ` Laszlo Ersek
@ 2019-11-08 11:58       ` Philippe Mathieu-Daudé
  2019-11-08 12:03       ` Thomas Huth
  1 sibling, 0 replies; 16+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-11-08 11:58 UTC (permalink / raw)
  To: Laszlo Ersek, Thomas Huth, qemu-devel
  Cc: qemu-trivial, Daniel P . Berrange, Wainer dos Santos Moschetta

On 11/8/19 12:39 PM, Laszlo Ersek wrote:
> On 11/08/19 11:42, Philippe Mathieu-Daudé wrote:
>> On 11/8/19 11:34 AM, Thomas Huth wrote:
>>> On 08/11/2019 11.28, Philippe Mathieu-Daudé wrote:
>>>> The bzip2 tool is not included in default installations.
>>>> On freshly installed systems, ./configure succeeds but 'make'
>>>> might fail later:
>>>>
>>>>       BUNZIP2 pc-bios/edk2-i386-secure-code.fd.bz2
>>>>     /bin/sh: bzip2: command not found
>>>>     make: *** [Makefile:305: pc-bios/edk2-i386-secure-code.fd] Error 127
>>>>     make: *** Deleting file 'pc-bios/edk2-i386-secure-code.fd'
>>>>     make: *** Waiting for unfinished jobs....
>>>>
>>>> Add a check in ./configure to warn the user if bzip2 is missing.
>>>>
>>>> Fixes: 536d2173b2b
>>>> Reported-by: Thomas Huth <thuth@redhat.com>
>>>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>>>> ---
>>>>    configure | 7 +++++++
>>>>    1 file changed, 7 insertions(+)
>>>>
>>>> diff --git a/configure b/configure
>>>> index efe165edf9..9957e913e8 100755
>>>> --- a/configure
>>>> +++ b/configure
>>>> @@ -1851,6 +1851,13 @@ python_version=$($python -c 'import sys;
>>>> print("%d.%d.%d" % (sys.version_info[0]
>>>>    # Suppress writing compiled files
>>>>    python="$python -B"
>>>> +# Some firmware binaries are compressed with bzip2
>>>> +if has bzip2; then
>>>> +  :
>>>> +else
>>>> +  error_exit "bzip2 program not found. Please install it"
>>>> +fi
>>>
>>> It's only required for the edk2 binaries, isn't it? So should this
>>> maybe also check whether we build any of the i386-softmmu,
>>> x86_64-softmmu arm-softmmu or aarch64-softmmu targets and pass otherwise?
>>
>> I have this on my TODO somewhere, because we extract the edk2 firmwares
>> even if we only build MIPS/PowerPC.
> 
> But that applies to all of "BLOBS" in the root-level Makefile, doesn't
> it? We also install, say, "vgabios-qxl.bin", when only the MIPS/PowerPC
> system emulators are built. The only aspect that's specific to edk2
> binaries is that they are kept compressed until installation time, to
> save space in the git repo and in the source tarball.

You are right, other targets could improve this too.
Since this add quite complexity to the buildsys and nobody complained 
about that previously, I suggest we clean that *after* we switch the 
build machinery to Meson.

> I'm reminded of the "external QEMU blob / firmware repo" idea.

Do you mind starting a new thread asking about it? It would be nice we 
clear this during the next dev cycle.

Regards,

Phil.


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH] configure: Check bzip2 is available
  2019-11-08 11:39     ` Laszlo Ersek
  2019-11-08 11:58       ` Philippe Mathieu-Daudé
@ 2019-11-08 12:03       ` Thomas Huth
  1 sibling, 0 replies; 16+ messages in thread
From: Thomas Huth @ 2019-11-08 12:03 UTC (permalink / raw)
  To: Laszlo Ersek, Philippe Mathieu-Daudé, qemu-devel
  Cc: qemu-trivial, Daniel P . Berrange, Wainer dos Santos Moschetta

On 08/11/2019 12.39, Laszlo Ersek wrote:
> On 11/08/19 11:42, Philippe Mathieu-Daudé wrote:
>> On 11/8/19 11:34 AM, Thomas Huth wrote:
>>> On 08/11/2019 11.28, Philippe Mathieu-Daudé wrote:
>>>> The bzip2 tool is not included in default installations.
>>>> On freshly installed systems, ./configure succeeds but 'make'
>>>> might fail later:
>>>>
>>>>       BUNZIP2 pc-bios/edk2-i386-secure-code.fd.bz2
>>>>     /bin/sh: bzip2: command not found
>>>>     make: *** [Makefile:305: pc-bios/edk2-i386-secure-code.fd] Error 127
>>>>     make: *** Deleting file 'pc-bios/edk2-i386-secure-code.fd'
>>>>     make: *** Waiting for unfinished jobs....
>>>>
>>>> Add a check in ./configure to warn the user if bzip2 is missing.
>>>>
>>>> Fixes: 536d2173b2b
>>>> Reported-by: Thomas Huth <thuth@redhat.com>
>>>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>>>> ---
>>>>    configure | 7 +++++++
>>>>    1 file changed, 7 insertions(+)
>>>>
>>>> diff --git a/configure b/configure
>>>> index efe165edf9..9957e913e8 100755
>>>> --- a/configure
>>>> +++ b/configure
>>>> @@ -1851,6 +1851,13 @@ python_version=$($python -c 'import sys;
>>>> print("%d.%d.%d" % (sys.version_info[0]
>>>>    # Suppress writing compiled files
>>>>    python="$python -B"
>>>> +# Some firmware binaries are compressed with bzip2
>>>> +if has bzip2; then
>>>> +  :
>>>> +else
>>>> +  error_exit "bzip2 program not found. Please install it"
>>>> +fi
>>>
>>> It's only required for the edk2 binaries, isn't it? So should this
>>> maybe also check whether we build any of the i386-softmmu,
>>> x86_64-softmmu arm-softmmu or aarch64-softmmu targets and pass otherwise?
>>
>> I have this on my TODO somewhere, because we extract the edk2 firmwares
>> even if we only build MIPS/PowerPC.
> 
> But that applies to all of "BLOBS" in the root-level Makefile, doesn't
> it? We also install, say, "vgabios-qxl.bin", when only the MIPS/PowerPC
> system emulators are built.

IIRC there was another odd dependency that the PCI devices need their 
ROM also on non-x86 systems... but that's another story...

> The only aspect that's specific to edk2
> binaries is that they are kept compressed until installation time, to
> save space in the git repo and in the source tarball.

I noticed that there are also some iotests that use bzip2 ... they are 
not used during the build process, but still, it might be better to 
simply always require bzip2, also in case some other architectures want 
to use it. So I'm also fine if we simply always require bzip2 for the build.

  Thomas

PS: Anybody interested in writing a patch to compress the other big 
binaries in the pc-bios folder, too? ... skiboot.lid ... 
openbios-sparc64 ... ppc_rom.bin ...



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH] configure: Check bzip2 is available
  2019-11-08 11:01 ` Laszlo Ersek
  2019-11-08 11:05   ` Daniel P. Berrangé
  2019-11-08 11:54   ` Philippe Mathieu-Daudé
@ 2019-11-08 15:43   ` Eric Blake
  2019-11-08 17:07     ` Philippe Mathieu-Daudé
  2 siblings, 1 reply; 16+ messages in thread
From: Eric Blake @ 2019-11-08 15:43 UTC (permalink / raw)
  To: Laszlo Ersek, Philippe Mathieu-Daudé, qemu-devel
  Cc: qemu-trivial, Thomas Huth, Daniel P . Berrange,
	Wainer dos Santos Moschetta

On 11/8/19 5:01 AM, Laszlo Ersek wrote:

>>
>> Add a check in ./configure to warn the user if bzip2 is missing.
> 
> We've come full circle. Let me explain:
> 
>>
>> Fixes: 536d2173b2b
> 
> So this makes me kinda grumpy. If you look at the v3 posting of the patch that would later become commit 536d2173b2b:
> 
>    http://mid.mail-archive.com/20190321113408.19929-8-lersek@redhat.com
> 
> you see the following note in the changelog:
> 
>      - compress FD files with bzip2 rather than xz, so that decompression at
>        "make install" time succeed on older build OSes too [Peter]
> 
> So I couldn't use xz because that was "too new" for some build OSes, but now we also can't take bzip2 for granted because that's "too old" for some other build OSes? This is ridiculous.
> 
> To be clear, my disagreement is only with the "Fixes" tag. For me, "Fixes" stands for something that, in retrospect, can be proven to have been a bug at the time the code was *originally* committed. But, at the time, taking "bzip2" for granted was *not* a bug. The conditions / circumstances have changed more recently, and the assumption about bzip2 has been invalidated *after* adding a dependency on bzip2.
> 
> Nonetheless, thank you for adapting the code to the potential absence of bzip2. Can you perhaps go in some details in the commit message, near "not included in default installations" and "freshly installed systems"? If we can, we should identify the exact distro release where this problem has been encountered (and I wouldn't mind a link to the BZ or ticket under which people agreed to remove bzip2 from the default package set).

bzip2 is no longer a favored compression.  If we are trying to pick a 
compression that is most likely to be present on any system, go with 
gzip.  If we are trying to pick a compression that packs tighter and 
uncompresses faster, pick xz or zstd.  But bzip2 does neither: it packs 
slightly tighter than gzip but has slower performance in doing so, and 
thus is no longer used as a default compression.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH] configure: Check bzip2 is available
  2019-11-08 15:43   ` Eric Blake
@ 2019-11-08 17:07     ` Philippe Mathieu-Daudé
  2019-11-08 17:10       ` Peter Maydell
  0 siblings, 1 reply; 16+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-11-08 17:07 UTC (permalink / raw)
  To: Eric Blake, Laszlo Ersek, qemu-devel
  Cc: Peter Maydell, Thomas Huth, Daniel P . Berrange, qemu-trivial,
	Wainer dos Santos Moschetta, Gerd Hoffmann

On 11/8/19 4:43 PM, Eric Blake wrote:
> On 11/8/19 5:01 AM, Laszlo Ersek wrote:
> 
>>>
>>> Add a check in ./configure to warn the user if bzip2 is missing.
>>
>> We've come full circle. Let me explain:
>>
>>>
>>> Fixes: 536d2173b2b
>>
>> So this makes me kinda grumpy. If you look at the v3 posting of the 
>> patch that would later become commit 536d2173b2b:
>>
>>    http://mid.mail-archive.com/20190321113408.19929-8-lersek@redhat.com
>>
>> you see the following note in the changelog:
>>
>>      - compress FD files with bzip2 rather than xz, so that 
>> decompression at
>>        "make install" time succeed on older build OSes too [Peter]
>>
>> So I couldn't use xz because that was "too new" for some build OSes, 
>> but now we also can't take bzip2 for granted because that's "too old" 
>> for some other build OSes? This is ridiculous.
>>
>> To be clear, my disagreement is only with the "Fixes" tag. For me, 
>> "Fixes" stands for something that, in retrospect, can be proven to 
>> have been a bug at the time the code was *originally* committed. But, 
>> at the time, taking "bzip2" for granted was *not* a bug. The 
>> conditions / circumstances have changed more recently, and the 
>> assumption about bzip2 has been invalidated *after* adding a 
>> dependency on bzip2.
>>
>> Nonetheless, thank you for adapting the code to the potential absence 
>> of bzip2. Can you perhaps go in some details in the commit message, 
>> near "not included in default installations" and "freshly installed 
>> systems"? If we can, we should identify the exact distro release where 
>> this problem has been encountered (and I wouldn't mind a link to the 
>> BZ or ticket under which people agreed to remove bzip2 from the 
>> default package set).
> 
> bzip2 is no longer a favored compression.  If we are trying to pick a 
> compression that is most likely to be present on any system, go with 
> gzip.  If we are trying to pick a compression that packs tighter and 
> uncompresses faster, pick xz or zstd.  But bzip2 does neither: it packs 
> slightly tighter than gzip but has slower performance in doing so, and 
> thus is no longer used as a default compression.

The problem was with OpenBSD 6.1 which hadn't xz available.

In commit 12745eaa02 Gerd updated the VM to OpenBSD 6.5 and we now have 
access to xz. IIRC OSX supported versions also provide xz.

If we want to revert Laszlo's patches and apply his first version (using 
xz), we should do that during 5.0 dev cycle, now it is too late.
I'd prefer we simply fix bzip2 for the next release.


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH] configure: Check bzip2 is available
  2019-11-08 17:07     ` Philippe Mathieu-Daudé
@ 2019-11-08 17:10       ` Peter Maydell
  2019-11-11 11:51         ` Thomas Huth
  0 siblings, 1 reply; 16+ messages in thread
From: Peter Maydell @ 2019-11-08 17:10 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé
  Cc: Thomas Huth, Daniel P . Berrange, QEMU Trivial, QEMU Developers,
	Wainer dos Santos Moschetta, Gerd Hoffmann, Laszlo Ersek

On Fri, 8 Nov 2019 at 17:07, Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
> On 11/8/19 4:43 PM, Eric Blake wrote:
> > bzip2 is no longer a favored compression.  If we are trying to pick a
> > compression that is most likely to be present on any system, go with
> > gzip.  If we are trying to pick a compression that packs tighter and
> > uncompresses faster, pick xz or zstd.  But bzip2 does neither: it packs
> > slightly tighter than gzip but has slower performance in doing so, and
> > thus is no longer used as a default compression.
>
> The problem was with OpenBSD 6.1 which hadn't xz available.
>
> In commit 12745eaa02 Gerd updated the VM to OpenBSD 6.5 and we now have
> access to xz. IIRC OSX supported versions also provide xz.
>
> If we want to revert Laszlo's patches and apply his first version (using
> xz), we should do that during 5.0 dev cycle, now it is too late.
> I'd prefer we simply fix bzip2 for the next release.

I don't think we should try to use 'xz' because I don't see
the point. We should use something that's generally available,
whether that's bzip2 or gzip. Life's too short to deal with
yet another file compression tool and format.

thanks
-- PMM


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH] configure: Check bzip2 is available
  2019-11-08 17:10       ` Peter Maydell
@ 2019-11-11 11:51         ` Thomas Huth
  2019-11-11 13:33           ` Aleksandar Markovic
  0 siblings, 1 reply; 16+ messages in thread
From: Thomas Huth @ 2019-11-11 11:51 UTC (permalink / raw)
  To: Peter Maydell, Philippe Mathieu-Daudé
  Cc: Daniel P . Berrange, QEMU Trivial, QEMU Developers,
	Wainer dos Santos Moschetta, Gerd Hoffmann, Laszlo Ersek

On 08/11/2019 18.10, Peter Maydell wrote:
> On Fri, 8 Nov 2019 at 17:07, Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
>> On 11/8/19 4:43 PM, Eric Blake wrote:
>>> bzip2 is no longer a favored compression.  If we are trying to pick a
>>> compression that is most likely to be present on any system, go with
>>> gzip.  If we are trying to pick a compression that packs tighter and
>>> uncompresses faster, pick xz or zstd.  But bzip2 does neither: it packs
>>> slightly tighter than gzip but has slower performance in doing so, and
>>> thus is no longer used as a default compression.
>>
>> The problem was with OpenBSD 6.1 which hadn't xz available.
>>
>> In commit 12745eaa02 Gerd updated the VM to OpenBSD 6.5 and we now have
>> access to xz. IIRC OSX supported versions also provide xz.
>>
>> If we want to revert Laszlo's patches and apply his first version (using
>> xz), we should do that during 5.0 dev cycle, now it is too late.
>> I'd prefer we simply fix bzip2 for the next release.
> 
> I don't think we should try to use 'xz' because I don't see
> the point. We should use something that's generally available,
> whether that's bzip2 or gzip. Life's too short to deal with
> yet another file compression tool and format.

FWIW, on the weekend, I accidentially came accross this page:

 https://www.nongnu.org/lzip/xz_inadequate.html

After reading that, I also don't think anymore that we should switch to
'xz'.

 Thomas



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH] configure: Check bzip2 is available
  2019-11-11 11:51         ` Thomas Huth
@ 2019-11-11 13:33           ` Aleksandar Markovic
  0 siblings, 0 replies; 16+ messages in thread
From: Aleksandar Markovic @ 2019-11-11 13:33 UTC (permalink / raw)
  To: Thomas Huth
  Cc: Peter Maydell, Daniel P . Berrange, QEMU Trivial, Laszlo Ersek,
	QEMU Developers, Wainer dos Santos Moschetta, Gerd Hoffmann,
	Philippe Mathieu-Daudé

[-- Attachment #1: Type: text/plain, Size: 2213 bytes --]

On Monday, November 11, 2019, Thomas Huth <thuth@redhat.com> wrote:

> On 08/11/2019 18.10, Peter Maydell wrote:
> > On Fri, 8 Nov 2019 at 17:07, Philippe Mathieu-Daudé <philmd@redhat.com>
> wrote:
> >> On 11/8/19 4:43 PM, Eric Blake wrote:
> >>> bzip2 is no longer a favored compression.  If we are trying to pick a
> >>> compression that is most likely to be present on any system, go with
> >>> gzip.  If we are trying to pick a compression that packs tighter and
> >>> uncompresses faster, pick xz or zstd.  But bzip2 does neither: it packs
> >>> slightly tighter than gzip but has slower performance in doing so, and
> >>> thus is no longer used as a default compression.
> >>
> >> The problem was with OpenBSD 6.1 which hadn't xz available.
> >>
> >> In commit 12745eaa02 Gerd updated the VM to OpenBSD 6.5 and we now have
> >> access to xz. IIRC OSX supported versions also provide xz.
> >>
> >> If we want to revert Laszlo's patches and apply his first version (using
> >> xz), we should do that during 5.0 dev cycle, now it is too late.
> >> I'd prefer we simply fix bzip2 for the next release.
> >
> > I don't think we should try to use 'xz' because I don't see
> > the point. We should use something that's generally available,
> > whether that's bzip2 or gzip. Life's too short to deal with
> > yet another file compression tool and format.
>
> FWIW, on the weekend, I accidentially came accross this page:
>
>  https://www.nongnu.org/lzip/xz_inadequate.html
>
> After reading that, I also don't think anymore that we should switch to
> 'xz'.



Off topic, but, from the page you linked to:

There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.
-- C.A.R. Hoare

Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away.
-- Antoine de Saint-Exupery

Perhaps we should display these quotes at some highly visible place on our
dev QEMU website. ;)

Aleksandar



>
>  Thomas
>
>
>

[-- Attachment #2: Type: text/html, Size: 3184 bytes --]

<br><br>On Monday, November 11, 2019, Thomas Huth &lt;<a href="mailto:thuth@redhat.com">thuth@redhat.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 08/11/2019 18.10, Peter Maydell wrote:<br>
&gt; On Fri, 8 Nov 2019 at 17:07, Philippe Mathieu-Daudé &lt;<a href="mailto:philmd@redhat.com">philmd@redhat.com</a>&gt; wrote:<br>
&gt;&gt; On 11/8/19 4:43 PM, Eric Blake wrote:<br>
&gt;&gt;&gt; bzip2 is no longer a favored compression.  If we are trying to pick a<br>
&gt;&gt;&gt; compression that is most likely to be present on any system, go with<br>
&gt;&gt;&gt; gzip.  If we are trying to pick a compression that packs tighter and<br>
&gt;&gt;&gt; uncompresses faster, pick xz or zstd.  But bzip2 does neither: it packs<br>
&gt;&gt;&gt; slightly tighter than gzip but has slower performance in doing so, and<br>
&gt;&gt;&gt; thus is no longer used as a default compression.<br>
&gt;&gt;<br>
&gt;&gt; The problem was with OpenBSD 6.1 which hadn&#39;t xz available.<br>
&gt;&gt;<br>
&gt;&gt; In commit 12745eaa02 Gerd updated the VM to OpenBSD 6.5 and we now have<br>
&gt;&gt; access to xz. IIRC OSX supported versions also provide xz.<br>
&gt;&gt;<br>
&gt;&gt; If we want to revert Laszlo&#39;s patches and apply his first version (using<br>
&gt;&gt; xz), we should do that during 5.0 dev cycle, now it is too late.<br>
&gt;&gt; I&#39;d prefer we simply fix bzip2 for the next release.<br>
&gt; <br>
&gt; I don&#39;t think we should try to use &#39;xz&#39; because I don&#39;t see<br>
&gt; the point. We should use something that&#39;s generally available,<br>
&gt; whether that&#39;s bzip2 or gzip. Life&#39;s too short to deal with<br>
&gt; yet another file compression tool and format.<br>
<br>
FWIW, on the weekend, I accidentially came accross this page:<br>
<br>
 <a href="https://www.nongnu.org/lzip/xz_inadequate.html" target="_blank">https://www.nongnu.org/lzip/<wbr>xz_inadequate.html</a><br>
<br>
After reading that, I also don&#39;t think anymore that we should switch to<br>
&#39;xz&#39;.</blockquote><div><br></div><div><br></div><div>Off topic, but, from the page you linked to:</div><div><br></div><div><blockquote style="font-family:&#39;Times New Roman&#39;;font-size:medium"><p>There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.<br>-- C.A.R. Hoare</p></blockquote><blockquote style="font-family:&#39;Times New Roman&#39;;font-size:medium"><p>Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away.<br>-- Antoine de Saint-Exupery</p><div><br></div></blockquote></div><div>Perhaps we should display these quotes at some highly visible place on our dev QEMU website. ;)</div><div><br></div><div>Aleksandar</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
 Thomas<br>
<br>
<br>
</blockquote>

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, back to index

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-08 10:28 [PATCH] configure: Check bzip2 is available Philippe Mathieu-Daudé
2019-11-08 10:31 ` Daniel P. Berrangé
2019-11-08 10:34 ` Thomas Huth
2019-11-08 10:42   ` Philippe Mathieu-Daudé
2019-11-08 11:39     ` Laszlo Ersek
2019-11-08 11:58       ` Philippe Mathieu-Daudé
2019-11-08 12:03       ` Thomas Huth
2019-11-08 11:01 ` Laszlo Ersek
2019-11-08 11:05   ` Daniel P. Berrangé
2019-11-08 11:54   ` Philippe Mathieu-Daudé
2019-11-08 11:57     ` Thomas Huth
2019-11-08 15:43   ` Eric Blake
2019-11-08 17:07     ` Philippe Mathieu-Daudé
2019-11-08 17:10       ` Peter Maydell
2019-11-11 11:51         ` Thomas Huth
2019-11-11 13:33           ` Aleksandar Markovic

QEMU-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/qemu-devel/0 qemu-devel/git/0.git
	git clone --mirror https://lore.kernel.org/qemu-devel/1 qemu-devel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 qemu-devel qemu-devel/ https://lore.kernel.org/qemu-devel \
		qemu-devel@nongnu.org
	public-inbox-index qemu-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.nongnu.qemu-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git