Thursday, 23 March 2017

Ubuntu 17.04 (Zesty Zapus) Final Beta released

The Ubuntu team is pleased to announce the final beta release of the
Ubuntu 17.04 Desktop, Server, and Cloud products.

Codenamed "Zesty Zapus", 17.04 continues Ubuntu's proud tradition of
integrating the latest and greatest open source technologies into a
high-quality, easy-to-use Linux distribution. The team has been hard
at work through this cycle, introducing new features and fixing bugs.

This beta release includes images from not only the Ubuntu Desktop,
Server, and Cloud products, but also the Kubuntu, Lubuntu, Ubuntu
GNOME, UbuntuKylin, Ubuntu MATE, Ubuntu Studio, and Xubuntu flavours.

We're also pleased with this release to welcome Ubuntu Budgie to the
family of Ubuntu community flavours.

The beta images are known to be reasonably free of showstopper CD build
or installer bugs, while representing a very recent snapshot of 17.04
that should be representative of the features intended to ship with the
final release expected on April 13th, 2017.

Ubuntu, Ubuntu Server, Cloud Images:
Yakkety Final Beta includes updated versions of most of our core set
of packages, including a current 4.10 kernel, and much more.

To upgrade to Ubuntu 17.04 Final Beta from Ubuntu 16.10, follow these

The Ubuntu 17.04 Final Beta images can be downloaded at: (Ubuntu and Ubuntu Server on x86)

Additional images can be found at the following links: (Cloud Images) (Non-x86 Server) (Netboot)

As fixes will be included in new images between now and release, any
daily cloud image from today or later (i.e. a serial of 20170323 or
higher) should be considered a beta image. Bugs found should be filed
against the appropriate packages or, failing that, the cloud-images
project in Launchpad.

The full release notes for Ubuntu 17.04 Final Beta can be found at:

Kubuntu is the KDE based flavour of Ubuntu. It uses the Plasma desktop
and includes a wide selection of tools from the KDE project.

The Final Beta images can be downloaded at:

More information on Kubuntu Final Beta can be found here:

Lubuntu is a flavor of Ubuntu that targets to be lighter, less
resource hungry and more energy-efficient by using lightweight
applications and LXDE, The Lightweight X11 Desktop Environment,
as its default GUI.

The Final Beta images can be downloaded at:

More information on Lubuntu Final Beta can be found here:

Ubuntu Budgie:
Ubuntu Budgie is community developed desktop, integrating Budgie
Desktop Environment with Ubuntu at its core.

The Final Beta images can be downloaded at:

More information on Ubuntu Budgie Final Beta can be found here:

Ubuntu GNOME:
Ubuntu GNOME is a flavor of Ubuntu featuring the GNOME desktop

The Final Beta images can be downloaded at:

More information on Ubuntu GNOME Final Beta can be found here:

UbuntuKylin is a flavor of Ubuntu that is more suitable for Chinese

The Final Beta images can be downloaded at:

More information on UbuntuKylin Final Beta can be found here:

Ubuntu MATE:
Ubuntu MATE is a flavor of Ubuntu featuring the MATE desktop

The Final Beta images can be downloaded at:

More information on UbuntuMATE Final Beta can be found here:

Ubuntu Studio:
Ubuntu Studio is a flavor of Ubuntu that provides a full range of
multimedia content creation applications for each key workflows:
audio, graphics, video, photography and publishing.

The Final Beta images can be downloaded at:

More information about Ubuntu Studio Final Beta can be found here:

Xubuntu is a flavor of Ubuntu that comes with Xfce, which is a stable,
light and configurable desktop environment.

The Final Beta images can be downloaded at:

More inormation about Xubuntu Final Beta can be found here:

Regular daily images for Ubuntu, and all flavours, can be found at:

Ubuntu is a full-featured Linux distribution for clients, servers and
clouds, with a fast and easy installation and regular releases. A
tightly-integrated selection of excellent applications is included, and
an incredible variety of add-on software is just a few clicks away.

Professional technical support is available from Canonical Limited and
hundreds of other companies around the world. For more information
about support, visit

If you would like to help shape Ubuntu, take a look at the list of ways
you can participate at:

Your comments, bug reports, patches and suggestions really help us to
improve this and future releases of Ubuntu. Instructions can be
found at:

You can find out more about Ubuntu and about this beta release on our
website, IRC channel and wiki.

To sign up for future Ubuntu announcements, please subscribe to Ubuntu's
very low volume announcement list at:

On behalf of the Ubuntu Release Team,

Adam Conrad

ubuntu-announce mailing list
[email protected]
Modify settings or unsubscribe at:

Ubuntu Kernel Team - Weekly Newsletter, 2017-03-21


The Ubuntu Kernel Team has published this weeks newsletter[0].

The Newsletter is published weekly. It contains highlights from the
week, announcements regarding the development and stable kernels, as
well as any other news the Kernel Team may have.


The Ubuntu Kernel Team


ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at:

Wednesday, 22 March 2017

Re: aptdaemon

Le 15/03/2017 à 23:24, Jeremy Bicha a écrit :
> sessioninstaller is broken in zesty now (LP: #1661371)
> As I commented on the bug, gnome-software can replace sessioninstaller
> (at least for the purpose of installing the codecs to play an mp3),
> but it doesn't work with gnome-software apt backend.

Hey there,

Just a follow up about sessioninstaller. I had a look at the issue and
it's still working, the problem is that the packagekit backend build has
been turned on mid-cycle in zesty (looks like an error, it was not
documented in the changelog at least) resulting in gnome-software
including a dbus .service/claiming the org.freedesktop.PackageKit name
on the session bus, which means sessioninstaller can't do that and is
bailing out.

We discussed that on IRC and Jeremy has uploaded a new gnome-software
revision to disable packagekit back, which should be enough to fix the
issue for zesty.

It would still be good to fix gnome-software codec installation when
using our apt backend so we can deprecate sessioninstaller though, I'm
going to have a look to that next.


Sebastien Bacher

ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at:

Tuesday, 21 March 2017

SRU quality and preventing regressions

I'm fairly new to ~ubuntu-sru, and I noticed a couple of things that I
think we could do better in terms of preventing SRU regressions:

1) Actual consideration of how regressions might manifest in "Regression
Potential" paperwork.

2) A description of what was actually tested when marking

Both of these are already requirements of the SRU process, but many
uploaders appear to be unaware of this. Since I started on ~ubuntu-sru,
I have been following the process and either fixing up or deferring SRUs
that do not follow the process. Please help to save everyone time by
making sure this is done properly the first time.

With my DMB hat, we considered and accepted our first application to
~ubuntu-sru-developers last week. In also having an SRU hat[1], I'd like
to see ~ubuntu-sru-developers holding the torch for SRU quality, but
that's tough when I think other existing uploaders could do better.


1) "Regression Potential"

"Regression Potential" is supposed to describe: regressions are most likely to manifest, or may manifest
even if it is unlikely, as a result of this change. It is
assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's
important to make the effort to think about what could happen in
the event of a regression.

Note that "Low" or "None", or an explanation of why it is "Low" or
"None", is insufficient and doesn't meet this requirement.

If I don't have enough information to be able to fill this in myself
quickly, or if I have a particuarly big queue when I'm reviewing, I will
continue to bounce this back to the uploader and delay the SRU. I prefer
this over accepting something that will get insufficient verification
and risk regressing the stable release.

2) "verification-done"

When marking "verification-done", please describe what packages were
tested and what versions. This is explicitly requested in the acceptance
message, but I see many people not doing this.

We have had at least one very severe regression because the version
tested was not the version released. To prevent this happening again, I
will continue to bounce back any "verification-done" that does not
explicitly state what package versions were tested.

Just switching the tags is similarly unacceptable. I will continue to
decline to release and just switch the tag back when I see this.

Automated testing is still fine - just arrange the automatic testing to
print out the package versions used, and copy that detail in, explaining
it was automatically tested.

If you are a sponsor, please hold contributors to these standards too.
Otherwise they'll only get frustrated later when their SRUs get delayed.



[1] currently I believe there are four people who wear both hats, so
this isn't unique to me

Monday, 20 March 2017

Re: Contributing Developer Application for Ross Gammon

I'm pleased to announce that the DMB voted to grant Ross Gammon
Contributing Developer on 2017-02-27.

Welcome Ross, and sorry for the late announcement.

On behalf of the DMB,


Re: Proposal: new ~ubuntu-sru-uploaders team [was: Unblocking SRU uploader permissions]

On Tue, Feb 28, 2017 at 09:32:38AM -0500, Eric Desrochers wrote:
> Yes, I'll prepare my application for the sru-uploader team for the next DMB meeting.

The DMB considered Eric's application on 13 March and I'm pleased to
report that it was successful with a unanimous vote.

Eric is the first member of this new team. Welcome Eric, and thank you
for your contributions to Ubuntu!

I have documented the new team at:

I also made the executive decision to call the team
~ubuntu-sru-developers instead of ~ubuntu-sru-uploaders, since the team
does grant Ubuntu membership and this naming seems to match the scheme
used in existing teams better. Of course SRU uploads aren't exclusive to
this team; if you can upload to the development release for any package,
you can also upload that package to the stable releases for SRU review.
No change there.

On behalf of the DMB,


Re: To access IPP-over-USB printer: Emulate remote machine in the network

On 02/23/2017 12:47 AM, Seth Arnold wrote:
> On Wed, Feb 22, 2017 at 04:42:46PM -0300, Till Kamppeter wrote:
>> So it looks like that we need to work with an extra interface (dummy0 with
>> IPv6) and find a way to let Avahi broadcast the interface's own host name or
> Would you mind changing the name to something that would more clearly
> reflect the reason why this dummy interface exists?
> e.g., cups0 or cupsbrowser or cupslocal.
> Ideally it'd be unique enough that searching the web for the name would
> return our documentation about it and nothing else. 'dummy0' would easily
> fail that test.

I also came already to this idea and in my most recent tests I called
the interface "ippusbxd". I set up the interface for testing with the
following commands:

sudo ip link add ippusbxd type dummy
sudo ip link set ippusbxd up
sudo ip link set ippusbxd multicast on
sudo ip -6 addr add 'fd00:1:1::1/64' dev ippusbxd

Note that for the testing I use a fixed IP address. For production a
random one should be chosen.


ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at: