Friday, 28 April 2017

Ubuntu 12.04 (Precise Pangolin) End of Life reached on April 28, 2017

This is a follow-up to the End of Life warning sent last month to
confirm that as of today (April 28, 2017), Ubuntu 12.04 is no longer
generally supported. No more package updates will be accepted to
the 12.04 primary archive, and it will be copied for archival to
old-releases.ubuntu.com in the coming weeks.

However, we will again remind you that for customers who can't upgrade
immediately, Canonical is offering Extended Security Support for Ubuntu
Advantage customers, more info about which can be found here:

* https://ubuntu.com/esm

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

Ubuntu announced its 12.04 (Precise Pangolin) release almost 5 years ago,
on April 26, 2012. As with the earlier LTS releases, Ubuntu committed
to ongoing security and critical fixes for a period of 5 years. The
support period is now nearing its end and Ubuntu 12.04 will reach end
of life on Friday, April 28th. At that time, Ubuntu Security Notices
will no longer include information or updated packages for Ubuntu 12.04.

The supported upgrade path from Ubuntu 12.04 is via Ubuntu 14.04.
Users are encouraged to evaluate and upgrade to our latest 16.04 LTS
release via 14.04. Instructions and caveats for the upgrades may be
found at https://help.ubuntu.com/community/TrustyUpgrades and
https://help.ubuntu.com/community/XenialUpgrades. Ubuntu 14.04 and
16.04 continue to be actively supported with security updates and
select high-impact bug fixes. All announcements of official 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

For users who can't upgrade immediately, Canonical has just announced
an extended support package for Ubuntu Advantage customers, which will
keep delivering security updates while you evaluate your upgrades to
newer releases. The announcement, with details about how and where to
purchase extended support, can be found at:

https://lists.ubuntu.com/archives/ubuntu-announce/2017-March/000217.html

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
[email protected]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-announce

sqlalchemy 1.1 for artful

Hi All

sqlalchemy 1.0.x has been creating some awkward unit test races in some OpenStack projects (specifically neutron, and I'm fed up of hitting rebuild); I've started work on the transition to sqlalchemy 1.1.x for artful in:


reverse-depends currently have versioned Depends on sqlachemy - a no-change rebuild is required to update those.

Cheers

James

Wednesday, 26 April 2017

Re: Does the backporters team need help?

Excerpts from Iain Lane's message of 2017-04-25 09:18:31 +0100:
> On Mon, Apr 24, 2017 at 07:08:30PM -0500, Micah Gersten wrote:
> > Yes, indeed, the team could use assistance. I was on vacation and am
> > catching up on things. I would be happy to start getting more people
> > involved starting next week.
>
> I'm speaking as a member of the backporters team here.
>
> The backports process relies on the small and overworked backports team
> manually reviewing, uploading and then accepting uploads based on bug
> reports which often come from users and require any amount of cajoling
> (either back and forth with the reporter or actually doing the work) to
> be uploadable.
>
> The process is set up in such a way that there is a specific list of
> things that the requests have to contain, a specific set of meanings for
> bug statuses and a very onerous amount of testing required for
> non-trivial backports. Any or all of these things can be wrong per the
> policy, and they all make it very hard for the backporters team to
> manage. A new member might manage to triage some percentage of the bugs,
> but I suspect that very quickly they would get burned out with the
> process like the rest of us.
>
> I think it's proven to be a poor and unworkable process and it should be
> fixed to enable more developer autonomy. That said, I don't have a new
> proposal to make right now but I would be interested in trying to work
> one out.

Indeed, it feels a bit heavy weight. I wonder if we could just make it
a little easier to become a backporter if you're already a developer.

That said, I'm happy to help a little bit on the current workload until
we can revamp backports. With Canonical's refocus and staff changes,
I think it's worthwhile for folks like myself to step up and help in
areas we find important.

--
ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Ubuntu Kernel Team - Weekly Newsletter, 2017-04-25

Hello,

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.

Sincerely,

The Ubuntu Kernel Team


[0] https://wiki.ubuntu.com/KernelTeam/Newsletter/2017-04-25


--
ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Tuesday, 25 April 2017

Removal of upstart and cgmanager from Artful Aardvark

Upstart and CGManager have been in maintenance mode for a few releases
now. The primary users of upstart & CGManager were Mobile (Unity
Touch) and Unity8 desktop sessions. Upstart is used in those session
to provide user session supervisor and implement application
lifecycle.

Currently, ubuntu-app-launch has been ported to provide application
lifecycle using systemd. However, neither of the two session packages
were ported to kick off touch/unity8 sessions exclusively under
systemd. Currently, these still rely on user session upstart.

Whilst many apps and user session services have been ported to
systemd, I do not believe this effort is complete. Many of the
unported apps and services are touch/unity8 specific and are listed at
https://blueprints.launchpad.net/ubuntu/+spec/convergence-y-replace-upstart

In zesty, touch/unity8 sessions are the only two remaining sessions
that use upstart user init supervision. Everything else use systemd
(including unity7 session), and/or more typical session supervisors
(e.g. gnome-session, and forks of thereof).

upstart ongoing maintenance in the archive is not cost free, as their
sources and testsuites must be continuously maintained and updated for
the toolchain and kernel updates. Whilst both will be supported for
the full length of LTS and ESM timelines, I do not wish to ship either
in Artful.

Removal bug at https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1649310

Shows the extent of packages which will need to be removed:

* upstart
* unity8-desktop-session
* ubuntu-touch-session
* lxc-android-config
* upstart-watchdog
* ubuntu-touch-meta
* cgmanager

Without upstart unity8-desktop-session and ubuntu-touch-session
packages will be broken, as they rely on executing upstart to start a
session. Similarly, lxc-android-config provides many touch specific
and upstart specific overrides to make phone images integrate
correctly with the hardware specific device container.
upstart-watchdog is a package which ships upstart jobs only. Above
packages are all dependencies of the ubuntu-touch metapackage which is
used to determine the packages that should be installed in the touch
images.

I'm proposing to remove all of the above packages from Artful.

Certainly, it is possible to keep some of the above packages, by
simply removing metadata dependencies on upstart. But the packages in
question will be rendered useless, as they cannot function as intended
without upstart in their current state and need further porting to
systemd.

Please advise how to proceed, and if the stakeholders are ok with
removing above mentioned packages.

--
Regards,

Dimitri.

--
ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Server team meeting minutes: 2017-04-25

Minutes and action times from today's server team meeting are now posted
available here:
https://ubottu.com/meetingology/logs/ubuntu-meeting/2017/ubuntu-meeting.2017-04-25-16.01.html

Next week's agenda is available here:
https://wiki.ubuntu.com/ServerTeam/Meeting

Thanks!

--
Joshua Powers
Ubuntu Server
Canonical Ltd

--
ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Does the backporters team need help?

On Mon, Apr 24, 2017 at 07:08:30PM -0500, Micah Gersten wrote:
> Yes, indeed, the team could use assistance. I was on vacation and am
> catching up on things. I would be happy to start getting more people
> involved starting next week.

I'm speaking as a member of the backporters team here.

The backports process relies on the small and overworked backports team
manually reviewing, uploading and then accepting uploads based on bug
reports which often come from users and require any amount of cajoling
(either back and forth with the reporter or actually doing the work) to
be uploadable.

The process is set up in such a way that there is a specific list of
things that the requests have to contain, a specific set of meanings for
bug statuses and a very onerous amount of testing required for
non-trivial backports. Any or all of these things can be wrong per the
policy, and they all make it very hard for the backporters team to
manage. A new member might manage to triage some percentage of the bugs,
but I suspect that very quickly they would get burned out with the
process like the rest of us.

I think it's proven to be a poor and unworkable process and it should be
fixed to enable more developer autonomy. That said, I don't have a new
proposal to make right now but I would be interested in trying to work
one out.

Cheers,

--
Iain Lane [ [email protected] ]
Debian Developer [ [email protected] ]
Ubuntu Developer [ [email protected] ]