[Qemu-devel] [QUESTION] SDL 1.2 support

[Qemu-devel] [QUESTION] SDL 1.2 support

[Aleksandar Markovic]

Hello, Gerd, Daniel, and others involved.

I have multiple reports from end users that say that transition from
SDL 1.2 to SDL 2.0 was difficult, or even impossible for their hosts.
In that light, they don't appreciate removing SDL 1.2 support from
QEMU. The most notable example is Ubutnu 16.04, where it looks there
is no way of installing SDL 2.0 that does not involve complete OS
upgrade, which, for various reasons, many are not willing to do.

It looks to me that depreciation of SDL 1.2 was a little premature. My
humble opinion is that we should not look at release dates of
libraries when we deprecate them, but release dates and end-of-support
dates of major Linux distribution that include them.

My question for you is: How difficult would be to reactivate SDL 1.2
support in QEMU, and postpone its depreciation for a couple of years?

I do not demand anything, this is just a question, meant to start a
conversation.

Yours,
Aleksandar

Re: [Qemu-devel] [QUESTION] SDL 1.2 support

[Peter Maydell]

On Tue, 16 Jul 2019 at 12:17, Aleksandar Markovic
<aleksandar.m.mail@gmail.com> wrote:
>
> Hello, Gerd, Daniel, and others involved.
>
> I have multiple reports from end users that say that transition from
> SDL 1.2 to SDL 2.0 was difficult, or even impossible for their hosts.
> In that light, they don't appreciate removing SDL 1.2 support from
> QEMU. The most notable example is Ubutnu 16.04, where it looks there
> is no way of installing SDL 2.0 that does not involve complete OS
> upgrade, which, for various reasons, many are not willing to do.

One of my build test machines is an Ubuntu 16.04 system
(specifically 16.04.6 LTS), and it has SDL2 installed
and the built test includes compiling the SDL2 UI. So I'm
not sure what's happening with your end users -- do you have
more detail on what their setup is and what isn't working for them ?

> It looks to me that depreciation of SDL 1.2 was a little premature. My
> humble opinion is that we should not look at release dates of
> libraries when we deprecate them, but release dates and end-of-support
> dates of major Linux distribution that include them.

That is indeed the way our deprecation policy is supposed to
work -- we care about the versions of libraries that distros
have shipped in their LTS, not what the upstream library
release schedule is.

thanks
-- PMM

Re: [Qemu-devel] [QUESTION] SDL 1.2 support

[Aleksandar Markovic]

On Tue, Jul 16, 2019 at 1:41 PM Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Tue, 16 Jul 2019 at 12:17, Aleksandar Markovic
> <aleksandar.m.mail@gmail.com> wrote:
> >
> > Hello, Gerd, Daniel, and others involved.
> >
> > I have multiple reports from end users that say that transition from
> > SDL 1.2 to SDL 2.0 was difficult, or even impossible for their hosts.
> > In that light, they don't appreciate removing SDL 1.2 support from
> > QEMU. The most notable example is Ubutnu 16.04, where it looks there
> > is no way of installing SDL 2.0 that does not involve complete OS
> > upgrade, which, for various reasons, many are not willing to do.
>
> One of my build test machines is an Ubuntu 16.04 system
> (specifically 16.04.6 LTS), and it has SDL2 installed
> and the built test includes compiling the SDL2 UI. So I'm
> not sure what's happening with your end users -- do you have
> more detail on what their setup is and what isn't working for them ?
>

I gather that their systems are one of earlier versions of Ubuntu 16.04
that has SDL 1.2, and not SDL 2.

Let me explain the situation in more details. The build and test beds in
many organization are often maintained in a state that is not subject to
change over time. This means no updates/upgrades, except some
really rare exceptions. The rationale is that build and test beds should
be "constant" in time to achieve reproducible build runs and test
executions. In some organizations such setup is frequently achieved
by using virtual machines that automatically revert to their initial state
on each reboot.

But I digress. Let me quote our Linux deprecation policy for reference
for future readers here:

"For distributions with frequent, short-lifetime releases, the project will
aim to support all versions that are not end of life by their respective
vendors. For the purposes of identifying supported software versions,
the project will look at Fedora, Ubuntu, and openSUSE distros. Other
short-lifetime distros will be assumed to ship similar software versions.

For distributions with long-lifetime releases, the project will aim to
support the most recent major version at all times. Support for the
previous major version will be dropped 2 years after the new major
version is released. For the purposes of identifying supported software
versions, the project will look at RHEL, Debian, Ubuntu LTS, and
SLES distros. Other long-lifetime distros will be assumed to ship
similar software versions."

However, any distribution is a "living creature". Packages are constantly
added and modified, and Ubuntu 16.04 looks different at its inception
and now, even though it bears the same version number, 16.04.

The problem here (not directly visible from the policy) is that it looks
as if we implicitly assume that any end user is constantly updating and
upgrading their systems - and that may not be true. I think we can't say
to such user: "Why didn't you update your Ubuntu 16.04?" It is up to the
user how he/she wants to use their OS, we can't and shouldn't dictate
that - at least this is my understanding of our desired relations to the
end users.

> > It looks to me that depreciation of SDL 1.2 was a little premature. My
> > humble opinion is that we should not look at release dates of
> > libraries when we deprecate them, but release dates and end-of-support
> > dates of major Linux distribution that include them.
>
> That is indeed the way our deprecation policy is supposed to
> work -- we care about the versions of libraries that distros
> have shipped in their LTS, not what the upstream library
> release schedule is.
>

I think there seems to be a hidden unclarity in our deprecation policy,
related to the situation I described above.

I appreciate your response very much!

Yours,
Aleksandar

> thanks
> -- PMM

Re: [Qemu-devel] [QUESTION] SDL 1.2 support

[Peter Maydell]

On Tue, 16 Jul 2019 at 18:48, Aleksandar Markovic
<aleksandar.m.mail@gmail.com> wrote:
> "For distributions with frequent, short-lifetime releases, the project will
> aim to support all versions that are not end of life by their respective
> vendors. For the purposes of identifying supported software versions,
> the project will look at Fedora, Ubuntu, and openSUSE distros. Other
> short-lifetime distros will be assumed to ship similar software versions.
>
> For distributions with long-lifetime releases, the project will aim to
> support the most recent major version at all times. Support for the
> previous major version will be dropped 2 years after the new major
> version is released. For the purposes of identifying supported software
> versions, the project will look at RHEL, Debian, Ubuntu LTS, and
> SLES distros. Other long-lifetime distros will be assumed to ship
> similar software versions."
>
> However, any distribution is a "living creature". Packages are constantly
> added and modified, and Ubuntu 16.04 looks different at its inception
> and now, even though it bears the same version number, 16.04.

Ubuntu do actually put a sub-version number in here; if you
do 'lsb_release -a' on a properly upgraded 16.04 LTS system
it will tell you it's 16.04.6.

> The problem here (not directly visible from the policy) is that it looks
> as if we implicitly assume that any end user is constantly updating and
> upgrading their systems - and that may not be true.

We do effectively assume that to some extent (ie I don't
think we need to support the very first 16.04 release), and
I think that's not unreasonable, because if you're not updating
then you have a huge pile of security vulnerabilities you haven't
patched against. The vastly common use case is to stay up to date
within an LTS type release.

> I think we can't say
> to such user: "Why didn't you update your Ubuntu 16.04?" It is up to the
> user how he/she wants to use their OS, we can't and shouldn't dictate
> that - at least this is my understanding of our desired relations to the
> end users.

We don't dictate to users how they should use or update their
OS. But we do have to define a policy which balances the
amount of effort we as upstream would have to do (limiting
the set of systems we support is less work for us), against
the benefit to users of having support for a wider range of
systems. The deprecation-policy is where we've set that balance.
It is inevitable that there will be some set of users that are
left unsupported by the point we've chosen. We hope that that
set of users is fairly small, because we include LTS distros
in our supported set and give a 2 year grace period for users
to move forward; and many users who for stability reasons want
to stick with an older distro will also be staying with the
older QEMU and not moving forward to the most recent one.
But, yes, there will be some who are stuck on the older LTS and
still want the newer QEMU. That's unfortunate for them, but
we can't support everybody on the planet on every version of
Linux ever shipped since the 1990s. Those users get to
make a choice between remaining with their stable environment
(the QEMU we shipped to them originally still works and won't
evaporate) or moving forward to both a newer QEMU and perhaps
a newer version of their host OS.

thanks
-- PMM

Re: [Qemu-devel] [QUESTION] SDL 1.2 support

[Daniel P. Berrangé]

On Tue, Jul 16, 2019 at 01:17:01PM +0200, Aleksandar Markovic wrote:
> Hello, Gerd, Daniel, and others involved.
> 
> I have multiple reports from end users that say that transition from
> SDL 1.2 to SDL 2.0 was difficult, or even impossible for their hosts.
> In that light, they don't appreciate removing SDL 1.2 support from
> QEMU. The most notable example is Ubutnu 16.04, where it looks there
> is no way of installing SDL 2.0 that does not involve complete OS
> upgrade, which, for various reasons, many are not willing to do.

Ubuntu has shipped SDL 2 for a long time now, for 16.04 and before.

> It looks to me that depreciation of SDL 1.2 was a little premature. My
> humble opinion is that we should not look at release dates of
> libraries when we deprecate them, but release dates and end-of-support
> dates of major Linux distribution that include them.

We do indeed based deprecations off our suppported build platform
targets as defined here:

  https://qemu.weilnetz.de/doc/qemu-doc.html#Supported-build-platforms

As above, Ubuntu has shipped SDL2 for a long time already, so removing
SDL 1.2 was considered to not be a problem.

> My question for you is: How difficult would be to reactivate SDL 1.2
> support in QEMU, and postpone its depreciation for a couple of years?

In the absence of more info, I'm not seeing a compelling reason to
undelete SDL 1.2, given all our supported build platforms ship SDL 2

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: [Qemu-devel] [QUESTION] SDL 1.2 support

[Thomas Huth]

On 16/07/2019 13.17, Aleksandar Markovic wrote:
> Hello, Gerd, Daniel, and others involved.
> 
> I have multiple reports from end users that say that transition from
> SDL 1.2 to SDL 2.0 was difficult, or even impossible for their hosts.
> In that light, they don't appreciate removing SDL 1.2 support from
> QEMU. The most notable example is Ubutnu 16.04, where it looks there
> is no way of installing SDL 2.0 that does not involve complete OS
> upgrade, which, for various reasons, many are not willing to do.

What's the problem here? According to
https://packages.ubuntu.com/xenial/libsdl2-2.0-0 the library should be
available there.

> It looks to me that depreciation of SDL 1.2 was a little premature. My
> humble opinion is that we should not look at release dates of
> libraries when we deprecate them, but release dates and end-of-support
> dates of major Linux distribution that include them.

We are already doing that. Our support policy can be found here:

https://qemu.weilnetz.de/doc/qemu-doc.html#Linux-OS

So Ubuntu 16.04 should still be supported until April in 2020.

 Thomas

Re: [Qemu-devel] [QUESTION] SDL 1.2 support

[Aleksandar Markovic]

On Tue, Jul 16, 2019 at 1:54 PM Thomas Huth <thuth@redhat.com> wrote:
>
> On 16/07/2019 13.17, Aleksandar Markovic wrote:
> > Hello, Gerd, Daniel, and others involved.
> >
> > I have multiple reports from end users that say that transition from
> > SDL 1.2 to SDL 2.0 was difficult, or even impossible for their hosts.
> > In that light, they don't appreciate removing SDL 1.2 support from
> > QEMU. The most notable example is Ubutnu 16.04, where it looks there
> > is no way of installing SDL 2.0 that does not involve complete OS
> > upgrade, which, for various reasons, many are not willing to do.
>
> What's the problem here? According to
> https://packages.ubuntu.com/xenial/libsdl2-2.0-0 the library should be
> available there.
>

Yes, we, as developers, are good at upgrading, we like flexibility in
our development systems, and naturally want to try latest and greatest
tools and libraries.

However, in QA / build / test environments, the things seem to look
different. Their main concern is stability and repeatibility of their
systems. They don't like updates and upgrades. If a new of library
is available for an OS, this does not mean it will be installed, or it
will be desired to be installed.

It appears that Ubuntu 16.04 came originally with SDL 1.2, and
SDL 2.0 was made available later on.

That is the problem: We make, in my opinion, an incorrect logical
leap here: we assume that if a package is available for an OS, it is
installed (or should be installed) on any instance of an OS.

Yours,
Aleksandar

Re: [Qemu-devel] [QUESTION] SDL 1.2 support

[Daniel P. Berrangé]

On Tue, Jul 16, 2019 at 07:09:37PM +0200, Aleksandar Markovic wrote:
> On Tue, Jul 16, 2019 at 1:54 PM Thomas Huth <thuth@redhat.com> wrote:
> >
> > On 16/07/2019 13.17, Aleksandar Markovic wrote:
> > > Hello, Gerd, Daniel, and others involved.
> > >
> > > I have multiple reports from end users that say that transition from
> > > SDL 1.2 to SDL 2.0 was difficult, or even impossible for their hosts.
> > > In that light, they don't appreciate removing SDL 1.2 support from
> > > QEMU. The most notable example is Ubutnu 16.04, where it looks there
> > > is no way of installing SDL 2.0 that does not involve complete OS
> > > upgrade, which, for various reasons, many are not willing to do.
> >
> > What's the problem here? According to
> > https://packages.ubuntu.com/xenial/libsdl2-2.0-0 the library should be
> > available there.
> >
> 
> Yes, we, as developers, are good at upgrading, we like flexibility in
> our development systems, and naturally want to try latest and greatest
> tools and libraries.

We were actually very conservative in requiring use of SDL 2. We shipped
QEMU with both SDL 1.2 & 2.0 support for many releases, and have only
dropped SDL 1.2 support *5* years after SDL 2.0 was shipped.

> However, in QA / build / test environments, the things seem to look
> different. Their main concern is stability and repeatibility of their
> systems. They don't like updates and upgrades. If a new of library
> is available for an OS, this does not mean it will be installed, or it
> will be desired to be installed.

No one ever wants to change what they do currently. That's totally
understandable & normal, but that comes with a cost to the project
to maintain compatibility indefinitely. That is not viable for a
project with limited maintainer resources.

There needs to be a balance between adding new technology, and
keeping compatibility with existing technology. QEMU has done
that for a very long time shipping SDL1.2 & SDL2 support in
parallel. More generally our platform support policy and our
feature deprecation policy try to set expectations for consumers
for what to expect in future releases.

> It appears that Ubuntu 16.04 came originally with SDL 1.2, and
> SDL 2.0 was made available later on.

That is not the case. Ubuntu has shipped both SDL 1.2 and 2.0
concurrently as options, even in the previous 14.04 LTS, and
probably before that too.

> That is the problem: We make, in my opinion, an incorrect logical
> leap here: we assume that if a package is available for an OS, it is
> installed (or should be installed) on any instance of an OS.

We're not assuming that it is installed, as everyone's OS install
packageset is going to be different. We're just assuming that it is
possible to be installed as an official vendor package, should the
user want that feature. This is not unreasonable IMHO.

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: [Qemu-devel] [QUESTION] SDL 1.2 support

[Aleksandar Markovic]

> > It appears that Ubuntu 16.04 came originally with SDL 1.2, and
> > SDL 2.0 was made available later on.
>
> That is not the case. Ubuntu has shipped both SDL 1.2 and 2.0
> concurrently as options, even in the previous 14.04 LTS, and
> probably before that too.
>

Thank you for finding this out.

However, this bring to surface another problematic point:

We assume that introduction of SDL 2.0 to Ubuntu is a green light
for deprecating SDL 1.2. In fact, SDL 1.2 is not deprecated by
Ubuntu (at least not by 16.04) - as established by you.

> > That is the problem: We make, in my opinion, an incorrect logical
> > leap here: we assume that if a package is available for an OS, it is
> > installed (or should be installed) on any instance of an OS.
>
> We're not assuming that it is installed, as everyone's OS install
> packageset is going to be different. We're just assuming that it is
> possible to be installed as an official vendor package, should the
> user want that feature. This is not unreasonable IMHO.
>

Again, what I find problematic is that we don't take deprecating
of older version of a library by a distribution as our reference point,
but our reference point is introducing of a new version.

Daniel, in any case, thanks a lot for your responses, I will not
respond to another email of yours in this thread, since I would be
just repeating myself - I also responded to Peter and Thomas,
so you can read those responses too for more details.

Many thanks again!
Aleksandar

> 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: [Qemu-devel] [QUESTION] SDL 1.2 support

[Daniel P. Berrangé]

On Tue, Jul 16, 2019 at 08:06:24PM +0200, Aleksandar Markovic wrote:
> > > It appears that Ubuntu 16.04 came originally with SDL 1.2, and
> > > SDL 2.0 was made available later on.
> >
> > That is not the case. Ubuntu has shipped both SDL 1.2 and 2.0
> > concurrently as options, even in the previous 14.04 LTS, and
> > probably before that too.
> >
> 
> Thank you for finding this out.
> 
> However, this bring to surface another problematic point:
> 
> We assume that introduction of SDL 2.0 to Ubuntu is a green light
> for deprecating SDL 1.2. In fact, SDL 1.2 is not deprecated by
> Ubuntu (at least not by 16.04) - as established by you.
>

> > > That is the problem: We make, in my opinion, an incorrect logical
> > > leap here: we assume that if a package is available for an OS, it is
> > > installed (or should be installed) on any instance of an OS.
> >
> > We're not assuming that it is installed, as everyone's OS install
> > packageset is going to be different. We're just assuming that it is
> > possible to be installed as an official vendor package, should the
> > user want that feature. This is not unreasonable IMHO.
> >
> 
> Again, what I find problematic is that we don't take deprecating
> of older version of a library by a distribution as our reference point,
> but our reference point is introducing of a new version.

Distros don't really do "deprecation" as a concept though.
They will continue to ship an old version of a library for
as long as they need to ship some application that consumes
it. IOW, the fact that SDL 1.2 exists still indicates that some
application the distro cares about is unable to build with
SDL 2 yet.

For this reason you'll even see distros still shipping GTK-1,
despite GTK-2 being released in 2002 and GTK-3 in 2011 and
GTK-4 appearing real soon.  IOW, it wouldn't surprise me if
SDL 1.2 exists in distros for another 10 years, despite the
upstream project considering it obsolete long ago. This
doesn't mean it is desirable / neccessary to continue to
support SDL 1.2 in downstream apps, when SDL 2 is widely
available.

> Daniel, in any case, thanks a lot for your responses, I will not
> respond to another email of yours in this thread, since I would be
> just repeating myself - I also responded to Peter and Thomas,
> so you can read those responses too for more details.

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: [Qemu-devel] [QUESTION] SDL 1.2 support

[Aleksandar Markovic]

On Tue, Jul 16, 2019 at 7:44 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Tue, Jul 16, 2019 at 07:09:37PM +0200, Aleksandar Markovic wrote:
> > On Tue, Jul 16, 2019 at 1:54 PM Thomas Huth <thuth@redhat.com> wrote:
> > >
> > > On 16/07/2019 13.17, Aleksandar Markovic wrote:
> > > > Hello, Gerd, Daniel, and others involved.
> > > >
> > > > I have multiple reports from end users that say that transition from
> > > > SDL 1.2 to SDL 2.0 was difficult, or even impossible for their hosts.
> > > > In that light, they don't appreciate removing SDL 1.2 support from
> > > > QEMU. The most notable example is Ubutnu 16.04, where it looks there
> > > > is no way of installing SDL 2.0 that does not involve complete OS
> > > > upgrade, which, for various reasons, many are not willing to do.
> > >
> > > What's the problem here? According to
> > > https://packages.ubuntu.com/xenial/libsdl2-2.0-0 the library should be
> > > available there.
> > >
> >
> > Yes, we, as developers, are good at upgrading, we like flexibility in
> > our development systems, and naturally want to try latest and greatest
> > tools and libraries.
>
> We were actually very conservative in requiring use of SDL 2. We shipped
> QEMU with both SDL 1.2 & 2.0 support for many releases, and have only
> dropped SDL 1.2 support *5* years after SDL 2.0 was shipped.
>

Daniel, that is fine, I don't question that, I basically wanted to start a talk
between us to clarify some things. Related to our situation in the field,
I have a sub-question to you:

Let's say there is a build system with SDL 1.2, and not SDL 2.0. Should
QEMU refuse to build?

Yours,
Aleksandar

Re: [Qemu-devel] [QUESTION] SDL 1.2 support

[Eric Blake]

[-- Attachment #1.1: Type: text/plain, Size: 2272 bytes --]

On 7/17/19 1:34 PM, Aleksandar Markovic wrote:

> 
> Daniel, that is fine, I don't question that, I basically wanted to start a talk
> between us to clarify some things. Related to our situation in the field,
> I have a sub-question to you:
> 
> Let's say there is a build system with SDL 1.2, and not SDL 2.0. Should
> QEMU refuse to build?

If the dependency is soft (when SDL 2.0 is available, we can compile
more things than when it is not), then the build shouldn't fail, but
your resulting binaries will not use SDL.  For example, we treat librbd
as a soft dependency: if it is available, you can build in Ceph support;
if it is not, you lose out on that particular block format, but can
still run guests locally.

If the dependency is hard (when SDL 2.0 is unavailable, we cannot
perform our job), then the build should fail.  For example, we treat
glib2 as a hard dependency: if it is unavailable, we can't implement our
main loop, and there's really nothing left worth compiling.

Some qemu dependencies are hard, some are soft. And your choice of
configure options may further influence things (our KConfig setup may
mean that some libraries are hard dependencies for one board type, but
soft dependencies for others).  Off-hand, I'd guess that SDL 2.0 should
be a soft dependency (but if it is a hard dependency, patches to make it
a soft dependency are welcome); if I'm right, then building when only
SDL 1.2 is available should not fail, but also will not use SDL.

But the presence or absence of SDL 1.2 on a build machine has no bearing
on the real question of whether SDL 2.0 is a hard or soft dependency,
now that the project has decided that SDL 2.0 is easy enough to obtain
across all of the set of systems included in our documented list of
minimum development setups.  In short, if you want to build with SDL,
you need to have SDL 2.0 available because we are not going to support
builds against SDL 1.2 as a reasonable development target any longer;
but having SDL 2.0 development libraries available does not preclude
also keeping SDL 1.2 on the same machine for other reasons.

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [Qemu-devel] [QUESTION] SDL 1.2 support

[Aleksandar Markovic]

On Wed, Jul 17, 2019 at 8:57 PM Eric Blake <eblake@redhat.com> wrote:
>
> On 7/17/19 1:34 PM, Aleksandar Markovic wrote:
>
> >
> > Daniel, that is fine, I don't question that, I basically wanted to start a talk
> > between us to clarify some things. Related to our situation in the field,
> > I have a sub-question to you:
> >
> > Let's say there is a build system with SDL 1.2, and not SDL 2.0. Should
> > QEMU refuse to build?
>
> If the dependency is soft (when SDL 2.0 is available, we can compile
> more things than when it is not), then the build shouldn't fail, but
> your resulting binaries will not use SDL.  For example, we treat librbd
> as a soft dependency: if it is available, you can build in Ceph support;
> if it is not, you lose out on that particular block format, but can
> still run guests locally.
>
> If the dependency is hard (when SDL 2.0 is unavailable, we cannot
> perform our job), then the build should fail.  For example, we treat
> glib2 as a hard dependency: if it is unavailable, we can't implement our
> main loop, and there's really nothing left worth compiling.
>

Eric, I truly appreciate your clarification.

But, does "configure" list somewhere unmet soft dependencies? (the
question is general, not looking at SDL only) Is there any other way for
an end user to have info on unmet dependencies (whether soft or hard),
other than see QEMU is not building, or something is not working in
QEMU run-time?

Daniel,

We had message "SDL 1.2 is going to be deprecated" in QEMU 3.0
"configure" and, if I remember well, in QEMU 3.1 as well. And now,
when we finally deprecated it, is it true that there is no message
whatsoever on systems with SDL 1.2 only?

Yours,
Aleksandar

> Some qemu dependencies are hard, some are soft. And your choice of
> configure options may further influence things (our KConfig setup may
> mean that some libraries are hard dependencies for one board type, but
> soft dependencies for others).  Off-hand, I'd guess that SDL 2.0 should
> be a soft dependency (but if it is a hard dependency, patches to make it
> a soft dependency are welcome); if I'm right, then building when only
> SDL 1.2 is available should not fail, but also will not use SDL.
>
> But the presence or absence of SDL 1.2 on a build machine has no bearing
> on the real question of whether SDL 2.0 is a hard or soft dependency,
> now that the project has decided that SDL 2.0 is easy enough to obtain
> across all of the set of systems included in our documented list of
> minimum development setups.  In short, if you want to build with SDL,
> you need to have SDL 2.0 available because we are not going to support
> builds against SDL 1.2 as a reasonable development target any longer;
> but having SDL 2.0 development libraries available does not preclude
> also keeping SDL 1.2 on the same machine for other reasons.
>
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.           +1-919-301-3226
> Virtualization:  qemu.org | libvirt.org
>

Re: [Qemu-devel] [QUESTION] SDL 1.2 support

[Eric Blake]

[-- Attachment #1.1: Type: text/plain, Size: 2683 bytes --]

On 7/17/19 2:20 PM, Aleksandar Markovic wrote:

> But, does "configure" list somewhere unmet soft dependencies? (the
> question is general, not looking at SDL only) Is there any other way for
> an end user to have info on unmet dependencies (whether soft or hard),
> other than see QEMU is not building, or something is not working in
> QEMU run-time?

Yes - at the end of ./configure, the output includes a list similar to:

...
profiler          no
static build      no
SDL support       yes (2.0.9)
SDL image support no
GTK support       yes (3.24.1)
GTK GL support    yes
VTE support       yes (0.54.4)
TLS priority      NORMAL
GNUTLS support    yes
libgcrypt         no
nettle            yes (3.4.1)
...

so on my system, I have SDL 2.0.9 (auto-detected, so it is in use);
whereas a system with no SDL or only SDL 1.2 would probably state "SDL
support no". You can similarly observe how I lack libgcrypt but have
libnettle. Basically, if configure exited with status 0, anything with a
'no' status was a soft dependency and you are building without that
feature; but if you want to ensure that a feature is used, you could use
'./configure --enable-sdl=yes' to force configure to make SDL a hard
dependency (fail it if was not found, instead of the default of probing
if it is available and then deciding yes or no based on the probe
results).  Conversely, you can use './configure --disable-sdl' (also
spelled './configure --enable-sdl=no') to forcefully build without SDL
(and prove that it was a soft dependency, and to see what gets omitted
from the build) even when the probe would otherwise have automatically
built against SDL 2.0.

> 
> Daniel,
> 
> We had message "SDL 1.2 is going to be deprecated" in QEMU 3.0
> "configure" and, if I remember well, in QEMU 3.1 as well. And now,
> when we finally deprecated it, is it true that there is no message
> whatsoever on systems with SDL 1.2 only?

You'll get the 'SDL supported no' message, but unless you were explicit
at the configure command line, the default behavior is that it relies on
system probing with silent fallback; you have to supply an
--enable/--disable command-line option if you want better behavior than
an implicit default.  In fact, if you ever look at downstream packages,
you'll notice that the packagers have a very long list of
--enable/--disable to prove that their build is reproducible with the
intended components instead of arbitrary based on whatever probing
happened to find on the system at the time.

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [Qemu-devel] [QUESTION] SDL 1.2 support

[Philippe Mathieu-Daudé]

Hi Aleksandar,

On 7/16/19 7:09 PM, Aleksandar Markovic wrote:
> On Tue, Jul 16, 2019 at 1:54 PM Thomas Huth <thuth@redhat.com> wrote:
>>
>> On 16/07/2019 13.17, Aleksandar Markovic wrote:
>>> Hello, Gerd, Daniel, and others involved.
>>>
>>> I have multiple reports from end users that say that transition from
>>> SDL 1.2 to SDL 2.0 was difficult, or even impossible for their hosts.
>>> In that light, they don't appreciate removing SDL 1.2 support from
>>> QEMU. The most notable example is Ubutnu 16.04, where it looks there
>>> is no way of installing SDL 2.0 that does not involve complete OS
>>> upgrade, which, for various reasons, many are not willing to do.
>>
>> What's the problem here? According to
>> https://packages.ubuntu.com/xenial/libsdl2-2.0-0 the library should be
>> available there.
>>
> 
> Yes, we, as developers, are good at upgrading, we like flexibility in
> our development systems, and naturally want to try latest and greatest
> tools and libraries.
> 
> However, in QA / build / test environments, the things seem to look
> different. Their main concern is stability and repeatibility of their
> systems. They don't like updates and upgrades. If a new of library
> is available for an OS, this does not mean it will be installed, or it
> will be desired to be installed.
> 
> It appears that Ubuntu 16.04 came originally with SDL 1.2, and
> SDL 2.0 was made available later on.

I am a bit confused, I checked the older Xenial image I can find is a
pre-release:

16.04.20151218.1-xenial-baseline

# lsb_release -a
LSB Version:
core-9.20160110ubuntu0.2-amd64:core-9.20160110ubuntu0.2-noarch:security-9.20160110ubuntu0.2-amd64:security-9.20160110ubuntu0.2-noarch
Distributor ID: Ubuntu
Description:    Ubuntu Xenial Xerus (development branch)
Release:        16.04
Codename:       xenial

# apt-cache search libsdl
libsdl1.2-dbg - Simple DirectMedia Layer debug files
libsdl1.2-dev - Simple DirectMedia Layer development files
libsdl1.2debian - Simple DirectMedia Layer

# apt-cache search libsdl2

# apt-get update

# apt-cache search libsdl2
libsdl2-2.0-0 - Simple DirectMedia Layer
libsdl2-dbg - Simple DirectMedia Layer debug files
libsdl2-dev - Simple DirectMedia Layer development files
libsdl2-doc - Reference manual for libsdl2
libsdl2-gfx-1.0-0 - drawing and graphical effects extension for SDL2
libsdl2-gfx-dbg - debugging symbols for SDL2_gfx
libsdl2-gfx-dev - development files for SDL2_gfx
libsdl2-gfx-doc - documentation files for SDL2_gfx
libsdl2-image-2.0-0 - Image loading library for Simple DirectMedia Layer
2, libraries
libsdl2-image-dbg - Image loading library for Simple DirectMedia Layer
2, debugging symbols
libsdl2-image-dev - Image loading library for Simple DirectMedia Layer
2, development files
libsdl2-mixer-2.0-0 - Mixer library for Simple DirectMedia Layer 2,
libraries
libsdl2-mixer-dbg - Mixer library for Simple DirectMedia Layer 2, debugging
libsdl2-mixer-dev - Mixer library for Simple DirectMedia Layer 2,
development files
libsdl2-net-2.0-0 - Network library for Simple DirectMedia Layer 2,
libraries
libsdl2-net-dbg - Network library for Simple DirectMedia Layer 2, debugging
libsdl2-net-dev - Network library for Simple DirectMedia Layer 2,
development files
libsdl2-ttf-2.0-0 - TrueType Font library for Simple DirectMedia Layer
2, libraries
libsdl2-ttf-dbg - TrueType Font library for Simple DirectMedia Layer 2,
debugging
libsdl2-ttf-dev - TrueType Font library for Simple DirectMedia Layer 2,
development files

# apt-cache show libsdl2-dev
Package: libsdl2-dev
Architecture: amd64
Version: 2.0.4+dfsg1-2ubuntu2.16.04.1
Priority: optional
Section: universe/libdevel
Source: libsdl2
Origin: Ubuntu
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Original-Maintainer: Debian SDL packages maintainers
<pkg-sdl-maintainers@lists.alioth.debian.org>
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 3803
Depends: libasound2-dev, libdbus-1-dev, libegl1-mesa-dev,
libgl1-mesa-dev, libgles2-mesa-dev, libglu1-mesa-dev, libmirclient-dev,
libpulse-dev, libsdl2-2.0-0 (= 2.0.4+dfsg1-2ubuntu2.16.04.1),
libsndio-dev, libudev-dev, libwayland-dev, libx11-dev, libxcursor-dev,
libxext-dev, libxi-dev, libxinerama-dev, libxkbcommon-dev,
libxrandr-dev, libxss-dev, libxt-dev, libxv-dev, libxxf86vm-dev
Conflicts: libsdl-1.3-dev
Replaces: libsdl-1.3-dev
Filename:
pool/universe/libs/libsdl2/libsdl2-dev_2.0.4+dfsg1-2ubuntu2.16.04.1_amd64.deb
Size: 612948
MD5sum: 75ff5bbc4c5ec0c9b81052b3695aa642
SHA1: 7d9ddbb5217343400128149ceea497d29a188a5e
SHA256: 1b79ee19be271d26e28de1a83f8181afa36a7fdc5479faa9f5dfe07ba4c4c272
Homepage: http://www.libsdl.org/
Description: Simple DirectMedia Layer development files
Description-md5: 9a82f59c5790721baad7ffc5f181d3d6
Supported: 5y

Package: libsdl2-dev
Priority: optional
Section: universe/libdevel
Installed-Size: 3802
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Original-Maintainer: Debian SDL packages maintainers
<pkg-sdl-maintainers@lists.alioth.debian.org>
Architecture: amd64
Source: libsdl2
Version: 2.0.4+dfsg1-2ubuntu2
Replaces: libsdl-1.3-dev
Depends: libasound2-dev, libdbus-1-dev, libegl1-mesa-dev,
libgl1-mesa-dev, libgles2-mesa-dev, libglu1-mesa-dev, libmirclient-dev,
libpulse-dev, libsdl2-2.0-0 (= 2.0.4+dfsg1-2ubuntu2), libsndio-dev,
libudev-dev, libwayland-dev, libx11-dev, libxcursor-dev, libxext-dev,
libxi-dev, libxinerama-dev, libxkbcommon-dev, libxrandr-dev, libxss-dev,
libxt-dev, libxv-dev, libxxf86vm-dev
Conflicts: libsdl-1.3-dev
Filename:
pool/universe/libs/libsdl2/libsdl2-dev_2.0.4+dfsg1-2ubuntu2_amd64.deb
Size: 613746
MD5sum: 470e753ffa16fec00c29215e0c94efc9
SHA1: db99050370630d36105131d60bad9daa95c530d8
SHA256: 461dc89140f2716f05e20cf35c2cf3f46b0ae6e32c5bed16136df08d28b2fde0
Description: Simple DirectMedia Layer development files
Description-md5: 9a82f59c5790721baad7ffc5f181d3d6
Homepage: http://www.libsdl.org/
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu
Supported: 9m

# curl -v
http://archive.ubuntu.com/ubuntu/pool/universe/libs/libsdl2/libsdl2_2.0.4+dfsg1-2ubuntu2.dsc
2>&1 | fgrep Last-Modified
< Last-Modified: Thu, 10 Mar 2016 22:03:45 GMT

This package was available before the Xenial official release.

I am supposing your host does not have Internet access to run apt-update
then?

Regards,

Phil.

Re: [Qemu-devel] [QUESTION] SDL 1.2 support

[Philippe Mathieu-Daudé]

On 7/16/19 8:20 PM, Philippe Mathieu-Daudé wrote:
> Hi Aleksandar,
> 
> On 7/16/19 7:09 PM, Aleksandar Markovic wrote:
>> On Tue, Jul 16, 2019 at 1:54 PM Thomas Huth <thuth@redhat.com> wrote:
>>>
>>> On 16/07/2019 13.17, Aleksandar Markovic wrote:
>>>> Hello, Gerd, Daniel, and others involved.
>>>>
>>>> I have multiple reports from end users that say that transition from
>>>> SDL 1.2 to SDL 2.0 was difficult, or even impossible for their hosts.
>>>> In that light, they don't appreciate removing SDL 1.2 support from
>>>> QEMU. The most notable example is Ubutnu 16.04, where it looks there
>>>> is no way of installing SDL 2.0 that does not involve complete OS
>>>> upgrade, which, for various reasons, many are not willing to do.
>>>
>>> What's the problem here? According to
>>> https://packages.ubuntu.com/xenial/libsdl2-2.0-0 the library should be
>>> available there.
>>>
>>
>> Yes, we, as developers, are good at upgrading, we like flexibility in
>> our development systems, and naturally want to try latest and greatest
>> tools and libraries.
>>
>> However, in QA / build / test environments, the things seem to look
>> different. Their main concern is stability and repeatibility of their
>> systems. They don't like updates and upgrades. If a new of library
>> is available for an OS, this does not mean it will be installed, or it
>> will be desired to be installed.
>>
>> It appears that Ubuntu 16.04 came originally with SDL 1.2, and
>> SDL 2.0 was made available later on.
> 
> I am a bit confused, I checked the older Xenial image I can find is a
> pre-release:
> 
> 16.04.20151218.1-xenial-baseline
> 
> # lsb_release -a
> LSB Version:
> core-9.20160110ubuntu0.2-amd64:core-9.20160110ubuntu0.2-noarch:security-9.20160110ubuntu0.2-amd64:security-9.20160110ubuntu0.2-noarch
> Distributor ID: Ubuntu
> Description:    Ubuntu Xenial Xerus (development branch)
> Release:        16.04
> Codename:       xenial
> 
> # apt-cache search libsdl
> libsdl1.2-dbg - Simple DirectMedia Layer debug files
> libsdl1.2-dev - Simple DirectMedia Layer development files
> libsdl1.2debian - Simple DirectMedia Layer
> 
> # apt-cache search libsdl2
> 
> # apt-get update
> 
> # apt-cache search libsdl2
> libsdl2-2.0-0 - Simple DirectMedia Layer
> libsdl2-dbg - Simple DirectMedia Layer debug files
> libsdl2-dev - Simple DirectMedia Layer development files
> libsdl2-doc - Reference manual for libsdl2
> libsdl2-gfx-1.0-0 - drawing and graphical effects extension for SDL2
> libsdl2-gfx-dbg - debugging symbols for SDL2_gfx
> libsdl2-gfx-dev - development files for SDL2_gfx
> libsdl2-gfx-doc - documentation files for SDL2_gfx
> libsdl2-image-2.0-0 - Image loading library for Simple DirectMedia Layer
> 2, libraries
> libsdl2-image-dbg - Image loading library for Simple DirectMedia Layer
> 2, debugging symbols
> libsdl2-image-dev - Image loading library for Simple DirectMedia Layer
> 2, development files
> libsdl2-mixer-2.0-0 - Mixer library for Simple DirectMedia Layer 2,
> libraries
> libsdl2-mixer-dbg - Mixer library for Simple DirectMedia Layer 2, debugging
> libsdl2-mixer-dev - Mixer library for Simple DirectMedia Layer 2,
> development files
> libsdl2-net-2.0-0 - Network library for Simple DirectMedia Layer 2,
> libraries
> libsdl2-net-dbg - Network library for Simple DirectMedia Layer 2, debugging
> libsdl2-net-dev - Network library for Simple DirectMedia Layer 2,
> development files
> libsdl2-ttf-2.0-0 - TrueType Font library for Simple DirectMedia Layer
> 2, libraries
> libsdl2-ttf-dbg - TrueType Font library for Simple DirectMedia Layer 2,
> debugging
> libsdl2-ttf-dev - TrueType Font library for Simple DirectMedia Layer 2,
> development files
> 
> # apt-cache show libsdl2-dev
> Package: libsdl2-dev
> Architecture: amd64
> Version: 2.0.4+dfsg1-2ubuntu2.16.04.1
> Priority: optional
> Section: universe/libdevel
> Source: libsdl2
> Origin: Ubuntu
> Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
> Original-Maintainer: Debian SDL packages maintainers
> <pkg-sdl-maintainers@lists.alioth.debian.org>
> Bugs: https://bugs.launchpad.net/ubuntu/+filebug
> Installed-Size: 3803
> Depends: libasound2-dev, libdbus-1-dev, libegl1-mesa-dev,
> libgl1-mesa-dev, libgles2-mesa-dev, libglu1-mesa-dev, libmirclient-dev,
> libpulse-dev, libsdl2-2.0-0 (= 2.0.4+dfsg1-2ubuntu2.16.04.1),
> libsndio-dev, libudev-dev, libwayland-dev, libx11-dev, libxcursor-dev,
> libxext-dev, libxi-dev, libxinerama-dev, libxkbcommon-dev,
> libxrandr-dev, libxss-dev, libxt-dev, libxv-dev, libxxf86vm-dev
> Conflicts: libsdl-1.3-dev
> Replaces: libsdl-1.3-dev
> Filename:
> pool/universe/libs/libsdl2/libsdl2-dev_2.0.4+dfsg1-2ubuntu2.16.04.1_amd64.deb
> Size: 612948
> MD5sum: 75ff5bbc4c5ec0c9b81052b3695aa642
> SHA1: 7d9ddbb5217343400128149ceea497d29a188a5e
> SHA256: 1b79ee19be271d26e28de1a83f8181afa36a7fdc5479faa9f5dfe07ba4c4c272
> Homepage: http://www.libsdl.org/
> Description: Simple DirectMedia Layer development files
> Description-md5: 9a82f59c5790721baad7ffc5f181d3d6
> Supported: 5y
> 
> Package: libsdl2-dev
> Priority: optional
> Section: universe/libdevel
> Installed-Size: 3802
> Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
> Original-Maintainer: Debian SDL packages maintainers
> <pkg-sdl-maintainers@lists.alioth.debian.org>
> Architecture: amd64
> Source: libsdl2
> Version: 2.0.4+dfsg1-2ubuntu2
> Replaces: libsdl-1.3-dev
> Depends: libasound2-dev, libdbus-1-dev, libegl1-mesa-dev,
> libgl1-mesa-dev, libgles2-mesa-dev, libglu1-mesa-dev, libmirclient-dev,
> libpulse-dev, libsdl2-2.0-0 (= 2.0.4+dfsg1-2ubuntu2), libsndio-dev,
> libudev-dev, libwayland-dev, libx11-dev, libxcursor-dev, libxext-dev,
> libxi-dev, libxinerama-dev, libxkbcommon-dev, libxrandr-dev, libxss-dev,
> libxt-dev, libxv-dev, libxxf86vm-dev
> Conflicts: libsdl-1.3-dev
> Filename:
> pool/universe/libs/libsdl2/libsdl2-dev_2.0.4+dfsg1-2ubuntu2_amd64.deb
> Size: 613746
> MD5sum: 470e753ffa16fec00c29215e0c94efc9
> SHA1: db99050370630d36105131d60bad9daa95c530d8
> SHA256: 461dc89140f2716f05e20cf35c2cf3f46b0ae6e32c5bed16136df08d28b2fde0
> Description: Simple DirectMedia Layer development files
> Description-md5: 9a82f59c5790721baad7ffc5f181d3d6
> Homepage: http://www.libsdl.org/
> Bugs: https://bugs.launchpad.net/ubuntu/+filebug
> Origin: Ubuntu
> Supported: 9m
> 
> # curl -v
> http://archive.ubuntu.com/ubuntu/pool/universe/libs/libsdl2/libsdl2_2.0.4+dfsg1-2ubuntu2.dsc
> 2>&1 | fgrep Last-Modified
> < Last-Modified: Thu, 10 Mar 2016 22:03:45 GMT
> 
> This package was available before the Xenial official release.
> 
> I am supposing your host does not have Internet access to run apt-update
> then?

Spending more time on this issue, assuming your customer has Ubuntu
16.04 installed from default cdrom image, with not network connectivity,
but can copy packages on a USB drive.

So since the default install comes without git, I had to shutdown the
guest, mount the disk image, copy from a cloned repository, reboot the
guest.

$ ./configure

ERROR: pkg-config binary 'pkg-config' not found

pkg-config depends of the following 11 packages:
- bzip2
- dpkg-dev
- libdpkg-perl
- libgdbm3
- libglib2.0-0
- libperl5.22
- make
- patch
- perl
- perl-modules-5.22
- xz-utils

Since it starts to be painful and time consuming to shutdown guest/mount
image/copy files/umount image/restart guest, and since I have network
access to it, I'll install openssh-server, but will not run "apt-get
update" in my guest.

So openssh-server requires:
- init-system-helpers
- libbsd0
- libedit2
- libgssapi-krb5-2
- libk5crypto3
- libkeyutils1
- libkrb5-3
- libkrb5support0
- libwrap0
- openssh-client
- openssh-server
- openssh-sftp-server

Now I manually download all the .deb packages from
http://archive.ubuntu.com/ubuntu and copy them to the guest.
Restart guest, install packages.

$ ./configure

ERROR: glib-2.40 gthread-2.0 is required to compile QEMU

Ok, this is a hard dependency.

New packages to install:
- libelf1
- libglib2.0-bin
- libglib2.0-data
- libglib2.0-dev
- libpcre16-3
- libpcre3-dev
- libpcre32-3
- libpcrecpp0v5
- zlib1g-dev

$ ./configure

ERROR: pixman >= 0.21.8 not present.
       Please install the pixman devel package.

Installing:
- libpixman-1-0
- libpixman-1-dev

$ ./configure
No C++ compiler available; disabling C++ specific optional code
Install prefix    /usr/local
BIOS directory    /usr/local/share/qemu
firmware path     /usr/local/share/qemu-firmware
binary directory  /usr/local/bin
library directory /usr/local/lib
module directory  /usr/local/lib/qemu
libexec directory /usr/local/libexec
include directory /usr/local/include
config directory  /usr/local/etc
local state directory   /usr/local/var
Manual directory  /usr/local/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path       /tmp/qemu
GIT binary        git
GIT submodules    ui/keycodemapdb tests/fp/berkeley-testfloat-3
tests/fp/berkeley-softfloat-3 dtc capstone slirp
C compiler        cc
Host C compiler   cc
C++ compiler
Objective-C compiler cc
ARFLAGS           rv
CFLAGS            -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g
QEMU_CFLAGS       -I/usr/include/pixman-1 -I$(SRC_PATH)/dtc/libfdt
-Werror  -pthread -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -fPIE -DPIE -m64 -mcx16
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings
-Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -std=gnu99
 -Wendif-labels -Wno-missing-include-dirs -Wempty-body -Wnested-externs
-Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers
-Wold-style-declaration -Wold-style-definition -Wtype-limits
-fstack-protector-strong -I$(SRC_PATH)/capstone/include
LDFLAGS           -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g
QEMU_LDFLAGS      -L$(BUILD_DIR)/dtc/libfdt
make              make
install           install
python            python -B (2.7.12)
slirp support     git
smbd              /usr/sbin/smbd
module support    no
host CPU          x86_64
host big endian   no
target list       aarch64-softmmu alpha-softmmu arm-softmmu cris-softmmu
hppa-softmmu i386-softmmu lm32-softmmu m68k-softmmu microblaze-softmmu
microblazeel-softmmu mips-softmmu mips64-softmmu mips64el-softmmu
mipsel-softmmu moxie-softmmu nios2-softmmu or1k-softmmu ppc-softmmu
ppc64-softmmu riscv32-softmmu riscv64-softmmu s390x-softmmu sh4-softmmu
sh4eb-softmmu sparc-softmmu sparc64-softmmu tricore-softmmu
unicore32-softmmu x86_64-softmmu xtensa-softmmu xtensaeb-softmmu
aarch64-linux-user aarch64_be-linux-user alpha-linux-user arm-linux-user
armeb-linux-user cris-linux-user hppa-linux-user i386-linux-user
m68k-linux-user microblaze-linux-user microblazeel-linux-user
mips-linux-user mips64-linux-user mips64el-linux-user mipsel-linux-user
mipsn32-linux-user mipsn32el-linux-user nios2-linux-user or1k-linux-user
ppc-linux-user ppc64-linux-user ppc64abi32-linux-user ppc64le-linux-user
riscv32-linux-user riscv64-linux-user s390x-linux-user sh4-linux-user
sh4eb-linux-user sparc-linux-user sparc32plus-linux-user
sparc64-linux-user tilegx-linux-user x86_64-linux-user xtensa-linux-user
xtensaeb-linux-user
gprof enabled     no
sparse enabled    no
strip binaries    yes
profiler          no
static build      no
SDL support       no
SDL image support no
GTK support       no
GTK GL support    no
VTE support       no
TLS priority      NORMAL
GNUTLS support    no
libgcrypt         no
nettle            no
libtasn1          no
PAM               no
iconv support     yes
curses support    no
virgl support     no
curl support      no
mingw32 support   no
Audio drivers      oss
Block whitelist (rw)
Block whitelist (ro)
VirtFS support    no
Multipath support no
VNC support       yes
VNC SASL support  no
VNC JPEG support  no
VNC PNG support   no
xen support       no
brlapi support    no
bluez  support    no
Documentation     no
PIE               yes
vde support       no
netmap support    no
Linux AIO support no
ATTR/XATTR support yes
Install blobs     yes
KVM support       yes
HAX support       no
HVF support       no
WHPX support      no
TCG support       yes
TCG debug enabled no
TCG interpreter   no
malloc trim support yes
RDMA support      no
PVRDMA support    no
fdt support       git
membarrier        no
preadv support    yes
fdatasync         yes
madvise           yes
posix_madvise     yes
posix_memalign    yes
libcap-ng support no
vhost-net support yes
vhost-crypto support yes
vhost-scsi support yes
vhost-vsock support yes
vhost-user support yes
Trace backends    log
spice support     no
rbd support       no
xfsctl support    no
smartcard support no
libusb            no
usb net redir     no
OpenGL support    no
OpenGL dmabufs    no
libiscsi support  no
libnfs support    no
build guest agent yes
QGA VSS support   no
QGA w32 disk info no
QGA MSI support   no
seccomp support   no
coroutine backend ucontext
coroutine pool    yes
debug stack usage no
mutex debugging   no
crypto afalg      no
GlusterFS support no
gcov              gcov
gcov enabled      no
TPM support       yes
libssh support    no
QOM debugging     yes
Live block migration yes
lzo support       no
snappy support    no
bzip2 support     no
lzfse support     no
NUMA host support no
libxml2           no
tcmalloc support  no
jemalloc support  no
avx2 optimization yes
replication support yes
VxHS block device no
bochs support     yes
cloop support     yes
dmg support       yes
qcow v1 support   yes
vdi support       yes
vvfat support     yes
qed support       yes
parallels support yes
sheepdog support  yes
capstone          git
docker            no
libpmem support   no
libudev           no
default devices   yes

warning: Python 2 support is deprecated
warning: Python 3 will be required for building future versions of QEMU

NOTE: cross-compilers enabled:  'cc' 'cc'

$

Yay!

$ make
/bin/sh: 1: git: not found
make[1]: Entering directory 'slirp'
make[1]: *** No targets specified and no makefile found.  Stop.
make[1]: Leaving directory 'slirp'
Makefile:503: recipe for target 'slirp/all' failed
make: *** [slirp/all] Error 2

Hmmm I forgot about git, but having git here would suggest we have
Internet connectivity we assumed we don't have. I forgot about it, it
was somehow stupid to work with a cloned repository.

So I'll continue with this tarball instead:
https://github.com/qemu/qemu/archive/v4.1.0-rc0.tar.gz

$ ./configure

ERROR: missing file /tmp/qemu-4.1.0-rc0/ui/keycodemapdb/README

This is not a GIT checkout but module content appears to
be missing. Do not use 'git archive' or GitHub download links
to acquire QEMU source archives. Non-GIT builds are only
supported with source archives linked from:

  https://www.qemu.org/download/

Developers working with GIT can use scripts/archive-source.sh
if they need to create valid source archives.

OK. Oh, this page doesn't link anything... Odd.

Let's look at the last mail from Michael Roth:

---
On behalf of the QEMU Team, I'd like to announce the availability of the
first release candidate for the QEMU 4.1 release.  This release is meant
for testing purposes and should not be used in a production environment.

  http://download.qemu-project.org/qemu-4.1.0-rc0.tar.xz
  http://download.qemu-project.org/qemu-4.1.0-rc0.tar.xz.sig
---

$ tar -xf qemu-4.1.0-rc0.tar.xz
tar: qemu-4.1.0-rc0.tar.xz: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now

Who said this would be easy, eh...

$ type xz
xz is /usr/bin/xz

Oh, we have xz but tar is too old and dunno about it.

$ unxz qemu-4.1.0-rc0.tar.xz
$ tar -xf qemu-4.1.0-rc0.tar

$ ./configure
No C++ compiler available; disabling C++ specific optional code
Install prefix    /usr/local
BIOS directory    /usr/local/share/qemu
firmware path     /usr/local/share/qemu-firmware
binary directory  /usr/local/bin
library directory /usr/local/lib
module directory  /usr/local/lib/qemu
libexec directory /usr/local/libexec
include directory /usr/local/include
config directory  /usr/local/etc
local state directory   /usr/local/var
Manual directory  /usr/local/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path       /tmp/qemu-4.1.0-rc0
GIT binary        git
GIT submodules
C compiler        cc
Host C compiler   cc
C++ compiler
Objective-C compiler cc
ARFLAGS           rv
CFLAGS            -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g
QEMU_CFLAGS       -I/usr/include/pixman-1 -I$(SRC_PATH)/dtc/libfdt
-pthread -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -fPIE -DPIE -m64 -mcx16
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings
-Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -std=gnu99
 -Wendif-labels -Wno-missing-include-dirs -Wempty-body -Wnested-externs
-Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers
-Wold-style-declaration -Wold-style-definition -Wtype-limits
-fstack-protector-strong -I$(SRC_PATH)/capstone/include
LDFLAGS           -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g
QEMU_LDFLAGS      -L$(BUILD_DIR)/dtc/libfdt
make              make
install           install
python            python -B (2.7.12)
slirp support     internal
smbd              /usr/sbin/smbd
module support    no
host CPU          x86_64
host big endian   no
target list       aarch64-softmmu alpha-softmmu arm-softmmu cris-softmmu
hppa-softmmu i386-softmmu lm32-softmmu m68k-softmmu microblaze-softmmu
microblazeel-softmmu mips-softmmu mips64-softmmu mips64el-softmmu
mipsel-softmmu moxie-softmmu nios2-softmmu or1k-softmmu ppc-softmmu
ppc64-softmmu riscv32-softmmu riscv64-softmmu s390x-softmmu sh4-softmmu
sh4eb-softmmu sparc-softmmu sparc64-softmmu tricore-softmmu
unicore32-softmmu x86_64-softmmu xtensa-softmmu xtensaeb-softmmu
aarch64-linux-user aarch64_be-linux-user alpha-linux-user arm-linux-user
armeb-linux-user cris-linux-user hppa-linux-user i386-linux-user
m68k-linux-user microblaze-linux-user microblazeel-linux-user
mips-linux-user mips64-linux-user mips64el-linux-user mipsel-linux-user
mipsn32-linux-user mipsn32el-linux-user nios2-linux-user or1k-linux-user
ppc-linux-user ppc64-linux-user ppc64abi32-linux-user ppc64le-linux-user
riscv32-linux-user riscv64-linux-user s390x-linux-user sh4-linux-user
sh4eb-linux-user sparc-linux-user sparc32plus-linux-user
sparc64-linux-user tilegx-linux-user x86_64-linux-user xtensa-linux-user
xtensaeb-linux-user
gprof enabled     no
sparse enabled    no
strip binaries    yes
profiler          no
static build      no
SDL support       no
SDL image support no
GTK support       no
GTK GL support    no
VTE support       no
TLS priority      NORMAL
GNUTLS support    no
libgcrypt         no
nettle            no
libtasn1          no
PAM               no
iconv support     yes
curses support    no
virgl support     no
curl support      no
mingw32 support   no
Audio drivers      oss
Block whitelist (rw)
Block whitelist (ro)
VirtFS support    no
Multipath support no
VNC support       yes
VNC SASL support  no
VNC JPEG support  no
VNC PNG support   no
xen support       no
brlapi support    no
bluez  support    no
Documentation     no
PIE               yes
vde support       no
netmap support    no
Linux AIO support no
ATTR/XATTR support yes
Install blobs     yes
KVM support       yes
HAX support       no
HVF support       no
WHPX support      no
TCG support       yes
TCG debug enabled no
TCG interpreter   no
malloc trim support yes
RDMA support      no
PVRDMA support    no
fdt support       git
membarrier        no
preadv support    yes
fdatasync         yes
madvise           yes
posix_madvise     yes
posix_memalign    yes
libcap-ng support no
vhost-net support yes
vhost-crypto support yes
vhost-scsi support yes
vhost-vsock support yes
vhost-user support yes
Trace backends    log
spice support     no
rbd support       no
xfsctl support    no
smartcard support no
libusb            no
usb net redir     no
OpenGL support    no
OpenGL dmabufs    no
libiscsi support  no
libnfs support    no
build guest agent yes
QGA VSS support   no
QGA w32 disk info no
QGA MSI support   no
seccomp support   no
coroutine backend ucontext
coroutine pool    yes
debug stack usage no
mutex debugging   no
crypto afalg      no
GlusterFS support no
gcov              gcov
gcov enabled      no
TPM support       yes
libssh support    no
QOM debugging     yes
Live block migration yes
lzo support       no
snappy support    no
bzip2 support     no
lzfse support     no
NUMA host support no
libxml2           no
tcmalloc support  no
jemalloc support  no
avx2 optimization yes
replication support yes
VxHS block device no
bochs support     yes
cloop support     yes
dmg support       yes
qcow v1 support   yes
vdi support       yes
vvfat support     yes
qed support       yes
parallels support yes
sheepdog support  yes
capstone          internal
docker            no
libpmem support   no
libudev           no
default devices   yes

warning: Python 2 support is deprecated
warning: Python 3 will be required for building future versions of QEMU

NOTE: cross-compilers enabled:  'cc' 'cc'

$ make
[...]
  GEN     util/trace.c
        CHK version_gen.h
         LEX convert-dtsv0-lexer.lex.c
make[1]: flex: Command not found
         BISON dtc-parser.tab.c
make[1]: bison: Command not found
         LEX dtc-lexer.lex.c
make[1]: flex: Command not found
  AR      libcapstone.a
ar: creating /tmp/qemu-4.1.0-rc0/capstone/libcapstone.a
[...]
  CC      mipsel-softmmu/trace/generated-helpers.o
  LINK    mipsel-softmmu/qemu-system-mipsel
[...]
  CC      mips64el-softmmu/target/mips/cp0_timer.o
  GEN     trace/generated-helpers.c
  CC      mips64el-softmmu/trace/control-target.o
  CC      mips64el-softmmu/trace/generated-helpers.o
  LINK    mips64el-softmmu/qemu-system-mips64el
[...]

$ wget
https://mipsdistros.mips.com/LinuxDistro/nanomips/kernels/v4.15.18-432-gb2eb9a8b07a1-20180627102142/generic_nano32r6el_page16k_up.xz

$ unxz generic_nano32r6el_page16k_up.xz

$ ./mipsel-softmmu/qemu-system-mipsel -M malta -cpu I7200 -kernel
generic_nano32r6el_page16k_up -append console=ttyS0 -nographic
[    0.000000] Linux version 4.15.18 (emubuild@mipscs567) (gcc version
6.3.0 (Codescape GNU Tools 2018.04-02 for nanoMIPS Linux)) #1 Wed Jun 27
11:13:09 PDT 2018
[    0.000000] GCRs appear to have been moved (expected them at 0x1fbf8000)!
[    0.000000] GCRs appear to have been moved (expected them at 0x1fbf8000)!
[    0.000000] CPU0 revision is: 00010000 (MIPS GENERIC QEMU)
[    0.000000] MIPS: machine is mti,malta
[    0.000000] Determined physical RAM map:
[    0.000000]  memory: 08000000 @ 00000000 (usable)
[    0.000000] earlycon: ns16550a0 at I/O port 0x3f8 (options '38400n8')
[...]

$ make check-tcg
[...]
  BUILD   TCG tests for mips-softmmu
  BUILD   mips guest-tests SKIPPED
  RUN     TCG tests for mips-softmmu
  RUN     tests for mips SKIPPED
  BUILD   TCG tests for mips64-softmmu
  BUILD   mips64 guest-tests SKIPPED
  RUN     TCG tests for mips64-softmmu
  RUN     tests for mips64 SKIPPED
  BUILD   TCG tests for mips64el-softmmu
  BUILD   mips64el guest-tests SKIPPED
  RUN     TCG tests for mips64el-softmmu
  RUN     tests for mips64el SKIPPED
  BUILD   TCG tests for mipsel-softmmu
  BUILD   mipsel guest-tests SKIPPED
  RUN     TCG tests for mipsel-softmmu
  RUN     tests for mipsel SKIPPED
[...]
  BUILD   x86_64 guest-tests with cc
  RUN     tests for x86_64
  TEST    test-mmap (default) on x86_64
  TEST    sha1 on x86_64
  TEST    linux-test on x86_64
  TEST    testthread on x86_64
  TEST    test-x86_64 on x86_64
  TEST    test-mmap (4096 byte pages) on x86_64
[...]
$

Ah, cross-target tests are skipped because I don't have Docker for
cross-building tests.

Let's see how you use them:

$ cat tests/tcg/mips/user/ase/msa/README
The tests in subdirectories of this directory are supposed to be
compiled for
mips64el MSA-enabled CPU (I6400, I6500), using an appropriate MIPS
toolchain.
For example:

/opt/img/bin/mips-img-linux-gnu-gcc <source file>                  \
-EL -static -mabi=64 -march=mips64r6 -mmsa  -o <executable file>

They are to be executed using QEMU user mode, using command line:

mips64el-linux-user/qemu-mips64el -cpu I6400 <executable file>
[...]

Googling I find this link:
https://www.mips.com/develop/tools/codescape-mips-sdk/

The following host platforms are recommended:
 Windows 10 (64-bit)
 Linux: Ubuntu 16.04 (64-bit) and CentOS 7 (64-bit)

Offline Installer
These are ~ 3Gbyte and include all components in one installer file.

OMG I'm not sure I want to continue with this...

Download in progress.

I already spent 2h on this today, I have to continue other tasks
meanwhile, I might continue later.

Re: [Qemu-devel] [QUESTION] SDL 1.2 support

[Philippe Mathieu-Daudé]

Hi Aleksandar,

On 7/18/19 8:20 AM, Philippe Mathieu-Daudé wrote:
> On 7/16/19 8:20 PM, Philippe Mathieu-Daudé wrote:
>> Hi Aleksandar,
>>
>> On 7/16/19 7:09 PM, Aleksandar Markovic wrote:
>>> On Tue, Jul 16, 2019 at 1:54 PM Thomas Huth <thuth@redhat.com> wrote:
>>>>
>>>> On 16/07/2019 13.17, Aleksandar Markovic wrote:
>>>>> Hello, Gerd, Daniel, and others involved.
>>>>>
>>>>> I have multiple reports from end users that say that transition from
>>>>> SDL 1.2 to SDL 2.0 was difficult, or even impossible for their hosts.
>>>>> In that light, they don't appreciate removing SDL 1.2 support from
>>>>> QEMU. The most notable example is Ubutnu 16.04, where it looks there
>>>>> is no way of installing SDL 2.0 that does not involve complete OS
>>>>> upgrade, which, for various reasons, many are not willing to do.
>>>>
>>>> What's the problem here? According to
>>>> https://packages.ubuntu.com/xenial/libsdl2-2.0-0 the library should be
>>>> available there.
>>>>
>>>
>>> Yes, we, as developers, are good at upgrading, we like flexibility in
>>> our development systems, and naturally want to try latest and greatest
>>> tools and libraries.
>>>
>>> However, in QA / build / test environments, the things seem to look
>>> different. Their main concern is stability and repeatibility of their
>>> systems. They don't like updates and upgrades. If a new of library
>>> is available for an OS, this does not mean it will be installed, or it
>>> will be desired to be installed.
>>>
>>> It appears that Ubuntu 16.04 came originally with SDL 1.2, and
>>> SDL 2.0 was made available later on.
>>
>> I am a bit confused, I checked the older Xenial image I can find is a
>> pre-release:
>>
>> 16.04.20151218.1-xenial-baseline
>>
[...]
> $ make
> [...]
>   GEN     util/trace.c
>         CHK version_gen.h
>          LEX convert-dtsv0-lexer.lex.c
> make[1]: flex: Command not found
>          BISON dtc-parser.tab.c
> make[1]: bison: Command not found
>          LEX dtc-lexer.lex.c
> make[1]: flex: Command not found
>   AR      libcapstone.a
> ar: creating /tmp/qemu-4.1.0-rc0/capstone/libcapstone.a
> [...]
>   CC      mipsel-softmmu/trace/generated-helpers.o
>   LINK    mipsel-softmmu/qemu-system-mipsel
> [...]
>   CC      mips64el-softmmu/target/mips/cp0_timer.o
>   GEN     trace/generated-helpers.c
>   CC      mips64el-softmmu/trace/control-target.o
>   CC      mips64el-softmmu/trace/generated-helpers.o
>   LINK    mips64el-softmmu/qemu-system-mips64el
> [...]
> 
> $ wget
> https://mipsdistros.mips.com/LinuxDistro/nanomips/kernels/v4.15.18-432-gb2eb9a8b07a1-20180627102142/generic_nano32r6el_page16k_up.xz
> 
> $ unxz generic_nano32r6el_page16k_up.xz
> 
> $ ./mipsel-softmmu/qemu-system-mipsel -M malta -cpu I7200 -kernel
> generic_nano32r6el_page16k_up -append console=ttyS0 -nographic
> [    0.000000] Linux version 4.15.18 (emubuild@mipscs567) (gcc version
> 6.3.0 (Codescape GNU Tools 2018.04-02 for nanoMIPS Linux)) #1 Wed Jun 27
> 11:13:09 PDT 2018
> [    0.000000] GCRs appear to have been moved (expected them at 0x1fbf8000)!
> [    0.000000] GCRs appear to have been moved (expected them at 0x1fbf8000)!
> [    0.000000] CPU0 revision is: 00010000 (MIPS GENERIC QEMU)
> [    0.000000] MIPS: machine is mti,malta
> [    0.000000] Determined physical RAM map:
> [    0.000000]  memory: 08000000 @ 00000000 (usable)
> [    0.000000] earlycon: ns16550a0 at I/O port 0x3f8 (options '38400n8')
> [...]
> 
> $ make check-tcg
> [...]
>   BUILD   TCG tests for mips-softmmu
>   BUILD   mips guest-tests SKIPPED
>   RUN     TCG tests for mips-softmmu
>   RUN     tests for mips SKIPPED
>   BUILD   TCG tests for mips64-softmmu
>   BUILD   mips64 guest-tests SKIPPED
>   RUN     TCG tests for mips64-softmmu
>   RUN     tests for mips64 SKIPPED
>   BUILD   TCG tests for mips64el-softmmu
>   BUILD   mips64el guest-tests SKIPPED
>   RUN     TCG tests for mips64el-softmmu
>   RUN     tests for mips64el SKIPPED
>   BUILD   TCG tests for mipsel-softmmu
>   BUILD   mipsel guest-tests SKIPPED
>   RUN     TCG tests for mipsel-softmmu
>   RUN     tests for mipsel SKIPPED
> [...]
>   BUILD   x86_64 guest-tests with cc
>   RUN     tests for x86_64
>   TEST    test-mmap (default) on x86_64
>   TEST    sha1 on x86_64
>   TEST    linux-test on x86_64
>   TEST    testthread on x86_64
>   TEST    test-x86_64 on x86_64
>   TEST    test-mmap (4096 byte pages) on x86_64
> [...]
> $
> 
> Ah, cross-target tests are skipped because I don't have Docker for
> cross-building tests.
> 
> Let's see how you use them:
> 
> $ cat tests/tcg/mips/user/ase/msa/README
> The tests in subdirectories of this directory are supposed to be
> compiled for
> mips64el MSA-enabled CPU (I6400, I6500), using an appropriate MIPS
> toolchain.
> For example:
> 
> /opt/img/bin/mips-img-linux-gnu-gcc <source file>                  \
> -EL -static -mabi=64 -march=mips64r6 -mmsa  -o <executable file>
> 
> They are to be executed using QEMU user mode, using command line:
> 
> mips64el-linux-user/qemu-mips64el -cpu I6400 <executable file>
> [...]
> 
> Googling I find this link:
> https://www.mips.com/develop/tools/codescape-mips-sdk/
> 
> The following host platforms are recommended:
>  Windows 10 (64-bit)
>  Linux: Ubuntu 16.04 (64-bit) and CentOS 7 (64-bit)
> 
> Offline Installer
> These are ~ 3Gbyte and include all components in one installer file.
> 
> OMG I'm not sure I want to continue with this...
> 
> Download in progress.
> 
> I already spent 2h on this today, I have to continue other tasks
> meanwhile, I might continue later.

I spent 1 more hour installing the CodeScape MIPS SDK, even trying to
install it in a Docker image to have it handy or use it in some CI.
However I reached the end of the spare time I could spend trying to
help, and nobody from the community is complaining except your customer.

Since 11 days passed and you haven't replied to my extensive testing, I
am assuming you could figure out how to help your customer with the
other answers to this thread.

Regards,

Phil.

Re: [Qemu-devel] [QUESTION] SDL 1.2 support

[Aleksandar Markovic]

>
>
>
> >
> > I already spent 2h on this today, I have to continue other tasks
> > meanwhile, I might continue later.
>
> I spent 1 more hour installing the CodeScape MIPS SDK,...


Philippe, thank you so much for your 3 hours!

Regards,
Aleksandar