* [Qemu-devel] [QUESTION] SDL 1.2 support
@ 2019-07-16 11:17 Aleksandar Markovic
2019-07-16 11:41 ` Peter Maydell
` (2 more replies)
0 siblings, 3 replies; 18+ messages in thread
From: Aleksandar Markovic @ 2019-07-16 11:17 UTC (permalink / raw)
To: Gerd Hoffmann, berrange, QEMU Developers
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-devel] [QUESTION] SDL 1.2 support
2019-07-16 11:17 [Qemu-devel] [QUESTION] SDL 1.2 support Aleksandar Markovic
@ 2019-07-16 11:41 ` Peter Maydell
2019-07-16 17:48 ` Aleksandar Markovic
2019-07-16 11:50 ` Daniel P. Berrangé
2019-07-16 11:54 ` Thomas Huth
2 siblings, 1 reply; 18+ messages in thread
From: Peter Maydell @ 2019-07-16 11:41 UTC (permalink / raw)
To: Aleksandar Markovic; +Cc: berrange, Gerd Hoffmann, QEMU Developers
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-devel] [QUESTION] SDL 1.2 support
2019-07-16 11:17 [Qemu-devel] [QUESTION] SDL 1.2 support Aleksandar Markovic
2019-07-16 11:41 ` Peter Maydell
@ 2019-07-16 11:50 ` Daniel P. Berrangé
2019-07-16 11:54 ` Thomas Huth
2 siblings, 0 replies; 18+ messages in thread
From: Daniel P. Berrangé @ 2019-07-16 11:50 UTC (permalink / raw)
To: Aleksandar Markovic; +Cc: Gerd Hoffmann, QEMU Developers
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 :|
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-devel] [QUESTION] SDL 1.2 support
2019-07-16 11:17 [Qemu-devel] [QUESTION] SDL 1.2 support Aleksandar Markovic
2019-07-16 11:41 ` Peter Maydell
2019-07-16 11:50 ` Daniel P. Berrangé
@ 2019-07-16 11:54 ` Thomas Huth
2019-07-16 17:09 ` Aleksandar Markovic
2 siblings, 1 reply; 18+ messages in thread
From: Thomas Huth @ 2019-07-16 11:54 UTC (permalink / raw)
To: Aleksandar Markovic, Gerd Hoffmann, berrange, QEMU Developers
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-devel] [QUESTION] SDL 1.2 support
2019-07-16 11:54 ` Thomas Huth
@ 2019-07-16 17:09 ` Aleksandar Markovic
2019-07-16 17:44 ` Daniel P. Berrangé
2019-07-16 18:20 ` Philippe Mathieu-Daudé
0 siblings, 2 replies; 18+ messages in thread
From: Aleksandar Markovic @ 2019-07-16 17:09 UTC (permalink / raw)
To: Thomas Huth; +Cc: berrange, Gerd Hoffmann, QEMU Developers
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-devel] [QUESTION] SDL 1.2 support
2019-07-16 17:09 ` Aleksandar Markovic
@ 2019-07-16 17:44 ` Daniel P. Berrangé
2019-07-16 18:06 ` Aleksandar Markovic
2019-07-17 18:34 ` Aleksandar Markovic
2019-07-16 18:20 ` Philippe Mathieu-Daudé
1 sibling, 2 replies; 18+ messages in thread
From: Daniel P. Berrangé @ 2019-07-16 17:44 UTC (permalink / raw)
To: Aleksandar Markovic; +Cc: Thomas Huth, Gerd Hoffmann, QEMU Developers
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 :|
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-devel] [QUESTION] SDL 1.2 support
2019-07-16 11:41 ` Peter Maydell
@ 2019-07-16 17:48 ` Aleksandar Markovic
2019-07-16 18:30 ` Peter Maydell
0 siblings, 1 reply; 18+ messages in thread
From: Aleksandar Markovic @ 2019-07-16 17:48 UTC (permalink / raw)
To: Peter Maydell; +Cc: berrange, Gerd Hoffmann, QEMU Developers
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-devel] [QUESTION] SDL 1.2 support
2019-07-16 17:44 ` Daniel P. Berrangé
@ 2019-07-16 18:06 ` Aleksandar Markovic
2019-07-16 18:16 ` Daniel P. Berrangé
2019-07-17 18:34 ` Aleksandar Markovic
1 sibling, 1 reply; 18+ messages in thread
From: Aleksandar Markovic @ 2019-07-16 18:06 UTC (permalink / raw)
To: Daniel P. Berrangé; +Cc: Thomas Huth, Gerd Hoffmann, QEMU Developers
> > 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 :|
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-devel] [QUESTION] SDL 1.2 support
2019-07-16 18:06 ` Aleksandar Markovic
@ 2019-07-16 18:16 ` Daniel P. Berrangé
0 siblings, 0 replies; 18+ messages in thread
From: Daniel P. Berrangé @ 2019-07-16 18:16 UTC (permalink / raw)
To: Aleksandar Markovic; +Cc: Thomas Huth, Gerd Hoffmann, QEMU Developers
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 :|
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-devel] [QUESTION] SDL 1.2 support
2019-07-16 17:09 ` Aleksandar Markovic
2019-07-16 17:44 ` Daniel P. Berrangé
@ 2019-07-16 18:20 ` Philippe Mathieu-Daudé
2019-07-18 6:20 ` Philippe Mathieu-Daudé
1 sibling, 1 reply; 18+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-07-16 18:20 UTC (permalink / raw)
To: Aleksandar Markovic, Thomas Huth; +Cc: berrange, Gerd Hoffmann, QEMU Developers
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-devel] [QUESTION] SDL 1.2 support
2019-07-16 17:48 ` Aleksandar Markovic
@ 2019-07-16 18:30 ` Peter Maydell
0 siblings, 0 replies; 18+ messages in thread
From: Peter Maydell @ 2019-07-16 18:30 UTC (permalink / raw)
To: Aleksandar Markovic; +Cc: berrange, Gerd Hoffmann, QEMU Developers
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-devel] [QUESTION] SDL 1.2 support
2019-07-16 17:44 ` Daniel P. Berrangé
2019-07-16 18:06 ` Aleksandar Markovic
@ 2019-07-17 18:34 ` Aleksandar Markovic
2019-07-17 18:57 ` Eric Blake
1 sibling, 1 reply; 18+ messages in thread
From: Aleksandar Markovic @ 2019-07-17 18:34 UTC (permalink / raw)
To: Daniel P. Berrangé; +Cc: Thomas Huth, Gerd Hoffmann, QEMU Developers
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-devel] [QUESTION] SDL 1.2 support
2019-07-17 18:34 ` Aleksandar Markovic
@ 2019-07-17 18:57 ` Eric Blake
2019-07-17 19:20 ` Aleksandar Markovic
0 siblings, 1 reply; 18+ messages in thread
From: Eric Blake @ 2019-07-17 18:57 UTC (permalink / raw)
To: Aleksandar Markovic, Daniel P. Berrangé
Cc: Thomas Huth, Gerd Hoffmann, QEMU Developers
[-- 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 --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-devel] [QUESTION] SDL 1.2 support
2019-07-17 18:57 ` Eric Blake
@ 2019-07-17 19:20 ` Aleksandar Markovic
2019-07-17 19:57 ` Eric Blake
0 siblings, 1 reply; 18+ messages in thread
From: Aleksandar Markovic @ 2019-07-17 19:20 UTC (permalink / raw)
To: Eric Blake
Cc: Thomas Huth, Daniel P. Berrangé, Gerd Hoffmann, QEMU Developers
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
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-devel] [QUESTION] SDL 1.2 support
2019-07-17 19:20 ` Aleksandar Markovic
@ 2019-07-17 19:57 ` Eric Blake
0 siblings, 0 replies; 18+ messages in thread
From: Eric Blake @ 2019-07-17 19:57 UTC (permalink / raw)
To: Aleksandar Markovic
Cc: Thomas Huth, Daniel P. Berrangé, Gerd Hoffmann, QEMU Developers
[-- 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 --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-devel] [QUESTION] SDL 1.2 support
2019-07-16 18:20 ` Philippe Mathieu-Daudé
@ 2019-07-18 6:20 ` Philippe Mathieu-Daudé
2019-07-29 10:36 ` Philippe Mathieu-Daudé
0 siblings, 1 reply; 18+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-07-18 6:20 UTC (permalink / raw)
To: Aleksandar Markovic, Thomas Huth; +Cc: berrange, Gerd Hoffmann, QEMU Developers
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-devel] [QUESTION] SDL 1.2 support
2019-07-18 6:20 ` Philippe Mathieu-Daudé
@ 2019-07-29 10:36 ` Philippe Mathieu-Daudé
2019-07-29 11:27 ` Aleksandar Markovic
0 siblings, 1 reply; 18+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-07-29 10:36 UTC (permalink / raw)
To: Aleksandar Markovic, Thomas Huth; +Cc: berrange, Gerd Hoffmann, QEMU Developers
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-devel] [QUESTION] SDL 1.2 support
2019-07-29 10:36 ` Philippe Mathieu-Daudé
@ 2019-07-29 11:27 ` Aleksandar Markovic
0 siblings, 0 replies; 18+ messages in thread
From: Aleksandar Markovic @ 2019-07-29 11:27 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Thomas Huth, berrange, Gerd Hoffmann, QEMU Developers
>
>
>
> >
> > 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
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2019-07-29 11:28 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-16 11:17 [Qemu-devel] [QUESTION] SDL 1.2 support Aleksandar Markovic
2019-07-16 11:41 ` Peter Maydell
2019-07-16 17:48 ` Aleksandar Markovic
2019-07-16 18:30 ` Peter Maydell
2019-07-16 11:50 ` Daniel P. Berrangé
2019-07-16 11:54 ` Thomas Huth
2019-07-16 17:09 ` Aleksandar Markovic
2019-07-16 17:44 ` Daniel P. Berrangé
2019-07-16 18:06 ` Aleksandar Markovic
2019-07-16 18:16 ` Daniel P. Berrangé
2019-07-17 18:34 ` Aleksandar Markovic
2019-07-17 18:57 ` Eric Blake
2019-07-17 19:20 ` Aleksandar Markovic
2019-07-17 19:57 ` Eric Blake
2019-07-16 18:20 ` Philippe Mathieu-Daudé
2019-07-18 6:20 ` Philippe Mathieu-Daudé
2019-07-29 10:36 ` Philippe Mathieu-Daudé
2019-07-29 11:27 ` Aleksandar Markovic
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).