Thursday, 19 July 2018

Ubuntu 17.10 (Artful Aardvark) End of Life reached on July 19 2018

This is a follow-up to the End of Life warning sent earlier this month
to confirm that as of today (July 19, 2018), Ubuntu 17.10 is no longer
supported. No more package updates will be accepted to 17.10, and
it will be archived to old-releases.ubuntu.com in the coming weeks.

The original End of Life warning follows, with upgrade instructions:

Ubuntu announced its 17.10 (Artful Aardvark) release almost 9 months
ago, on October 19, 2017. As a non-LTS release, 17.10 has a 9-month
support cycle and, as such, the support period is now nearing its
end and Ubuntu 17.10 will reach end of life on Thursday, July 19th.

At that time, Ubuntu Security Notices will no longer include
information or updated packages for Ubuntu 17.10.

The supported upgrade path from Ubuntu 17.10 is via Ubuntu 18.04.
Instructions and caveats for the upgrade may be found at:

https://help.ubuntu.com/community/BionicUpgrades

Ubuntu 18.04 continues to be actively supported with security updates
and select high-impact bug fixes. Announcements of security updates
for Ubuntu releases are sent to the ubuntu-security-announce mailing
list, information about which may be found at:

https://lists.ubuntu.com/mailman/listinfo/ubuntu-security-announce

Since its launch in October 2004 Ubuntu has become one of the most
highly regarded Linux distributions with millions of users in homes,
schools, businesses and governments around the world. Ubuntu is Open
Source software, costs nothing to download, and users are free to
customise or alter their software in order to meet their needs.

On behalf of the Ubuntu Release Team,

Adam Conrad

--
ubuntu-announce mailing list
ubuntu-announce@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-announce

Wednesday, 18 July 2018

The improved 18.04.1 LTS Server Installer - Call for testing!

Download from: http://cdimage.ubuntu.com/ubuntu-server/bionic/daily-live/

With the release of 18.04 LTS Bionic Beaver the new server installer
was introduced. At the time, it still lacked certain critical features
which have now been implemented.

For 18.04.1 we are adding support for LVM, RAID, VLAN, Bonds to the
new installer. The functionality and UI are all in place. It has not
yet been refined, thus I expect minor UI changes or improvements to
these features for Cosmic release. Notably, there are many new text
strings added, hence the translation coverage has now regressed.

At this point, we are looking for crash reports and critical bug
reports that might be observed with the updated installer. Please try
to configure LVM/RAID, Vlans, and Bonds, the way you would do it on
your typical server. This is to ensure 18.04.1 point release goes out
with a beautiful and fully functioning and improved server installer.

These and many other improvements are brought to you by Carla Berkers,
Claudio Gomboli, Dimitri John Ledkov, Ɓukasz 'sil2100' Zemczak, Med,
Michael Hudson-Doyle, Nornort, Ryan Harper, Scott Moser, Seth
Fitzsimmons, and many others.

Download from: http://cdimage.ubuntu.com/ubuntu-server/bionic/daily-live/

--
Regards,

Dimitri.

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Thursday, 12 July 2018

Re: Inconsistencies in package versions for stable releases

On Tue, Jul 10, 2018 at 12:37:33PM -0700, Seth Arnold wrote:
> The Ubuntu security team has a shell-script function that helps us keep
> the version strings consistent that may serve as a blueprint for such a
> lint:
>
> https://bazaar.launchpad.net/~ubuntu-security/ubuntu-security-tools/trunk/view/head:/package-tools/check-source-package#L623

Ah, thanks! FWIW, I wrote this a while ago for the lint:

https://git.launchpad.net/usd-importer/tree/gitubuntu/versioning.py#n356

The lint tool is mostly missing high level abstractions and tests at the
moment. Some of the core pieces are there already.

Robie

Tuesday, 10 July 2018

Re: mass SRUing for changing triggers to noawait in progress

On Tue, Jul 10, 2018 at 10:35:21PM +0200, Julian Andres Klode wrote:
> Our goal is to get those changes into xenial before 18.04.1 so that
> there are less upgrade failures. (Upgrade failures because the "await"

Oh nice, would this address bugs such as:

https://bugs.launchpad.net/ubuntu/+source/gnome-menus/+bug/1745785
https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1541716
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1573322
etc?

Thanks

mass SRUing for changing triggers to noawait in progress

Hi ubuntu-devel,

just a quick note that there is a mass SRUing going on (into xenial
mostly) for converting await triggers to noawait, the progress is being
tracked in https://bugs.launchpad.net/bugs/1780996. Help is welcome,
just assign yourself a task first and then complete it. Do note that
there are some pitfalls where triggers cannot be converted to noawait,
like gsettings schemas. If you are not sure, discuss it or leave it to
someone else.

Some artwork packages of flavours also need the same changes, that
progress is tracked in https://bugs.launchpad.net/bugs/1750465 -
I do encourage the people working on those flavours to fix it.

Our goal is to get those changes into xenial before 18.04.1 so that
there are less upgrade failures. (Upgrade failures because the "await"
triggers require triggers to be processed before configuration, so
if your package A triggers B, for example, by installing a file, B
declares an "interest" in; then B's postinst needs to run before A's
postinst can, which can easily fail if A does not depend on B, as
B might not be in a configurable state).

--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Inconsistencies in package versions for stable releases

On Tue, Jul 10, 2018 at 05:43:13PM +0100, Robie Basak wrote:
> pattern that so many developers seem to use. This is one that I want to
> resolve in the long term by encouraging via a lint tool first before
> turning it into a recommendation and eventually policy.

The Ubuntu security team has a shell-script function that helps us keep
the version strings consistent that may serve as a blueprint for such a
lint:

https://bazaar.launchpad.net/~ubuntu-security/ubuntu-security-tools/trunk/view/head:/package-tools/check-source-package#L623

Thanks

Re: Inconsistencies in package versions for stable releases

Hi Simon,

On Thu, Jul 05, 2018 at 11:15:08PM -0500, Simon Quigley wrote:
> This email is following several discussions I have had over the past few
> weeks on how the versioning scheme of packages work with respect to
> stable releases.

Thank you for bringing this up.

Right now, though I prefer the security team's documented scheme, I
understand that this isn't fixed by any policy so I usually reluctantly
accept other schemes from uploaders unless I think there is some
specific issue with it.

However, I would like to see our project having more consistency on this
in the long term.

For example, onboarding new developers (whether colleagues of mine at
Canonical or other volunteers) is made more difficult for everyone if
things aren't consistent, because astute propsective developers should
be asking about inconsistencies and this wastes everyone's time. And
it's also painful to be a prospective developer if you repeat patterns
you see elsewhere but don't know what your sponsors will or won't
accept, and what the SRU team will or won't accept.

To this end, I'd like to see SRU policy move from "this team does it
well; you may want to do it like them" to "this is our recommendation"
to "this is a requirement and results in a reject unless you can justify
an exception".

However, I'm not sure we're ready to move hard on that yet. I'd like to
see better tooling first, so any change creates less friction in the
short term. I have plans about this.

In git ubuntu, we have the beginnings of a "lint" tool. I haven't worked
on it in a while and it needs major refactoring before continuing. I
don't recommend it for general use yet. But eventually I want to be able
to recommend it for use by uploaders and sponsorees, as well as have it
run in CI against the sponsorship queue (which I hope will use a
MP-based workflow by then).

Then I'd like the lint tool to simply be able to say "I was expecting
version string X for this that appears to be an SRU, but I see version
string Y instead".

At this stage I expect that I'll want to push for this kind of
consistency to become a recommendation and hopefully eventually policy
(except for edge cases and where an exception is justified).

This is my general answer for matters of upload consistency FWIW. I want
to get the lint tool to the stage that it is reasonably pluggable,
implement a check for any perceived inconsistency as a warning in the
tool, and then move towards recommendations and policy from there.

I'm not sure I'm in favour of policy changes in this consistency area
until we have the tooling, as I'm concerned it'll cause too much
friction in existing workflows (especially in the very long
upload/reject review cycle for SRUs we have at the moment). With the
tooling, I'm hoping to be able to close the reject delay by
short-circuiting it.

> With ubuntu-report, I have always been discouraged from using codenames
> in the version number, because if, for some reason, we needed this in
> Xenial, being consistent with the naming scheme wouldn't work:
>
> $ dpkg --compare-versions "1.2.0~bionic" ">>" "1.2.0~xenial"; echo $?
> 1
> $ dpkg --compare-versions "1.2.0~bionic" ">>" "1.2.0~16.04.1"; echo $?
> 0
>
> This means we would have to be inconsistent across releases.

I'm in favour of implementing a general and immediate ban on using
release codenames in version strings to prevent confusion. AFAIK,
release numbers can always be used in their place, and the pattern is so
rare (I didn't even know it was still done in the archive) that I think
it'd cause almost no pain to implement. It's a dangerous pattern because
it sets up an expectation that doesn't always hold, as you point out. I
think it's worth breaking the pattern in any package that already uses
it.

> With shim, I have also been discouraged from doing ubuntuX, as opposed
> to ubuntuX.Y. In this case, I would have gone with 13-0ubuntu0.2.

I prefer ubuntuX.Y instead of ubuntu(X+1) for SRUs as I think it's
helpful to make it obvious that it's an SRU and it avoids the necessity
to check that ubuntu(X+1) isn't already in use (which is error prone).
However I continue to reluctantly accept ubuntu(X+1) because it's a
pattern that so many developers seem to use. This is one that I want to
resolve in the long term by encouraging via a lint tool first before
turning it into a recommendation and eventually policy.

> Is the existing document by the Security Team[1] lacking any important
> considerations? Can we adopt it as the uniform standard for updates in a
> stable release, or is there a good reason to continue with inconsistency
> here?

I'm in favour of turning it into a recommendation today. I thought it
already was, but I understand that some don't read the existing
documentation that way.

I don't want to mandate it until much further down the road though.

Robie