questions re: package qemu-system-sparc

Christian Ehrhardt christian.ehrhardt at
Tue Apr 30 05:31:29 UTC 2019

On Thu, Apr 11, 2019 at 8:32 PM <email436 at> wrote:
> On 4/9/2019 at 1:59 PM, "Dan Streetman" <dan.streetman at> wrote:
> On Tue, Apr 9, 2019 at 1:33 PM <email436 at> wrote:
> >
> > [Emailing here because it's the published maintainer address for Ubuntu package qemu-system-sparc. Please redirect me if I should look elsewhere.]
> >
> > From what I've been able to find within Ubuntu 18.10, the latest available version of qemu-system-sparc (and qemu in general) is 2.12.0 (Debian 1:2.12+dfsg-3ubuntu8.6).
> >
> > However the upstream QEMU project released v3.0.0 on August 14 2018, thus I'd hoped it would make it into Ubuntu 18.10. Is the delay simply due to a lack of resources?
> the next ubuntu release, disco, has qemu 3.1 included:
> $ rmadison -s disco -a source qemu
> qemu | 1:3.1+dfsg-2ubuntu3 | disco | source
> It is scheduled for release soon:
> Thank you for the fast reply, and for the pointer to rmadison.--

Hi as well,
for the general selection e.g. to predict the upcoming versions you
can always check the qemu planning pages like [1][2].
And compare it to the timeline of the Ubuntu Releases [3][4].
Ubuntu is on regular schedules since almost forever so we can use that reliably.
Furthermore these days qemu is more and more on a regular release
pattern as well with years bumping the major number and a .0 version
in ~April.
Followed by a .1 version in August and most likely a .2 in December -
3.x was special, but it is usually ~4 months each release.
Combining the two and considering the constraints like Ubuntu Entering
Feature freeze we can try to forecast future versions will map like

a) Ubuntu XX.04 => Qemu XX-16.Y (y being the last .y that qemu
released the year before)
b) Ubuntu XX.10 => Qemu XX-15.1 (If they make early August and no
hickups happen, otherwise .0 of April)

You already see that it is more of a stretch for the Ubuntu .10 releases.
Sometimes - actually most of the times looking at the past - you'd
want a libvirt release that is after the Qemu release to have it
handle the known hickups/changes well.
That means for the August Qemu you would often need the September
libvirt (monthly releases) and that is unfortunately too deep into
Ubuntu Feature Freeze - this is a case by case decision every cycle.

Following the SRU process [5] the qemu version in that Ubuntu release
will then stick and only be patched by individual bugfixes and
security updates.
In general, but even more so for LTS releases of Ubuntu, we also parse
the following qemu upstream development a few times to add further
patches for stabilization before releasing and then being under the
SRU process.

And if you want to look back in history rmadison (thanks ddstreet) or
just the Launchpads overview page of qemu [6] can tell you which qemu
is in which Ubuntu release.
Both of these techniques work for any package in Ubuntu by the way.

Finally there is also the Ubuntu Cloud Archive [7] which not always,
but often will carry the qemu/libvirt/... of the current Ubuntu
release - like 19.04 carrying qemu 3.1 which is in UCA-Stein - but as
backport to the latest LTS which is 18.04 at the moment.
This is mostly meant and supported for the context of a OpenStack
deployment, but depending on what you need/use it for that can be a
source for "new qemu on LTS" for you.

P.S. and for your particular question why qemu 3.0 isn't in Ubuntu
18.10 - which is a good question - this is one of the cases were
"early August" didn't work well for us.
This upstream release was just before the feature freeze (9 days), but
3.0 had too many changes that required extra work and we'd have wanted
the libvirt of September which was too late.
I didn't want to shove that onto Ubuntu users unprepared - so we
decided to stick with qemu 2.12 at that cycle.

P.P.S. Our planning on all of that is rather open and public, you'll
find a trello card like [8] for every cycle, the next one being [9].
There tasks, thoughts and references for the next releases virt-stack
will accumulate and be handled eventually.


More information about the Ubuntu-devel-discuss mailing list